Subject: [ietf-dkim] NEW ISSUE: Restriction to posting by first Author breaks email semantics

From: Dave Crocker <[email-masked]>
Date: Sun, 09 Dec 2007 09:27:08 -0800

> 7. Resolution in the Face of Multiple From field Addresses
> 
> When there are multiple address in a message's rfc2822.From field, the SSP
> specification arbitrarily declares that the first address shall be used for
> SSP enforcement.  Although multiple From addresses is rare, its use is valid
> and, in particular, occurs when the content's authors want to communicate
> something significant about the authorship.  In light of that, arbitrarily
> coercing which of the authors is allowed to submit the message is quite
> troubling, especially since it is usually a subordinate author who does the
> scut work of document maintenance and public posting.
> 
> Unfortunately, this is a problem for which there is no obvious solution. Since
> SSP should not get into the business of changing who is permitted to post
> valid mail, the issue does very much need better resolution. 

To the extent that the above is not sufficiently clear:

      SSP's arbitrary assertion that only the first author (as specified in 
the rfc2822.From field) can sign the message essentially limits posting to ony 
that author.  This breaks a flexibility in email service that is not even 
appropriate to the limited scenario of having multiple authors.

      The underlying problem is with coupling the From field to the DKIM 
signature.  At most, the Sender value should be used.

d/
-- 

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

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 10 Dec 2007 08:52:50 +0100

> To the extent that the above is not sufficiently clear:

It's clear, RFC 5016 should be moved to historic unless 
2822upd deprecates Resent-From and any kind of *-Sender.

> At most, the Sender value should be used.

In the parallel universe where Resent-* are deprecated,
as it happens I know who supported these proposals.

At least "Sender" would be compatible with RFC 4409 8.1,
STD 11, and RFC 4407 (outside of "Resent"-scenarios).

 Frank

---

From: Eliot Lear <[email-masked]>
Date: Mon, 10 Dec 2007 15:57:14 +0100

Dave,
>
>      The underlying problem is with coupling the From field to the
> DKIM signature.  At most, the Sender value should be used.

It would indeed be nice to use the Sender field, but I would be
concerned about the Sender field not at least matching one of the
domains of one of the RFC2822.From lines, lest someone attempt to bypass
the tests by inserting a Sender.  But then we need an extra rule in the
state machine.  Perhaps it is better to explicitly deprecate multiple
>From lines?  As UIs have developed they really don't index well against
multiple From lines anyway.

Eliot

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 10 Dec 2007 10:26:33 -0500

> multiple From lines anyway.
We went through all this at the time the decision to use first From was made.  
No new information has been provided to warrant reconsideration.  I'd suggest 
just mark the issue a duplicate and move on.

Scott K

---

From: Damon <[email-masked]>
Date: Mon, 10 Dec 2007 10:44:05 -0500

> just mark the issue a duplicate and move on.

+1

Regards,
Damon Sauer

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 11 Dec 2007 12:10:20 -0000

> multiple From lines anyway.

I think if the Sender matches one of the From addresses, and is itself  
signed, that should be regarded as a valid originator signature, even  
though it doesn't match the first.

I could even accept that a Sender (signed) from the proper domain should  
be regarded as a valid originator signature, even if none of the Froms was  
 from that domain - why else would the signer have signed it?

No verifier should have any problem testing for those conditions. True, it  
might confuse an end reader whose MUA did not show the Sender, but we  
can't build standards around the (many) quirks of poorly designed MUAs. In  
any case, it has always been our assumption that signatures would be  
checked by the boundary MTA, and readers should either be happy to accept  
that check, or they should repeate the check themselves (in which case we  
must assume they know how to do it properly).

-- 
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: Eliot Lear <[email-masked]>
Date: Tue, 11 Dec 2007 14:51:03 +0100

> though it doesn't match the first.

On the other hand, one could argue that this could be used as a form of
attack - that I Mr. Spammer insert a From line, a Sender line AND a
signature, with my main objective being to get mail in as some OTHER
>From (like a bank or Ebay), knowing that a particular UI is only going
to represent (first|last) From.  Remember, a lot of this boils down to
how this stuff gets represented to the end user.  And I would argue that
an abundance of caution is needed, where we err on the side of
protecting the recipient.

In the end I stick with my preferred way forward: deprecate multiple
>From lines.

Eliot

---

From: John Levine <[email-masked]>
Date: 11 Dec 2007 15:51:00 -0000

> In the end I stick with my preferred way forward: deprecate multiple

How does that turn into a spec?  I understand we say "don't do that", but
then someone will go and do it anyway.  Is the idea that a message with
multiple From: is out of scope of SSP?

Some relevant changes would be to section 2.3 to remove references to
multiple From: and change them to say that multiple From: is outside
the scope of SSP.

In 4.3 add a note to all and strict pointing out that if you publish either
of those, you better not send multiple From: mail.

R's,
John

---

From: Eliot Lear <[email-masked]>
Date: Tue, 11 Dec 2007 16:54:27 +0100

> multiple From: is out of scope of SSP?

No.  I think what's in the text is as good as anything we can come up
with.  Your earlier suggestion was probably the right one, John, that we
take it to the appropriate forum for RFC2822bis and work from there.

Eliot

---

From: Michael Thomas <[email-masked]>
Date: Tue, 11 Dec 2007 08:09:36 -0800

> of those, you better not send multiple From: mail.

Since SSP is about self-imposed limitations on what a domain does,
I don't see what the dilemma is in the strict or all practice saying
that they don't send mail with multiple From addresses. Considering
how rare and out of date this practice is these days, I can't imagine
that anybody would even notice.

		Mike

---

From: Mark Martinec <[email-masked]>
Date: Tue, 11 Dec 2007 19:53:27 +0100

Eliot,

> Perhaps it is better to explicitly deprecate multiple From lines?
> As UIs have developed they really don't index well against
...
> In the end I stick with my preferred way forward: deprecate
> multiple From lines.

The topic is not about multiple From header fields (lines),
these are prohibited by rfc2822 anyway. The topic is about
multiple author addresses in a single From header field.

  Mark

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 12 Dec 2007 11:59:53 -0000

> that anybody would even notice.

Then in that case you need a tag in SSP to say "we never do multiple
From:s".

---

From: Damon <[email-masked]>
Date: Wed, 12 Dec 2007 10:23:09 -0500

On Dec 12, 2007 6:59 AM, Charles Lindsey <[email-masked]> wrote:
> CharlesH.Lindsey---------AtHome,doingmyownthing------------------------
/dkim/ietf-list-rules.html

I am a bit curious about how prevalent this is so I checked a month
worth of logs.
The only multiple "From:"'s I could find were from seemingly broken
mailers that were putting in duplicate From: lines.
Does anyone have any real world examples of where this might cause a
basic functionality issue with legitimate MTA's?
I am really expecting this to be so far in the fringe that it
shouldn't even be on our radar.

Regards,
Damon Sauer

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 12 Dec 2007 20:09:35 +0100

Damon Sauer wrote:

> Does anyone have any real world examples of where this might
> cause a basic functionality issue with legitimate MTA's?

I've seen multiple authors (more than one address in the From
header field) in NetNews articles (e.g. for posted FAQs).

Please note that "multiple Froms" is a shorthand for more than
one author, "multiple From header fields" would be erroneous.

Nobody proposed to deprecate or remove "multiple authors" for
2822upd, it's a valid option, with a mandatory Sender address.

And the Sender address is not necessarily the same as one of
the author addresses.

My proposal to simplify at least "multiple Resent-From" (with
its mandatory Resent-Sender) into a single Resent-From for 
2822upd was more or less unanimously rejected on the 822 list.

Dave's proposal to get rid of Resent-* altogether also didn't
make it, some folks really like the Resent-From email feature.

> shouldn't even be on our radar.

Just because we don't see it often doesn't mean that it's never
used, it could be even essential for something we've never heard
of before.  It's how email works, and if SSP doesn't agree with
these 2822upd features it has a serious problem.

I've used From <> Sender (with different domains) in many cases,
any SSP claiming that I can't do this would be arguably broken.

 Frank

---

From: Damon <[email-masked]>
Date: Wed, 12 Dec 2007 17:21:04 -0500

Agreed.

Regards,
Damon Sauer

---

From: Dave Crocker <[email-masked]>
Date: Fri, 21 Dec 2007 09:53:24 -0500

Eliot Lear wrote:
> to represent (first|last) From.  

This presumes that user interface issues are relevant to SSP.

They aren't.

Or, rather, they shouldn't be.

Or rather, if they are, we need to see the empirical basis for making these
choices.

We aren't in a position to make security-related design decisions for user
interfaces.

So that's two ISSUES this design choice factors into.

d/
-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Sat, 22 Dec 2007 16:05:57 -0500

Dave Crocker wrote:
> They aren't. Or, rather, they shouldn't be.

+1.

> Or rather, if they are, we need to see the empirical basis 
 > for making these choices.
> 
> We aren't in a position to make security-related design decisions
 > for user interfaces.

+1,

We should only make sure we are consistent with the framework and/or 
make sure there is isn't a dependency or create new ones that relies on 
things that may be unfeasible to mandate.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com