Hallam-Baker, Phillip wrote:
For example. Define a command option SDATA, Reciever
advertises it in response to EHLO, sender uses it to
present signed data in place of DATA.
If the client sifts his outbound into "signed DATA" and
"unsigned DATA", it could also use a MAIL FROM parameter
to indicate what it's going to be.
the point is we should use the SMTP extension mechanism
not invent our own.
An example is RFC 4405.
[Scott wrote:]
Such a hint would, I imagine, only be useful when From =
Mail From.
Why ? Your scenario is apparently mail where you're about to
reject it before DATA, unless it promises a DKIM signature,
and you're willing to check this.
If you intend to check the signature after you've accepted the
mail you'd need a no-nonsense MAIL FROM, but why the same as
the 2822-From ?
IIRC, that accounts for about 80% of mail.
It would be interesting if somebody can confirm this. I've
seen it elsewhere, but can't tell anymore if it was about the
2822-From or the PRA.
I can see some potential for this to make signing more
attractive to small senders who are more likely to be
blocked due to RBLs. It may be attractive to receivers
as a way to reduce false positives from spam filtering
techniques used on the envelope.
Yes, but I miss two clues here. First party signatures are
created somewhere between MSA and "mailout" (= MTA talking
to an MX), and that MTA does not necessarily know what it's
sending, signed or unsigned mails.
In the cases of a list / moderated newsgroup / etc. (Dave
mentioned other cases) the MAIL FROM is not the same as the
2822-From.
Frank
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html