On Tuesday 08 August 2006 13:54, Hallam-Baker, Phillip wrote: > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Scott Kitterman > > Sent: Tuesday, August 08, 2006 1:31 PM > > To: [email protected] > > Subject: [ietf-dkim] Signalling DKIM support before DATA > > > > I think this new... > > > > If there is a reasonable way to do it, it might be useful for > > receivers to be able to get a hint before going to DATA if > > the message is going to be DKIM signed. I can envision > > looking for such a hint when evaluating a message from an IP > > address listed in an RBL and perhaps going to DATA to look > > for the promised signature. > > > > Such a hint would, I imagine, only be useful when From = Mail > > From. IIRC, that accounts for about 80% of mail. > > > > If the information (such as the policy record perhaps) > > contained a list of authorized signing domains then a > > receiver could go to DATA and find out if it was worth > > expending the CPU cycles to verify. > > > > 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. > >
> The way to do this (if it should be done) would be to use the SMTP > extension mechanism. > > 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. > > Might be a better implementation but the point is we should use the SMTP > extension mechanism not invent our own. > I guess that would be one way to do it. It might also play nicely with the sometimes discussed idea of breaking DATA into header and message: http://isdg.net/public/ietf/drafts/draft-santos-smtphead-00.txt Then it would be possible to receive the header and check if a signature using an appropriate domain is present before having to commint bandwidth and CPU to the actual message. The downside of this approach is that, I think, it would require core MTA libraries to be updated which would significantly impact deployability. I had been thinking of just doing a lookup on the policy record and if one finds a list of singing domains checking to see if the Mail From domain was on the list. My thought had been that if a receiver is already doing DNS intensive work such as RBL lookups, one more check for a policy record wouldn't be significant. The downside, of course, is that for forged e-mail an innocent bystander gets additional DNS traffic. Scott K _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
