Subject: [ietf-822] Mailing lists - assumptions

From: Pete Resnick <[email-masked]>
Date: Fri, 18 Apr 2014 13:43:51 -0500

[Bcc'ing dmarc, but directed to ietf-822, since that's where we appear 
to be having the discussion for the moment.]

These ideas about mailing lists have been rattling around in my head 
these past couple of days, and they're based on a bunch of design 
assumptions. So I figured I'd post my list of assumptions and see if 
anybody thought any of them were off in space.

1. The mailing list itself is going to have to participate in this in 
some way. There's no point in trying to design something for mailing 
lists that simply will not make any modifications.

2. In the end, we want mailing lists to be able to send messages that 
say "From: [email-masked]" and not have to say 
"From: [email-masked]".

3. If an originator sends mail to a mailing list, the originator is 
implicitly giving permission for the list to re-distribute the message 
"From:" the originator.

4. If an originating site allows its users sending mail to mailing lists 
at all, the site is OK with *any* mailing list re-distributing mail from 
its users. so long as the mailing list received the mail directly from 
the originating user through the originating site. That is, originating 
sites don't care about pre-vetting mailing lists; they just care that 
the mail sent by mailing lists came directly from their users.

5. For a recipient of mailing list mail, their site cares about whether 
the message they got came directly from the mailing list site, cares 
that the mailing list got the mail directly from the originating user's 
site, and cares that the mailing list got the mail relatively recently. 
For the most part, the recipient's site doesn't care how much has 
changed about the content of the message. The eventual recipient might 
care if the changes are in the extreme, but from a "is this spoofed 
spam" perspective, that really doesn't matter.

6. The mailing list cares about whether it got the message directly from 
the originating user's site.

7. An originating site would be willing to query (through a DNS lookup 
or otherwise) the first hop recipient for any message and stick 
something in the message that indicates, "This message came from 
originating user's site and was sent to recipient at such-and-so time", 
in order to facilitate #4 and #5.

8. The mechanism we use might need to chain: If I send to a mailing list 
A, which itself sends to another mailing list B, the eventual recipient 
will be able to see that the message it got came directly from B, which 
it got from A, which it got from me.

Anything I screwed up there? Any assumption I'm missing?

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Dave Crocker <[email-masked]>
Date: Fri, 18 Apr 2014 12:10:46 -0700

> the originating user's site.

Mailing lists can cascade.

An easy example is for a group to have a single subscription, but to use 
an address that, itself, is a 'local' mailing list.  This can be 
elaborated where there is a hierarchy of groups, such as:

    [email-masked]

    everyone -> sales, marketing, ops, engineering

    sales -> west coast region, east coast...

and so on.

The model needs to work for sequences of mailing lists.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Theodore Ts'o <[email-masked]>
Date: Fri, 18 Apr 2014 15:20:04 -0400

On Fri, Apr 18, 2014 at 01:43:51PM -0500, Pete Resnick wrote:
> These ideas about mailing lists have been rattling around in my head these
> past couple of days, and they're based on a bunch of design assumptions. So
> I figured I'd post my list of assumptions and see if anybody thought any of
> them were off in space.
> 
> 1. The mailing list itself is going to have to participate in this in some
> way. There's no point in trying to design something for mailing lists that
> simply will not make any modifications.

We need to answer the question, explicitly, about whether or not the
sites which are currently honoring the DMARC p=reject policy can be
assumed to adopt whatever we come up with.  Because if the answer is
no, then your assumption/requirement #2 is flat-out impossible:

> 2. In the end, we want mailing lists to be able to send messages that say
> "From: [email-masked]" and not have to say "From:
> [email-masked]".

Because if originatingdomain.example.com still has a DEMARC p=rejet
policy, and there are sites that will be continuing to honor that
policy, then assumption/requirement #2 is going to result in huge
problems (just as we have huge problems today).

And even if eventually all of the DMARC p=reject sites (both the ones
setting the p=reject policy, and those that are honoring the p=reject
policy) will eventually climb on board, there is still the transition
window period that needs to be considered.

What I'm currently thinking about hacking together is a scheme where
the mailing list server will rewrite the from field to something like
this:

From: [email-masked]

.... where dmark-remediation.mailing-list.org is an MX record to an
automated bounce server that will explain to the user that they need
to really send their e-mail to [email-masked] via
a 550 error.

That's because I'm assuming that the DMARC sites are going to be
intransigent, at least in the short term, so at least for some period
of time, possibly forever, I'm going to need to work around sites such
as yahoo.com.

If we go down this path as a long-term solution, as opposed to just a
short-term hack, we could imagine MUA's doing automated rewriting of
the from field to handle replies, and automatic address book
population.  Yes, it's an architectural hack, but so are NAT boxes,
and see how long they have lasted....

					- Ted

---

From: Dave Crocker <[email-masked]>
Date: Fri, 18 Apr 2014 12:27:13 -0700

> no, then your assumption/requirement #2 is flat-out impossible:

Clearly the broadening of DMARC's application is motivating the current 
discussion.

However I believe the technical issues that Pete and others are pursuing 
does not depend upon DMARC and can have benefits beyond it.

As such, I suggest the focus be on basic issues and benefits, rather 
than putting DMARC into the critical path.

d/

---

From: Jim Fenton <[email-masked]>
Date: Fri, 18 Apr 2014 12:38:11 -0700

> Anything I screwed up there? Any assumption I'm missing?

I'm not seeing where it addresses bad actors posing as mailing lists.
Dealing with that problem probably involves signatures and reputation
systems tied to the signers (probably at the domain level). I can't
think of a way around that.

-Jim

---

From: Pete Resnick <[email-masked]>
Date: Fri, 18 Apr 2014 14:45:26 -0500

That's what I meant by 8:

> 8. The mechanism we use might need to chain: If I send to a mailing 
> list A, which itself sends to another mailing list B, the eventual 
> recipient will be able to see that the message it got came directly 
> from B, which it got from A, which it got from me.

pr

---

From: Pete Resnick <[email-masked]>
Date: Fri, 18 Apr 2014 14:49:31 -0500

> I'm not seeing where it addresses bad actors posing as mailing lists.

Are you worried about me sending to a bad actor and that bad actor 
re-sending my message plus or minus some modifications to my message? 
That's what I was trying to capture with 4:

> 4. If an originating site allows its users sending mail to mailing 
> lists at all, the site is OK with *any* mailing list re-distributing 
> mail from its users. so long as the mailing list received the mail 
> directly from the originating user through the originating site. That 
> is, originating sites don't care about pre-vetting mailing lists; they 
> just care that the mail sent by mailing lists came directly from their 
> users.

So, if you get mail that says "From: [email-masked]" and was 
sent by "[email-masked]", *and it has the appropriate 
token*, you know that I sent mail to [email-masked]. Do 
you think we need to address more than that?

pr

---

From: Pete Resnick <[email-masked]>
Date: Fri, 18 Apr 2014 14:55:37 -0500

On 4/18/14 2:20 PM, Theodore Ts'o wrote:
> assumed to adopt whatever we come up with.

There may be sending sites that do *not* want their mail redistributed 
through mailing lists, or at least don't want their mail redistributed 
through mailing lists that don't support whatever the nifty new 
mechanism is. They'll want to say, "If you didn't get it directly from 
me, it went someplace it wasn't supposed to go." As goofy as I think 
that is, I am perfectly OK with the semantics of "p=reject" staying the 
same for those sites, and for receivers to honor "p=reject" by bouncing 
that email.

pr

---

From: Jim Fenton <[email-masked]>
Date: Fri, 18 Apr 2014 13:00:45 -0700

On 4/18/14 12:49 PM, Pete Resnick wrote:
>> is, originating sites don't care about pre-vetting mailing lists;
>> they just care that the mail sent by mailing lists came directly from
>> their users.
>
> So, if you get mail that says "From: [email-masked]" and
> was sent by "[email-masked]", *and it has the
> appropriate token*, you know that I sent mail to
> [email-masked]. Do you think we need to address more
> than that?

I hadn't fully understood how the token thing worked. That probably
addresses the most basic part of my concern (that bad actors could
simply invent messages that looked like they were sent to mailing
lists). But these days, it's not much of an effort, using malware, for a
bad actor to get a user in some domain to send a message to an arbitrary
address. Then the bad actor has a token, and can use it for their campaign.

That particular attack might be declared out-of-scope, but I want to
point it out.

-Jim

---

From: Dave Crocker <[email-masked]>
Date: Fri, 18 Apr 2014 13:06:54 -0700

>> from B, which it got from A, which it got from me.

ok.  the language preceding it was so precise, it excluded this case, 
but it's fine to defer wordsmithing.

d/

---

From: [email-masked]
Date: Fri, 18 Apr 2014 20:26:12 +0000

On Fri, Apr 18, 2014 at 02:55:37PM -0500, Pete Resnick wrote:
> There may be sending sites that do *not* want their mail
> redistributed through mailing lists, or at least don't want their
> mail redistributed through mailing lists that don't support whatever
> the nifty new mechanism is. They'll want to say, "If you didn't get
> it directly from me, it went someplace it wasn't supposed to go." As
> goofy as I think that is, I am perfectly OK with the semantics of
> "p=reject" staying the same for those sites, and for receivers to
> honor "p=reject" by bouncing that email.
> 

So you're OK with mailing list administrators telling yahoo.com users,
if you want to continue participating on this mailing list, you'll
have to change e-mail providers?

There has already been one DMARC cheerleader saying he would stop
supporting to non-profit organizations who would do that, so that's
putting the mailing list administrators of non-profit organizations in
an impossible situation.

Those of us who are in that situation will need some forum to discuss
what's the least disruptive way to the Internet mail architecture to
address our needs.  If that's not [email-masked], that's fine, but
this _is_ a real life problem that is not going away.  25% of the
governing board of my church are yahoo.com users.  I'm not sure I can
tell them all that they have to switch to gmail.com.

     	      	   	     	       - Ted

---

From: Pete Resnick <[email-masked]>
Date: Fri, 18 Apr 2014 15:33:24 -0500

> have to change e-mail providers?

So let's get all of the assumptions straight here. You're talking about 
one of two scenarios:

1. Yahoo adopts the new mechanism, but the mailing list administrator is 
unwilling to adopt the new mechanism, and Yahoo continues to say, "If 
mail didn't come directly from me or have the magic mailing list token, 
p=reject".

2. Yahoo is unwilling to adopt the new mechanism, whatever the mailing 
list administrator wants to do, and Yahoo continues to say, "If the mail 
didn't come directly from me, p=reject".

Yes, in both of those cases, I'm OK with those MLs bouncing the mail and 
MLAs telling yahoo.com users to go switch.

pr

---

From: [email-masked]
Date: Fri, 18 Apr 2014 20:38:09 +0000

On Fri, Apr 18, 2014 at 03:33:24PM -0500, Pete Resnick wrote:
> So let's get all of the assumptions straight here. You're talking
> about one of two scenarios:
> 
> 1. Yahoo adopts the new mechanism, but the mailing list
> administrator is unwilling to adopt the new mechanism, and Yahoo
> continues to say, "If mail didn't come directly from me or have the
> magic mailing list token, p=reject".
> 
> 2. Yahoo is unwilling to adopt the new mechanism, whatever the
> mailing list administrator wants to do, and Yahoo continues to say,
> "If the mail didn't come directly from me, p=reject".
> 
> Yes, in both of those cases, I'm OK with those MLs bouncing the mail
> and MLAs telling yahoo.com users to go switch.

or....

3.  It's going to take months or years to come up with a new
specification and to get it deployed, and in the mean time, there will
be people who don't have the luxury of waiting for Godot.

Basically, there will be people who need a short-term fix, and are we
really satisified with the Mailman:

From: Pete Resnick <[email-masked]>

workaround?

I know I'm not....

					- Ted

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Fri, 18 Apr 2014 21:38:37 +0100

On 18 Apr 2014, at 19:43, Pete Resnick <[email-masked]> wrote:
> 3. If an originator sends mail to a mailing list, the originator is implicitly giving permission for the list to re-distribute the message "From:" the originator.
> 
> 4. If an originating site allows its users sending mail to mailing lists at all, the site is OK with *any* mailing list re-distributing mail from its users. so long as the mailing list received the mail directly from the originating user through the originating site. That is, originating sites don't care about pre-vetting mailing lists; they just care that the mail sent by mailing lists came directly from their users.

I think these two points are understated.  Even if you are a free mail provider like the one that has got so much attention recently, surely your reputation isn't helped by a single malicious message sent to a single malicious mailing list, that now has the power to make the provider's life extremely miserable when it is ruthlessly and swiftly mass-mailed without the provider's authorisation or infrastructure?

Cheers,
Sabahattin

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Fri, 18 Apr 2014 21:04:06 +0000

> -----Original Message-----
> From: ietf-822 [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Friday, April 18, 2014 4:26 PM
> To: Pete Resnick
> Cc: [email-masked]
> Subject: Re: [ietf-822] Mailing lists - assumptions
> 
> > that is, I am perfectly OK with the semantics of "p=reject" staying
> > the same for those sites, and for receivers to honor "p=reject" by
> > bouncing that email.
> >
> 
> So you're OK with mailing list administrators telling yahoo.com users, if you
> want to continue participating on this mailing list, you'll have to change e-mail
> providers?
> 
> supporting to non-profit organizations who would do that, so that's putting
> the mailing list administrators of non-profit organizations in an impossible
> situation.
> 

Ted, you really do seem to have a propensity for putting words in other people's mouths. The assertion made was to send a NASTY email to the list participants, not simply a polite email explaining that there is a problem and one or more possible remedies. The latter is a reasonable method of explaining a situation not caused by the list operator itself. The former is attempting to coerce the list user into a campaign to force Yahoo to change its practices (which was what was explicitly stated). 

There is a distinct difference between the two approaches. If an organization I support, whether they do it knowingly or because the person or organization that manages their mailing lists decides to make such a decision (without advising management) to send me a nasty email intended to coerce me to do anything (doesn't have to be just about switching mailbox providers), of course I am going to withdraw support. I would fully expect others to feel along the lines I do. To be blunt, people (end users) don't particularly care about your impossible situation as a list administrator. It is your job to figure out the least intrusive way of dealing with the situation and of course, to communicate with the impacted users politely and where possible providing them options. This is not specific to the Yahoo DMARC implementation issue, that is the real world. You are focused on solving your problem (and crusade) and not necessarily theirs.

> Those of us who are in that situation will need some forum to discuss what's
> the least disruptive way to the Internet mail architecture to address our
> needs.  If that's not [email-masked], that's fine, but this _is_ a real life
> problem that is not going away.  25% of the governing board of my church are
> yahoo.com users.  I'm not sure I can tell them all that they have to switch to
> gmail.com.
> 
>      	      	   	     	       - Ted
> 
> _______________________________________________
> ietf-822 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-822

---

From: Theodore Ts'o <[email-masked]>
Date: Fri, 18 Apr 2014 17:08:39 -0400

On Fri, Apr 18, 2014 at 09:04:06PM +0000, MH Michael Hammer (5304) wrote:
> 
> There is a distinct difference between the two approaches. If an
> organization I support, whether they do it knowingly or because the
> person or organization that manages their mailing lists decides to
> make such a decision (without advising management) to send me a
> nasty email intended to coerce me to do anything (doesn't have to be
> just about switching mailbox providers), of course I am going to
> withdraw support. I would fully expect others to feel along the
> lines I do. To be blunt, people (end users) don't particularly care
> about your impossible situation as a list administrator. It is your
> job to figure out the least intrusive way of dealing with the
> situation and of course, to communicate with the impacted users
> politely and where possible providing them options. This is not
> specific to the Yahoo DMARC implementation issue, that is the real
> world. You are focused on solving your problem (and crusade) and not
> necessarily theirs.

All of the short-term workarounds will negatively impact the yahoo.com
user somewhat.  (It is because of the negative impact that I think
it's best if the workaround is deployed only if the recipient has a
DMARC p=reject policy, as opposed to being inflicted on all of the
mailing list recipients.)

If they don't like that negative impact, the only thing thing I can
tell them is to use another e-mail provider, or to lobby yahoo.com to
chainge their policies.  If that happens to negatively impact
yahoo.com, I can't say that I would be sorry.

Regards,

						- Ted

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Fri, 18 Apr 2014 21:19:25 +0000

> From: Theodore Ts'o [mailto:[email-masked]]
> Sent: Friday, April 18, 2014 5:09 PM
> To: MH Michael Hammer (5304)
> Cc: Pete Resnick; [email-masked]
> > make such a decision (without advising management) to send me a nasty
> > email intended to coerce me to do anything (doesn't have to be just
> > about switching mailbox providers), of course I am going to withdraw
> > support. I would fully expect others to feel along the lines I do. To
> > be blunt, people (end users) don't particularly care about your
> > impossible situation as a list administrator. It is your job to figure
> > out the least intrusive way of dealing with the situation and of
> > course, to communicate with the impacted users politely and where
> > possible providing them options. This is not specific to the Yahoo
> > DMARC implementation issue, that is the real world. You are focused on
> > solving your problem (and crusade) and not necessarily theirs.
> 
> All of the short-term workarounds will negatively impact the yahoo.com user
> somewhat.  (It is because of the negative impact that I think it's best if the
> workaround is deployed only if the recipient has a DMARC p=reject policy, as
> opposed to being inflicted on all of the mailing list recipients.)
> 
> If they don't like that negative impact, the only thing thing I can tell them is to
> use another e-mail provider, or to lobby yahoo.com to chainge their policies.
> If that happens to negatively impact yahoo.com, I can't say that I would be
> sorry.
> 

You are singing a different tune (at least in tone) than in your earlier posts.

---

From: Miles Fidelman <[email-masked]>
Date: Fri, 18 Apr 2014 17:23:44 -0400

One assumption that hasn't been stated is the basic one:

"If I send mail, I expect it to be delivered" - modulo the understanding 
that (e)mail is an unreliable medium and will sometimes get lost.

It kind of breaks a basic assumption if users are now in a position of 
"if I send mail, it might get delivered, maybe, if my email provider 
decides that it's appropriate."

Miles Fidelman

-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra

---

From: Jim Fenton <[email-masked]>
Date: Fri, 18 Apr 2014 14:43:41 -0700

On 4/18/14 1:26 PM, [email-masked] wrote:
> 25% of the

I wouldn't tell them to switch to GMail, or any other big provider
they'd be tied to. I'd tell them to register domains that they can host
elsewhere (on a big provider if they want) so they can switch providers
if/when needed. Similarly, many users are stuck with ISPs they dislike
because that's where their email address is hosted.

DMARC is just one example of how an email provider can do something that
makes some people unhappy. People need to be able to "vote with their feet".

-Jim

---

From: Theodore Ts'o <[email-masked]>
Date: Fri, 18 Apr 2014 18:01:57 -0400

> because that's where their email address is hosted.

Unfortunately, that's beyond the technological capabilities of many
people....  if there was a really easy, and relatively cheap, way to
do this, I'd recommend it without hesitation.

Some universities offer their alumni "email forwarding for life".
That's a solution that would work for some.  Unfortunately, not for
the less technically savvy.

						- Ted

---

From: Ned Freed <[email-masked]>
Date: Fri, 18 Apr 2014 19:40:02 -0700 (PDT)

> than putting DMARC into the critical path.

Quite right. There may be value in having a way of attaching these sorts of, I
guess I'll call them recipient semantics, to originator signatures independent
of their ability to address the current DMARC mess.

Realistically, this work isn't going to happen on a time scale to make
it viable as a response to what Yahoo has done. Any such ship will already
have sailed.

				Ned

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 19 Apr 2014 11:49:06 +0200

> problems (just as we have huge problems today).

Perhaps it would suffice to have DMARC define alignment in terms of
the From: domain /or/ the To: domain.  That would assume that any
recipient can redistribute the mail it receives, leaving copyright
questions to lawyers.  In fact, "To:" is as visible as "From:".

> to really send their e-mail to [email-masked] via

Oh well, it is easier, clearer, and safer to have

   From: [email-masked]

and let submission servers issue that 550 directly.

Ale

---

From: Paul Smith <[email-masked]>
Date: Sat, 19 Apr 2014 11:12:35 +0100

> From: Pete Resnick <[email-masked]>
OK - devil's advocate here...

Why not?

It doesn't really bother me. In many cases, I'd actually like it, as it 
wouldn't be publishing my email address to all and sundry.

If it's a big problem in some cases, could the original sender by put in 
another header, or could RESENT- fields be used, or could the From 
address be munged (From: Pete Resnick 
<[email-masked]> )?

-

Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

---

From: Michael Richardson <[email-masked]>
Date: Sat, 19 Apr 2014 08:56:26 -0400

> no, then your assumption/requirement #2 is flat-out impossible:

There will be some adoption, and perhaps some sites that will not adopt.
I care about the next 10 sites that want to turn on p=reject, not the one
that already did it.  While I'd like those sites to adopt, for me as a
mailing list admin,  there is a serious win if I can reduce the amount of
spam that goes into the moderation queue.

    > to really send their e-mail to [email-masked] via

I understand that you might want to do this in your context, and I accept
that it might work for you. But I don't want to do this for @ietf.org lists,
for instance, I want @ietf.org lists to honour p=reject, and reject the
message immediately.

    > and see how long they have lasted....

If we can assume any changes to the MUA, let's assume that they make sensible
changes that we document.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Sat, 19 Apr 2014 08:57:48 -0400

> through mailing lists that don't support whatever the nifty new mechanism
    > is. They'll want to say, "If you didn't get it directly from me, it
    > went

Maybe p=reject can replace the stupid "confidential" notices.
Clearly any email on a mailing list with that notice on it, really wanted
p=reject!

---

From: Ned Freed <[email-masked]>
Date: Sat, 19 Apr 2014 08:15:37 -0700 (PDT)

> the less technically savvy.

Alas, it's a solution that interacts poorly with SPF, which is also in the
mix. There are better technical alternatives to address SPF issues with
forwarders than there are to address DKIM issues with mailing lists, but
even so it's not a panacea.

				Ned

---

From: Theodore Ts'o <[email-masked]>
Date: Sat, 19 Apr 2014 11:43:04 -0400

> even so it's not a panacea.

The way alum.mit.edu handles email forwarding for life is they provide
an authenticated submission service for MIT alumni[1].  This handles SPF
and DKIM on the outgoing side, and on the forwarding side, it looks to
the e-mail provider that that an address such as "[email-masked]"
is a mailing list.

[1] https://alum.mit.edu/help/EmailForwardingFAQ

So that means that it's possible to have EFL where the outgoing e-mail
will both pass SPF and DKIM checks.  And better yet, since it's in
MIT's interest to keep their alumni happy (especially those that might
potentially donate a huge amount of money in the future, for a
building or an endowed chair), the financial incentives are relatively
well aligned to keep the service running.  :-)

Actually, in practice, I've not had to use the authenticated
submission service.  Despite that mit.edu and alum.mit.edu has an SPF
soft fail if you don't go through their authenticated e-mail
submission service, I've found that an SPF soft fail combined with an
authenticated DKIM for my envelope return address (for thunk.org,
which I control), is not a problem in practice.  I've not experienced
any problems with my e-mail getting rejected.

					- Ted

---

From: Theodore Ts'o <[email-masked]>
Date: Sat, 19 Apr 2014 11:57:24 -0400

> and let submission servers issue that 550 directly.

The problem is that there might be some receiving servers that will
try to see if the originatingdomain.example.com.INVALID is a valid
domain address, and seeing that it isn't, might reject the e-mail on
that basis.

						- Ted

---

From: "John Levine" <[email-masked]>
Date: 19 Apr 2014 16:26:08 -0000

>think of a way around that.

Agreed.  In my strawman proposal, if the M-R header/token isn't
signed, bad guys could trivially circumvent it by adding a fake token.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 19 Apr 2014 16:39:37 -0000

>That's what I was trying to capture with 4:

The bad actor sends a fake message with a fake return address that
pretends to be you, with a fake token and fake everything else.

The problem is that there are entirely legitimate mail scenarios that
are technically indistinguishable from this, e.g., gmail account
consolidation and WSJ mail an article.  (Well, they wouldn't add a
fake token, but you get the idea.)

The only way I know to tell evil fakes from good ones is to
whitelist the good ones, and since they're technically the
same, you can't run the whitelist mechanically.

R's,
John

---

From: Ned Freed <[email-masked]>
Date: Sat, 19 Apr 2014 11:00:35 -0700 (PDT)

> the e-mail provider that that an address such as "[email-masked]"

This isn't the issue; the issue is what the MAIL FROM address gets set to
when a message is forwarded.

You want any downstream delivery errors to be reported to the original sender,
so ideally you'd leave the MAIL FROM unchanged. But now an SPF check on the
MAIL FROM will fail because alum.mit.edu's IP address isn't going to be 
allowed list.

And if you do something like insert a simple forward, e.g.,
[email-masked], you've just
created an open relay.

The usual way this is solved is with a more complex forwarding address,
one that incorporates a timestamp and a verifier. As I noted 
previously the Sender Rewriting Scheme is one way to do this, but of
course you can use any encoding you want since only your systems have
to understand it.

> ...

> any problems with my e-mail getting rejected.

The SPF policy on alum.mit.edu is not the issue. See above.

				Ned

---

From: Paul Smith <[email-masked]>
Date: Sat, 19 Apr 2014 19:36:53 +0100

> MAIL FROM will fail because alum.mit.edu's IP address isn't going to be

Do you want delivery errors to be reported to the original sender? Are 
you sure?

If I send a message to [email-masked]', do I really want lots of 
delivery errors from random people I've never heard of? Wouldn't it make 
more sense for those delivery errors to be reported to the list 
administrator?

I know we have this problem with our MTA where people send mail to 
[email-masked]', and that user has a forward to a gmail account. It 
confuses the original sender if they receive a delivery failure report 
from Google, because they never sent a message to Google at all. So, we 
normally set things up so the MAIL FROM is changed to go to 
[email-masked]. That way, if a forward is set incorrectly, 
they can sort it out, and the company's contacts don't get confused.

-

---

From: Theodore Ts'o <[email-masked]>
Date: Sat, 19 Apr 2014 14:42:20 -0400

> course you can use any encoding you want since only your systems have

You mean like this:

Return-path: <SRS0=/H55=ZT=gmail.com=[email-masked]>

:-)

Sure, it's a bit ticklish, but it's obviously implementable.

					- Ted

---

From: Ned Freed <[email-masked]>
Date: Sat, 19 Apr 2014 15:06:59 -0700 (PDT)

> Do you want delivery errors to be reported to the original sender? Are

Of course you do. We're talking about a pure autoforwarder here, not
a mailing list. The only mailboxes in the picture are the ones belonging
to the sender and the recipient. Who else does it make sense to report
the problem to?

Mixed situations, like those created by having a sieve-enabled mailbox, are
another matter. There's no hard-and-fast rule for MAIL FROM manipulation that
produces optimum results in all cases.

> more sense for those delivery errors to be reported to the list

Now you're talking about a mailing list, where overriding the MAIL FROM
is always the right answer. Indeed, overriding the MAIL FROM in some
senses the defining characteristics of a mailing list.

In any case, this is different funcitonality than an autoforwarder provides,
with different semantics.

> from Google, because they never sent a message to Google at all.

That's why we have the NOTARY extension and the ORCPT field. Its purpose
is to preserve the original recipient address so it can be presented to
the user when there's a nondelivery.

I also note that the ORCPT field is reset on MAIL FROM changes. Quite a lot of
careful consideration has gone into this design, you know.

> So, we

In the case of a pure autoforwarder operated, say, on behalf of a former
alumnus, who is this magical administrative person who is both willing and
appropriate to see nondelivery notifications containing all or part of the
original message supposed to be?

An anecdote. Back when I was doing the postmaster thing, I was once braced by
an extremely angry user who had received a message from a postmaster at an
intermediate site who had taken it upon themselves to perform the role you're
talking about here. In this instance they forwarded a piece of mail that had
gone awry, but also saw fit to attach their own commentary on the content.
(Amusingly, the postmaster who did this is still around, and is now a very
vocal advocate for Internet privacy. I smile every time I hear the name.)

Trust me, this is not a situation you want to enable.

				Ned

---

From: Pete Resnick <[email-masked]>
Date: Sat, 19 Apr 2014 17:55:16 -0500

> pretends to be you, with a fake token and fake everything else.

Nope, still don't get it. You're going to have to give me an example. 
Let me start you out:

1. I have an account: [email-masked].
2. Yahoo has a policy of that says to reject if the message says it's 
"From: [email-masked]" unless:
     a) it came directly come from a yahoo.com server; or
     b) it came from an "example.net" server and it has a token that 
says it was sent directly from [email-masked] to "[email-masked]".
3. ... [John inserts steps here]
...
n. John get a message from an example.net server that says it's "From: 
[email-masked]", and it has a cryptographically verified token that 
indicates that it was sent directly by [email-masked] from a yahoo.com 
server directly to [email-masked], even though it was just 
example.net faking up my address and using a fake token.

I don't understand how you get there. What does the bad actor do to 
accomplish this?

pr

---

From: "John R Levine" <[email-masked]>
Date: 19 Apr 2014 19:15:51 -0400

> 2. Yahoo has a policy of that says to reject if the message says it's "From: 
> [email-masked]" unless: ...
>    b) it came from an "example.net" server and it has a token that says it 
> was sent directly from [email-masked] to "[email-masked]".

  From: Pete <[email-masked]>
  Subject: all your crypto are belong to us
  To: [email-masked]
  Token: s=[email-masked] l=[email-masked] t=now
  List-ID: kripto.rbn.ru
  DKIM-Signature: --- d=rbn.ru ... (100% genuine and valid)

  IESG is saying that all crypto will to use new improved NKVD-1024
  algorithm.

  Mir,
  Pete

How can you tell the Token: is a fake if it's not signed?  You can't tie 
it to the contents of the message, or you've just reinvented the DKIM hash 
issues.

Since most people have no idea what a discussion list looks like, it's 
just a phish that looks a whole lot like it's from you.

R's,
John

---

From: "John R Levine" <[email-masked]>
Date: 19 Apr 2014 19:18:02 -0400

> [email-masked]", and it has a cryptographically verified token that indicates 
> that it was sent directly by [email-masked] from a yahoo.com server directly 
> to [email-masked], even though it was just example.net faking up my 
> address and using a fake token.

Now I'm really confused.  Untill a few minutes ago I was saying the token 
has to be signed, and you were (as far as I can tell) saying it doesn't. 
Now we seem to agree.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Ned Freed <[email-masked]>
Date: Sat, 19 Apr 2014 15:33:52 -0700 (PDT)

Yes indeedy. Looks to me like bog-standard SRS.

> Sure, it's a bit ticklish, but it's obviously implementable.

Indeed. But now that we've gotten this far, here's a question...

Given that this issue is a forseeable - and forseen - consequence of using SPF,
and given there's an effective, but not exactly obvious, solution to the
problem, why are we going forward with publication of SPFBIS as a proposed
standard (currently in AUTH48) without a companion document describing this
problem and at least the corresponding solution space, if not going so far as
to document a specific solution?

At present draft-ietf-spfbis-4408bis has this to say about the issue:

 o  Mediators can solve the problem by rewriting the "MAIL FROM" to be
    in their own domain.  This means mail rejected from the external
    mailbox will have to be forwarded back to the original sender by
    the forwarding service.  Various schemes to do this exist though
    they vary widely in complexity and resource requirements on the
    part of the mediator.

Does anyone seriously think this provides the necessary guidance to an
autoforwarder developer/administrator faced with wholesale rejection of their
forwarded mail due to SPF? Because I certainly don't.

				Ned

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 19 Apr 2014 20:38:38 -0400

On Saturday, April 19, 2014 15:33:52 Ned Freed wrote:
> > > You want any downstream delivery errors to be reported to the original
> > > sender, so ideally you'd leave the MAIL FROM unchanged. But now an SPF
> > > check on the MAIL FROM will fail because alum.mit.edu's IP address
> > > isn't going to be allowed list.
> > > 
> Given that this issue is a forseeable - and forseen - consequence of using
> SPF, and given there's an effective, but not exactly obvious, solution to
> the problem, why are we going forward with publication of SPFBIS as a
> proposed standard (currently in AUTH48) without a companion document
> describing this problem and at least the corresponding solution space, if
> not going so far as to document a specific solution?
> 
> autoforwarder developer/administrator faced with wholesale rejection of
> their forwarded mail due to SPF? Because I certainly don't.

Since whatever scheme is used for rewriting Mail From only matters locally, 
there's not a lot more to say from an interoperability perspective.  We 
discussed this in the working group and concluded that was sufficient.

If someone feels a need for more specification of exactly how to do that, then 
I think they ought to write a draft specifying how to do SRS and get it 
published.  Throwing another roadblock in front of 4408bis now is not the 
right way to handle it.

It's also unrelated to the DMARC/mailing list problem (in most cases).  
Generally mailing list managers use their own mail from, so the original 
senders SPF doesn't enter into it.  SPF only gets mixed in due to DMARC 
insisting on identity alignment.  That's nothing to do with SPF.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 20 Apr 2014 01:39:51 -0000

>Yes indeedy. Looks to me like bog-standard SRS. ...

>forwarded mail due to SPF? Because I certainly don't.

Nobody brought it up in SPFBIS that I can recall.  SRS has been around
for a decade, and I only see it in a few academic mail forwarders and
one web host's mail gateway.  The problem that SRS solves evidently
isn't one that people care enough about very much.

R's,
John

---

From: S Moonesamy <[email-masked]>
Date: Sat, 19 Apr 2014 19:44:45 -0700

Hi Ned,
>to document a specific solution?

The document is moving forward because that is what the IETF agreed 
to.  I suggest discussing the matter with Pete Resnick as soon as 
possible if there is a serious issue that has been missed.

This is from https://help.yahoo.com/kb/mail/SLN24016.html

   'This means all DMARC compliant mail receivers (including Yahoo, Hotmail,
    and Gmail) are now bouncing emails sent as "@yahoo.com" addresses that
    aren't sent through Yahoo servers. Any messages without a proper Domain
    Keys Identified Mail (DKIM) signature or Sender Policy Framework (SPF)
    alignment will be rejected.

    ESPs who use their customers' "@yahoo.com" address as the "From" address
    to send messages are impacted by this change.'

People might read the about as messages which pass DKIM or SPF will 
not be rejected.  That's not what those mail receivers are doing.

Some of the suggestions in the different threads have been to do:

   (a) Address rewrites of the Return-Path

   (b) Address rewrites of the "From:" header

Taken together, the suggestions make matters worse in my opinion.

Regards,
S. Moonesamy

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 19 Apr 2014 23:45:33 -0400

>not be rejected.  That's not what those mail receivers are doing.

Right. I think it bears repeating for emphasis that the current Yahoo! DMARC mess is unrelated to issues with SPF as defined in either RFC 4408 or 4408bis.

Typical MLM managed lists send messages that pass SPF for the list's domain (which is typically what is found in Mail From).  Conceptually this is somewhat similar to the list adding it's own DKIM signature. Both pass/verify for SPF/DKIM, but neither are aligned to the From, so DMARC calls them a fail.

SPF and transparent forwarding is an issue, but not this one. 

Scott K

---

From: Hector Santos <[email-masked]>
Date: Sat, 19 Apr 2014 23:58:18 -0400

> SPF and transparent forwarding is an issue, but not this one.

Right. Scott, can you confirm my understanding of the DMARC policy 
yahoo.com has and how does it describes any tight alignment?

     "v=DMARC1;
        p=reject;
        sp=none;
        pct=100;
        rua=mailto:[email-masked],
            mailto:[email-masked];"

According to this, there is no strict alignment.  The default 
alignment is relaxed adkim=r aspf=r.

So doesn't this say?

     "All mail from YAHOO.COM must be signed, but we don't care who.
      If its not signed, reject it."

Why would transactions from a yahoo.com subscriber to yahoo.com 
subscribers get rejected, for example, with these data bits:

     5321.FROM FROM:      [email-masked]
     5321.RCPT TO:        [email-masked]
     5322.From:           [email-masked]
     5322.DKIM-Signature: d=winserver.com

The reject response is:

     5.7.9 Message not accepted for policy reasons.
           See http://postmaster.yahoo.com/errors/postmaster-28.html

Where is the alignment requirement description for when only p=reject 
is used?

-- 
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 20 Apr 2014 00:17:26 -0400

On Saturday, April 19, 2014 23:58:18 Hector Santos wrote:
> > Right. I think it bears repeating for emphasis that the current Yahoo!
> > DMARC mess is unrelated to issues with SPF as defined in either RFC 4408
> > or 4408bis.
> > 
> > Typical MLM managed lists send messages that pass SPF for the list's
> > domain (which is typically what is found in Mail From).  Conceptually
> > this is somewhat similar to the list adding it's own DKIM signature. Both
> > pass/verify for SPF/DKIM, but neither are aligned to the From, so DMARC
> > calls them a fail.
> > 

No.  Not at all.

> Where is the alignment requirement description for when only p=reject

See section 3.1.4 of the current DMARC draft.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Sun, 20 Apr 2014 00:59:09 -0400

> See section 3.1.4 of the current DMARC draft.

Got it. I see the problem.  DMARC by definition requires alignment for 
matching domains. An adkim=s (strict) is an exact match and adkim=r 
(relaxed) means sub-domains are allowed.

 From what I see, there is no 3rd party allowance and the only things 
that saves you is p=none or p=quarantine.

This will need an extension if the DMARC draft is locked down. 
Section 3.1.4.3 talks about authentication extensions:

    3.1.4.3.  Alignment and Extension Technologies

    If DMARC is extended to include the use of other authentication
    mechanisms, the extensions will need to allow for domain identifier
    extraction so that alignment with the RFC5322.From domain can be
    verified.

This would be a simple first step consideration -- A new ATPS tag

   atps=0  default, extension disabled allowed backward compatibility.
   atps=1  Valid alignment allows a valid 3rd party signature.
   atps=2  Valid alignment allows a valid 3rd party signature with ATPS
           (Authorized 3rd Party Signer) checking, RFC6541.

atps=1 basically declares a relaxed MUST SIGN policy.  atps=2 means 
the 3rd party signer must be authorized using RFC6541.

Lets go further using Pete's idea:

   atps=3  Valid alignment allows a valid 3rd party signature using
           the May-Resign header/token.

-- 
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 20 Apr 2014 01:14:06 -0400

> that saves you is p=none or p=quarantine.

Yes.  As currently defined, p=reject is only suitable for some classes of 
domains and the current mess is because yahoo.com isn't in one of those 
classes.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Sun, 20 Apr 2014 01:51:28 -0400

> domains and the current mess is because yahoo.com isn't in one of those

I don't agree that yahoo.com isn't one and neither does Yahoo.   Yes, 
it is a long time polluted and publicly used email domain but it was 
only because of a lack of method to check all the bad stuff. Millions 
of other domains are in the same boat, such as my santronics.com corp 
domain.  Its very "polluted."

 From my standpoint, all domains must be treated the same with any 
protocol, and the solution is not to think yahoo or any other domain 
can not be an user of the protocol.   That was the mistake belief with 
ADSP, trying to define "classes" of domains and exclude other 
"classes" for strong policy considerations and it took YAHOO to do it 
via DMARC to show that.  Their domain was way too polluted.  It was 
time to do this.  I expect an avalanche of private and public domains 
increasing their security value using DKIM + POLICY, in this case with 
DMARC.

But it still needs 3rd party "classes" of policies semantics to make 
it work right across the board.  We are going to go right back to the 
ultimate consensus of the main problems with 3rd party controls, 
namely scalability and manageability.   We need to see if ATPS can 
work, at least for a majority (80%) of the domains.  Yahoo said 
something about 30,000 mailing list and their yahoo.com users??  Well, 
can they manage 30,000 ATPS records?  Can DNS?

-- 
HLS

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 20 Apr 2014 11:39:42 +0200

> domain address, and seeing that it isn't, might reject the e-mail on

Exactly.  Why is that a problem?  Upon rejection the user will notice
the ".INVALID" and remove it, just like he or she would have done if the
rejection had arrived from dmarc-remediation.  The latter could have
contained a pointer to an explanation page, which interested users may
also find with google.

Ale

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 20 Apr 2014 13:02:31 +0200

On Sun 20/Apr/2014 01:18:02 +0200 John R Levine wrote:
> Now I'm really confused.  Untill a few minutes ago I was saying the
> token has to be signed, and you were (as far as I can tell) saying it
> doesn't. Now we seem to agree.

Signed by who?

Let me copy the exemplified token below:

   May-Resign: f=[email-masked]; r=ietf.org; s=foo; a=rsa-sha256; \
      t=1397786669; b=hashhashhash

There is an implied d=yahoo.com there, used to recover the key.  Since
the key is published by yahoo.com, we can regard the token as signed by
them.

Note that using such token (or an equivalent signature) disallows known
tricks such as posting as another subscriber --unless both subscribers
belong to a same domain which allows changing From: liberally.

Ale

---

From: Theodore Ts'o <[email-masked]>
Date: Sun, 20 Apr 2014 07:28:42 -0400

> contained a pointer to an explanation page, which interested users may

User "[email-masked]" sends mail to a mailing list which rewrites his
from field to be "[email-masked]".  When his post gets sent to
"[email-masked]", hotmail.com could decide to bounce the
message because the from field is invalid.  And then just as in the
case of DMARC-induced lossage, this counts towards [email-masked]'s
bounce count, and [email-masked] could end up getting her
membership to the mailing list suspended.

If you change the from field to
"[email-masked]", that's a valid
from field address, and reduces the chances that the receiving host
will bounce the message.

Part of the problem here is that mail can get bounced for many reasons
--- the user's inbox could be full, the recipient could be honoring a
DEMARC p=reject policy, it could just be the wrong time of month for
the mailer.  We could try to add some additional error codes that
indicate that the problem is not the recipient's inbox, but rather
that the incoming sender's from field, or SPF, or DKIM, or some other
arbitrary problem which is not specific to the recipient which is
causing the problem.  If we had that, then the mailing list could much
more easily decide that the right thing to do is to send the bounce
mail back to [email-masked], instead of having potentially
autosuspending [email-masked]'s mailing list service.  Of course,
then if [email-masked] is subscribed to a mailign list with hundreds of
addresses that are all playing the DEMARK p=reject game, it might not
be pretty for [email-masked]'s inbox....

						- Ted

---

From: Hector Santos <[email-masked]>
Date: Sun, 20 Apr 2014 10:01:52 -0400

Using .INVALID is a bad idea.  As enticing as it may sound as a vain 
attempt to counteract what Yahoo did, don't you think they will adjust 
to it?

The bad guys can easily just add .invalid believing some sites will 
actually do policy lookups blindly and just say "Oh, no policy, continue."

Whats to stop a receiver from removing this new "popular" .invalid 
appendage for lookup purposes and still find that the policy is 
restrictive?

   if 5322.From has ".invalid" then
      Strip it and do a Policy Check on the remaining domain.

We are really going in the wrong direction if we have to begin to 
defeat new security protocols by changing the 5322.From field and now, 
probably too late now since this cat's out of the bag, begin to watch 
for ".invalid" to see if bad guys took the idea seriously and began to 
use it.

Keep in mind it also means that you have to stop resigning the mail 
too or is this new adjusted .invalid from including a new resigner bind?

Can we also get into trouble with double 5322.From exploits now with a 
new "unethical" willingness to tamper with this important header, 
probably the only one remaining in 5322 that is most important to have 
correct with some higher degree of confidence and trust.

-- 
HLS

---

From: "John Levine" <[email-masked]>
Date: 20 Apr 2014 14:23:16 -0000

>from field address, and reduces the chances that the receiving host

Right, and now we're training users to believe that
"[email-masked]" is equivalent to
[email-masked].  Maybe their MUAs will even help.

This is the arms race you referred to before, no?

Also see Ned's note about why attempting to validate the From: line
domain is a bad idea.

R's,
John

---

From: Pete Resnick <[email-masked]>
Date: Sun, 20 Apr 2014 10:32:38 -0500

> doesn't. Now we seem to agree.

No, you must have misunderstood. I always agreed that the token had to 
be signed. I only disagreed that there had to be some sort of 
"re-signing" of the original message, or that anything that the 
originator sent needs to sent, unmolested, to the list recipients. Once 
the originator has sent the message with its token to the list, the list 
will be able to forward the token (or some modification of the token) 
such that the eventual recipient can cryptographically verify that:

1. The message came arrived directly from the list's server (e.g., using 
DKIM with the list's server).
2. The token in the message indicates that the list got the message 
directly from the originator's server.

pr

---

From: "John R Levine" <[email-masked]>
Date: 20 Apr 2014 12:14:38 -0400

> No, you must have misunderstood. I always agreed that the token had to be 
> signed. I only disagreed that there had to be some sort of "re-signing" of 
> the original message, or that anything that the originator sent needs to 
> sent, unmolested, to the list recipients.

Oh, no argument there.  The list (or whatever) signs what it sends, 
including the token.  A sufficiently malicious forwarder could screw it up 
but we appear to agree that either we don't think that it's a problem, or 
it's not a problem we can solve.

If it actually is a problem, we're back to whitelisting mailing lists and 
mailing list like things, and all the other mechanism other than perhaps 
VBR to hint about where to look for the whitelist is superfluous.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Sun, 20 Apr 2014 15:57:18 -0400

On 4/20/2014 12:14 PM, John R Levine wrote:
>
> If it actually is a problem, we're back to whitelisting mailing lists
> and mailing list like things, and all the other mechanism other than
> perhaps VBR to hint about where to look for the whitelist is superfluous.

Update DMARC with the following extension (see 3.1.4.3. Alignment and 
Extension Technologies):

   vbr=1  Check VBR (RFC5518) for valid 3rd party alignments

You have to support POLICY first before we finally come close to 
resolving this for trust.  Via Policy, we must give all mail system 
components the expected protocol logic necessary to gracefully handle 
all this.

-- 
HLS

---

From: Ned Freed <[email-masked]>
Date: Sun, 20 Apr 2014 21:32:47 -0700 (PDT)

> possible if there is a serious issue that has been missed.

You're missing my point. I wasn't proposing that SPFBIS publication be delayed
until this issue could be addressed - although a case can definitely be made
for that. 

Rather, I was pointing out that we should not assume that the failure to
clearly document known interoperability issues (and like it or not, that's what
they are) didn't start with DMARC. A similar, albeit more easily addressed one,
exists in SPFBIS.

OTOH, assuming that this problem is universal is also incorrect. An obvious
counterexample from the same general area is the RRVS specification now in IESG
evaluation. A veritable cornucopia of issues have been raised, some IMO pretty
picayune, a significant number of which have led to the addition of significant
amounts of new text to the document.

I don't know what distinguishes the specifications where such things  end up
documented from ones where they don't, but I suspect a number of factors are in
play. What I do know is we have a problem we need to address.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Sun, 20 Apr 2014 22:17:08 -0700 (PDT)

> isn't one that people care enough about very much.

Well, I don't claim to speak for the Internet, but there's been a fair bit
of interest in the SRS support we provide in our product... And that's
from my perspective; I only hear about what people are using when they
have a problem setting it up, find a bug, etc.

				Ned

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Fri, 25 Apr 2014 23:57:20 +0200

> of their ability to address the current DMARC mess.

I'd suggest to extend this list of assumptions/work-to-do to other 
scenario's like Johns 'WSJ mail an article' example and other use cases 
which are common on the Internet.

/rolf

---

From: Miles Fidelman <[email-masked]>
Date: Fri, 25 Apr 2014 18:01:07 -0400

Somebody have a wiki where we can set up a list of requirements and use 
cases to drive things forward?

Miles Fidelman

Rolf E. Sonneveld wrote:
> scenario's like Johns 'WSJ mail an article' example and other use 
> cases which are common on the Internet.
>
> /rolf
>

---

From: Jan Kundrát <[email-masked]>
Date: Sat, 26 Apr 2014 13:07:11 +0200

On Saturday, 26 April 2014 00:01:07 CEST, Miles Fidelman wrote:
> Somebody have a wiki where we can set up a list of requirements 
> and use cases to drive things forward?

I'm sure Timo wouldn't mind if you use http://imapwiki.org/ .

With kind regards,
Jan

-- 
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

---

From: "John Levine" <[email-masked]>
Date: 26 Apr 2014 13:33:37 -0000

>cases to drive things forward?

The ASRG wiki is still around and seems cruelly appropriate.

Drop me a note and I'll give you a login.

R's,
John