Hector Santos wrote: > Its the 2822.FROM: that is "My" mail.
I don't believe that. The 2822-From is the author. It's perfectly okay to use it in SMS, news etc., arriving elsewhere as mail with a different Sender, Resent-Sender, or Resent-From. Depending on where it originally came from it can have no signature at all. "I sign all mail" isn't the same as "I sign everything with some From: me construct". > That is the constant, consistent frame work in every mail system, > including gateways. Not for news from me behind a news2mail gateway. Folks want to use "their" 2822-From-addresses whereever it pleases them, not only on outbound routes with the corresponding DKIM-signing agents. > The RECEIVER will process 2821 first One hopes... :-) > SPF must pass first before it even gets to 2822, and when it goes > to 2822, all 2821 logic has already been satisfied. It can be still some MAIL FROM me Resent-From me with a rather old "From you". Or a MAIL FROM GMaNe Sender GMaNe From me (that's what the list here sees), where GMaNe is some special news2mail gateway, of course with both SPF and SenderID PASS for MAIL FROM and Sender. Do you intend to enumerate all cases where a pure 2822-From logic won't work as expected, adding a MUST NOT in the SSP draft ? With Sender-ID some folks already had serious doubts that it will work. A policy bound to the 2822-From is even more restrictive, and for a policy about DKIM signatures it's additionally bound to a single outbound route. It's a kind of BATV for 2822, like Sender-ID is a kind of SPF for 2822. If that goes into an SSP RFC it should list scenarios where it will "annotate" perfectly harmless mails as "suspicious". And we know that "annotate as suspicious" means DROP, otherwise we'd say REJECT. Rough idea how to express that in the next SSP requirements draft: "The protocol MUST state what 'DKIM signing complete' precisely means wrt common practises like resending, news, and other uses of a 2822-From address". Frank _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
