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