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. > -----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. > > Scott K > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html > > _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
