On Mon, 20 Jul 2009, Dotzero wrote:
The issues I referred to are brokenness within Sender-ID, not abuse of
SPF1 records. One key brokenness in SID is the paragraph in RFC4407
that sates:
"3. Select all the non-empty Sender headers in the message. If there
are no such headers, continue with step 4. If there is exactly
one such header, proceed to step 5. If there is more than one
such header, proceed to step 6."
Giving precedence to the "Sender" field allows one to game the system
to get a neutral (at minimum) for what are clearly spam/fraudulent
messages.
Standard SPFv1 has the same problem, in that a message with a blatantly
forged header From: will pass so long as the envelope MAIL FROM is unforged.
Most users won't notice an unusual Return-path: unless they were already
suspicous for other reasons.
(Although SPFv1 is still slightly better than SenderID because protecting
the MAIL FROM: reduces backscatter.)
DK/DKIM solves the problem by focusing on the From:. However, because of
that very feature, it false-positives on mailing lists.
Actually, it would be really cool to have an anti-forgery protocol that uses
cryptography like DK/DKIM, but protects the MAIL FROM like SPFv1. This would
avoid both SPFv1's forwarder FPs, and DK/DKIM's mailinglist FPs, thus
allowing rapid, complete deployment at the receiver end without causing mass
breakage.
My "fm=dkim" proposal, earlier, effectively would create such a protocol,
taking advantage of the fact that DKIM permits signatures other than those
for the From: domain.
---- Michael Deutschmann <michael(_at_)talamasca(_dot_)ocis(_dot_)net>
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com