Subject: [ietf-dkim] On changing From: when sending through lists

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 1 Aug 2010 15:43:39 -0700

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Daniel Black
> Sent: Thursday, July 29, 2010 5:15 AM
> To: [email-masked]
> Subject: Re: [ietf-dkim] Alternative MAiling List Approach
> 
> On Thursday 29 July 2010 21:21:41 Charles Lindsey wrote:
> > I promised to do this some while back, but only just got a round
> tuit.
> >
> 
> Ah the mythical round tuit.
> 
> I put a similar idea through when once I had a round tuit. Feel free to
> follow
> the threads.
> http://mipassoc.org/pipermail/dkim-dev/2009-September/000202.html

This makes at least the third time this has been suggested by someone.  I believe (though I'm willing to be corrected) that the draft should therefore cover this possibility and either advocate it or explain why it's a bad idea.  The latter is acceptable; the material is on-topic, and we're trying to relay implementation advice and experience here, so it can be a cookbook of what to do as well as what not to do.

Comments?  And if you agree, your rationales in either direction?  (I'll take Daniel's text at that link into account.)

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jeff Macdonald <[email-masked]>
Date: Mon, 2 Aug 2010 13:44:24 -0400

> Comments?  And if you agree, your rationales in either direction?  (I'll take Daniel's text at that link into account.)

Well, I'm on a mailing list (a custom one) that re-writes the From to
the mailing list, and frankly I like it.

-- 
Jeff Macdonald
Ayer, MA

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Mon, 02 Aug 2010 21:57:45 +0200

> This makes at least the third time this has been suggested by someone.  I believe (though I'm willing to be corrected) that the draft should therefore cover this possibility and either advocate it…

Include the option in the document with it's pros and cons: +1. As for 
the option itself (rewriting From): -1. Reasons:

- I don't think it's a good idea to overwrite any Reply already set by 
the author of the message; it breaks the meaning of Reply-To as defined 
in RFC5322
- As per par. 6.3.2 of RFC5322 the From: address is not the right field 
to rewrite, IMO. If anything would have to be rewritten, it would be the 
Sender address.

> Comments?  And if you agree, your rationales in either direction?  (I'll take Daniel's text at that link into account.)

/rolf

---

From: Douglas Otis <[email-masked]>
Date: Mon, 02 Aug 2010 15:49:15 -0700

On 7/30/10 1:05 PM, Alessandro Vesely wrote:
>  On 30/Jul/10 10:58, Douglas Otis wrote:
> > On 7/29/10 6:46 PM, Alessandro Vesely wrote:
> >> 1. There is no standard way for the domain to learn when any of
> >> its users subscribe to a new list.
> >
> > Disagree.
>
>  I'm happy to hear that.  The possibility that a domain becomes aware
>   of all of its users' subscriptions has been aired various times
>  before.  I think that is in many people's desiderata, and have even
>  tried to devise a way of collaboratively doing it
>  (fixforwarding.org.)
>
>  Anyway, let's assume that a domain has somehow managed to maintain a
>   database of all the lists that its users are subscribed to. That
>  domain signs all outbound mail and publishes a non-default ADSP.

Assume the community established a list of all informal third party 
service domains, similar to our product dropped back in 2005. See 
http://www.mail-abuse.com/enduserinfo_nml.html.  This list could be 
regenerated.

Instead of being a nonconforming list, it would be a list of all types 
of third-party services that invalidate Author Domain Signatures, where 
only conforming types would be authorized.  Of course, non-conforming 
lists should not be issued any messages.

The latest version of TPA-Label has not yet been published, but it now 
includes the discardable assertion.  This assertion can signal an 
outbound server that it should not send to the nonconforming domain.

>  I propose that, when a message is destined to a list, the author
>  domain signs a few header fields only, not the body, and tags the
>  message with a (signed) list-signature-required sort of advice.

Changing signature behavior seems ill advised, as this will be more 
difficult to implement.  Not signing the body will also introduce 
security issues.

>  Messages to multiple list and non-list recipients have to be split,
>  regularly signing the non-list copy.

A mailing list is just one possible informal third-party service that 
could benefit from TPA-Label authorization.  The "all tpa-sig" assertion 
indicates one should check for a domain specific authorization. With 
this scheme, there is no reason to split message types, or alter how 
they are signed.

>  Another way of achieving the same effect would be to standardize all
>   acceptable message changes, together with a MIME-compliant
>  canonicalization.  We've already noted that in some cases (plain
>  text, poster-added subject tags, not signing "Content-Type", l=) it
>  may work as-is.  For the general case, and for the time being, the
>  advice requiring the added list signature guards against replay
>  attacks: Verifiers must ensure that both signatures are valid, unless
>  they are the domain whose signature is missing.

I don't wish to stand in the way of such a goal, but such a change may 
take many years to define, and at least as many to gain adoption.

> >> 2. Granting a TPA implies a good degree of trust.
> >
> > Most mailing lists would be safe for a domain in their position to
> > authorize.
>
>  Except that phishermen.com may set up a mailing list for the sole
>  purpose of getting that auth.

The community would need to maintain the TPA list information.  The 
future of email will soon become more positive, than negative.
I also see TPA-Labels playing a significant role for email being emitted 
from the IPv6 address space.  The complexity of routing paths from this 
space will cause current client authentication schemes to be come 
obsolete.  With TPA-Labels allowing third-party signatures,  this also 
enables a means to deal with future namespace complexities as well.

-Doug

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 04 Aug 2010 14:22:41 +0200

> difficult to implement.  Not signing the body will also introduce

Signing software may also take signature properties, including key, 
from ad-hoc header fields.  Posters just have to set it adequately 
when they post to lists.  MLM should bounce the submission in case 
they forget, just like they do when posters pick up the wrong From.

The body will be signed by the MLM, so there is no security issue here.

> take many years to define, and at least as many to gain adoption.

Standardizing all acceptable message changes certainly will take 
years.  To the opposite, the joint-signature approach is 
straightforward.  Just like ADSP /requires/ one signature, the newly 
introduced "ADSP-Required" header field /requires/ one more (with the 
same meaning of /requires/.)  In case I haven't been clear, here is 
what the final recipient will get:

ADSP-Required: MLM.example (*this is new*; signed by original.example)
From: [email-masked]
To: [email-masked]
Date: Wed, 04 Aug 2010 14:22:18 +0200
Subject: [tag] This field is not signed by original.example

The only changes are the addition of the ADSP-Required header field, 
and its interpretation by verifiers.  This is not difficult:

After retrieving the ADSP RR, and seeing it is "all" or "discardable", 
the verifier checks whether d=original.example occurs among the 
successfully verified signatures.  The additional step is simply to 
check that a signature by MLM.example (as mentioned in ADSP-Required) 
also occurs.  If the latter step fails, dkim-adsp also fails, unless 
the verifier _is_ MLM.example.

Isn't this simpler than TPA?

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 10 Aug 2010 15:25:06 -0700

> Comments?  And if you agree, your rationales in either direction?  (I'll take Daniel's text at that link into account.)

Weighing in a bit late...I think this approach should be included in the document.  It's an entirely reasonable approach with some existing implementations, and it may not be as surprising to end users as it is to those of us who read raw email headers daily before breakfast.

---

From: John Levine <[email-masked]>
Date: 11 Aug 2010 00:09:57 -0000

>Comments?  And if you agree, your rationales in either direction?
>(I'll take Daniel's text at that link into account.)

Unless I misunderstand, this is a paper proposal that has never been
implemented that addresses a quite possibly purely hypothetical
problem.

There's nothing wrong with unimplemented paper designs, but what you
do with them is to write them up in an I-D, ask the IETF to publish it
as Experimental (something I'd encourage the WG to do for this one),
and once there's at least a modest amount of real life experience,
perhaps come back and propose an updated version for standards track.
For a good idea of the way this can work, look at the EAI group. It
published a variety of Experimental RFCs fof non-ASCII email
addresses, and now after they have some experience, they're moving
ahead with one that seems to work less badly than the others.  It's
not the one I'd have expected them to pick, but when I read the
messages about their experience, I see why they made the choice they
did.

I have to say that this particular proposal is currently no more than
1/3 baked, since unless I've missed something, I don't see much effort
to work out failure and security models.  For example:

- Who do you accept forwarded messages from? List subscribers? Anyone?
  Subscribers and people who sign up on a forward-me pseudo list?

- If a forwarded message is rejected or bounces, what do you do?  At
  what point should you stop trying to forward?  If you get mail to an
  address that you don't forward any more do you reject it? Drop it?
  Something else?

- What do you do when someone unsubscribes?  When someone bounces off the
  list?  When someone changes his subscription address? (Yes, there are
  MLMs that let you do that.)

- What kind of spam filtering is appropriate for forwarded messages?
  For returning bounces?  Should you try to distinguish between real
  bounces and spam to bounce addresses ?

- Many MUAs collect outgoing addresses into the local address book, so
  people who really have one address will now appear to have N+1 if
  they subscribe to N lists.  Is that a problem?  Why or why not?  If
  it's a problem, what should you do about it?

That's all that occurs to me in five minutes, but I'm sure that if you
actually try it, you'll find lots more.

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 10 Aug 2010 20:07:33 -0700

On 8/10/2010 3:25 PM, J.D. Falk wrote:
>> Comments?  And if you agree, your rationales in either direction?  (I'll
>> take Daniel's text at that link into account.)
>
> Weighing in a bit late...I think this approach should be included in the
> document.  It's an entirely reasonable approach with some existing
> implementations, and it may not be as surprising to end users

I claim that it not only is surprising, but that it is extremely confusing.  I'm 
glad to pursue a discussion of cognitive models for average users and suchlike.

That some implementation do it does not make it useful.

To the extent that the document is, well, documenting existing practise, then 
fine, although I'll urge that a caveat be included about unknown efficacy.

To the extent the document is making recommendations, I lobby quite hard against 
citing From: field re-writing.

No doubt there are some scenarios in which it's ok to do, but I claim that 
typical mailing list usage isn't among the set.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 11 Aug 2010 21:49:26 +0100

> to work out failure and security models.  For example:

OK, in the scenarios which follow, "you" is some MLM, and the proposition  
is that the MLM might decide to alter the From: header (e.g. by percent  
encoding), plus some other useful changes.
>   Subscribers and people who sign up on a forward-me pseudo list?

The MLM (aka "you") makes that decision according to the purpose of his  
list. Those factors might well influence whether he changes the From: or  
not.

> - If a forwarded message
ITYM one that is forwarded back to the original author via the percent hack
> is rejected or bounces, what do you do?  At
>   what point should you stop trying to forward?

That is a matter of policy for the MLM to decide. Presumably if it is a  
4xx response you keep trying, and if it is a 5xx you pass it back up the  
Return Path. That is, more or less, current common practice.

> ... If you get mail to an

Again that is a matter of policy for the MLM. It would be polite to reject  
with some 5xx and/or some explanation up the Return Path. It would be a  
kindness to continue to forward it at least for a while.
>   MLMs that let you do that.)

Policy again. there is no obligation to forward bounces off the list  
(indeed an open relay is already considered bad practice). A changed  
subscription simply causes the percent hack to be applied to the new  
address. For unsubscription, see the previous scenarios.
>   bounces and spam to bounce addresses ?

Probably best to forward regardless, which gives the same effect as if the  
responder had replied directly himself. As a minor benefit, it lets you  
discover that your members are sending spam, if you really want to follow  
that path. Essentially, your forwarding practice should seek to emulate  
the current situation where the responder replies to the original author  
directly.

>   it's a problem, what should you do about it?

That is the only point you have raised that might have some merit. It  
does  not seem like a showstopper to me, but the possibility ought to be  
documented as part of the proposal. If the percentified address in the  
address book stops working then, according to the answers given above, the  
responder will soon get to know about it, exactly the same as when someone  
currently changes their address and fails to notify everyone affected.
> actually try it, you'll find lots more.

Keep shooting. Maybe you will eventually find your foot :-) .

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Wed, 11 Aug 2010 15:54:53 -0700

On 8/11/10 1:49 PM, Charles Lindsey wrote:
> > - Many MUAs collect outgoing addresses into the local address book,
> > so people who really have one address will now appear to have N+1
> > if they subscribe to N lists.  Is that a problem?  Why or why not?
> > If it's a problem, what should you do about it?
>
>   does  not seem like a showstopper to me, but the possibility ought
>  to be documented as part of the proposal. If the percentified address
>  in the address book stops working then, according to the answers
>  given above, the responder will soon get to know about it, exactly
>  the same as when someone currently changes their address and fails to
>  notify everyone affected.

Obfuscating who sent a message is not good, especially in light of what 
motivated use of ADSP policy that is causing this problem.  
Unfortunately, ADSP as currently structured is too restrictive for all 
but ~0.0008% of legitimate domains, or even ~0.375% of domains being 
heavily phished.   ADSP's extremely limited use indicates it is _not_ 
the mailing-lists that need to change.  ADSP policies can be structured 
to permit specific third-party service exceptions, which resolves these 
problems without changing mailing-list and MUA code that would impact 
millions of users.

Finally, modifying From header fields will not offer any reasonable 
transitional strategy able to resolve the problems facing ADSP within 
any reasonable time frame.

-Doug

---

From: John Levine <[email-masked]>
Date: 11 Aug 2010 23:26:06 -0000

>encoding), plus some other useful changes.  ... [ various comments ]

OK, fine.  I'm looking forward to your I-D.

R's,
John