On Sep 22, 2007, at 5:56 PM, Frank Ellermann wrote:
Scott Kitterman wrote ten weeks ago:
On Friday 06 July 2007 20:09, Dave Crocker wrote:
It seems to me that if a message has a DKIM signature and the
signing domain matches the domain in the rfc2821.MailFrom
command, then it is safe to generate a bounce message to that
address.
By 'safe' I mean that one can be confident that the mail will not
go to an unwitting victim of a spoofed address.
[...]
I expect if limited to the case where 2821 Mail From domain is the
same as the signing domain it would likely be reasonably effective.
SPF Pass would (if available) give you the same or better confidence.
Better because you'd already have this confidence after SMTP MAIL
FROM without DKIM crypto looking at the 2822 header. SPF also
allows to aggregate more than one "sending provider", that's rather
tricky with DKIM or BATV.
This can be done with DKIM using a strategy that can bridge policy
domains.
See:
http://tools.ietf.org/wg/dkim/draft-otis-dkim-tpa-ssp-01.txt
Unlike SPF, the tpa-ssp method scales without invoking hundreds of
DNS transactions. This draft extends the current SSP draft.
OTOH you'd never see an SPF PASS behind "taditional" (aka "broken
by 1123 5.3.6a") forwarding, where Dave's approach based on DKIM
would still work. The scenarios aren't equivalent, Dave's method
is more or less limited to cases starting out with 2822-From = MAIL
FROM, but after that it survives forwarding.
If a mailing list manages to invalidate the DKIM signature Dave's
approach won't work. But the list could very easily guarantee it's
own SPF PASS, so in practice receivers can handle most sound cases.
The use of the From is sure to create problems for mailing-lists. As
with SPF, SSP also lacks policy scope which is unfortunate. This
could be repaired by extending SSP policy with drafts like TPA.
Unfortunately, these extensions are unlikely to be incorporated and
more convoluted work-arounds will likely be used.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html