On Tuesday 08 August 2006 15:15, Frank Ellermann wrote: > [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. > I was thinking in terms of using the policy record as a hint rather than something directly in the SMTP exchange. If an SMTP client tells me something in order to convince me to accept it's mail, I am extremely unlikely to believe it without outside confirmation.
If the Mail From domain has a DKIM policy record that says it signs mail, then that's an external source that is at least somewhat more believable. > 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 ? > In order to know what policy record to look at. > >> 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've probably seen it the same places. I'd be interested if someone had some current statistics too. > >> 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. Yes, but Mail From and signing will usually be generated at the MSA, so as long as the policy record is correct for the signing domain, I don't think that matters. > > In the cases of a list / moderated newsgroup / etc. (Dave > mentioned other cases) the MAIL FROM is not the same as the > 2822-From. > Yes. I don't think this can solve all problems, but it might have general enough utility to be worth specifying. I'm not sure. I throw this out as an idea for consideration by the group, not something that I am certain is worthwhile. Scott K _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
