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: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Scott
Kitterman
Sent: Tuesday, August 08, 2006 1:31 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
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