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
