On Tuesday 08 August 2006 13:54, Hallam-Baker, Phillip wrote:
-----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.
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