At 12:02 PM 2/23/2005 -0500, you wrote:
On Wed, 23 Feb 2005, David MacQuigg wrote:
> OK, I'm motivated. :>) The problem is the bounces coming from folks who
> are not participating in SPF. My SPF record doesn't stop them from
sending
> me a bounce. A universally-understood authentication system would end
most
> of that "backscatter".
You might be interested in SES as a complement to publishing SPF.
SES signs the return path, allowing you to reject bounces (DSNs) from
a forged return immediately after MAIL FROM at SMTP time.
SES also provides an alternate system for MAIL FROM validation.
It works very synergistically with SPF to get your email to recipients
that have not correctly configured SPF for their forwarders.
This works by publishing an SPF record that lists authorized IPs first,
followed by exists:%l._ses.example.org. A stunt DNS server for the sender
returns a record when the local part validates, and NXDOMAIN otherwise.
When a non-SRS forwarder delivers the email, and the recipient has
neglected to
whitelist said forwarder, then they hit the exists clause and the MAIL FROM
still gets validated. This makes the combination of SPF + SES very tolerant
of configuration errors.
If you are only interested in rejecting bounces of forged MAIL FROM, then
installing SRS for all outgoing mail accomplishes the same thing and
is much simpler. SRS is not suitable for validation because there is no
protection for replay attacks. Replay protection is the primary complication
for SES.
Caveat: SES/SRS can reject actual bounces/DSNs of forged MAIL FROM.
Unfortunately, way too many $^%&$* stupid dumb(_at_)$$ Windows spam/virus filter
writers send a reply instead of a DSN (and without checking SPF). Arrrrgggh.
So you'll still get emails saying, "Our Super WhoopDeDoo Virus filter
for ignorant Windows lusers has detected a virus in your email. And
even though the email almost certainly didn't come from you, since
viruses/virii never tell the truth in email headers, we'll annoy you
anyway by sending a reply instead of a DSN in the hopes that this display
of our ignorance and incompetence will motivate you to buy our product."
Sometimes a simple reply is effective in getting the owner of the machine
to install an antivirus product. I once called my neighbor, "Connie, I
just got an ad for penis pills from you. Are you trying to tell me
something?" Took me a few minutes to re-assure her I understood the
message wasn't from her, but it did come from her computer."
I think we have a fundamental human nature problem here. People shouldn't
assume spam came from the purported address, but they will. Give them a
bounce option, handle those bounces properly, and the problem goes
away. SPF enables the proper handling of bounces. That is something new
we ought to be taking advantage of.
I'm skeptical of the SPF/SRS/SES procedure described above, even if there
is nothing wrong with the technical details. The anti-SPF folks will
ridicule it as "patching a fundamentally broken SPF based on false
assumptions", etc. No doubt this is a bunch of FUD, but it is effective
FUD. So what should we do, FUD back? How are we going to get broader
acceptance of email authentication? Are the benefits worth the cost of
making some compromises with the "enemy"?
-- Dave
************************************************************* *
* David MacQuigg, PhD * email: dmq(_at_)gain(_dot_)com * *
* IC Design Engineer * phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* * 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. * Tucson, Arizona 85710 *
************************************************************* *
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com