At 06:10 PM 1/16/2008 -0800, Michael Deutschmann wrote:
On Mon, 14 Jan 2008, Stuart D. Gathman wrote:
AOL is a poster child for why the canard about how SPF "breaks forwarding"
is complete FUD. *Any* system that blocks the sources of spam
"breaks forwarding".
The real problem is that there are at least three separate "Forwarding
Problems":
Forwarding Problem S - To technologies like SPF, traditionally forwarded
messages appear to be forgeries.
Forwarding Problem K - Forwarding source IPs will accumulate "bad karma"
when they innocently pass on spam to a MUA with a "this is spam" button
and a luser operating it.
-- luser: term used mostly by immature computer geeks to show off their
literary skills and contempt for ordinary (non-geek) users.
I don't like the term "luser", due to the attitude it conveys. The users I
know are smart but busy people, some with advanced degrees, but not usually in
computer science. Looking at my AOL recipients, I see one is an MD, another is
a retired VP from a major retailer. They both seem to like AOL. We will do
better by making our technology serve their needs. That may not be as hard as
it seems. In this case, I would have an automated procedure for the Forwarder
to challenge a spam report. The absent-minded MD could then either confirm
that he didn't make a mistake, or just ignore the challenge and the report
would be ignored.
Forwarding Problem B - Forwarders are left holding a hot potato if they
accept SPF-neutral mail and the ultimate recipient MX 5xx's it.
Problems K and B really hurt the forwarder, and can only be resolved by
recipient whitelisting, period.
Problem S can be resolved by the forwarder alone, but it's in the
forwarder's interest to play dumb, since if the recipient solves Problem S
at his own end, he also solves Problem K, and if the recipient admin is
honourable, problem B as well.
Nice analysis. It took me a while to understand, however. Here is how I would
illustrate with an example.
/ /====================\
/ --> Receiver/Forwarder ~~> MDA ==> Recipient
/
(box67.com) (aol.com)
Box67.com is doing everything it can to be a good Forwarder, including using
SRS on its forwarded messages. In fact, it is one of the few forwarders in the
world that uses SRS. That solves Problem S, but leaves aol.com thinking that
the spam *originated* from box67.com (Problem K).
If the problem is to be resolved by one party alone, it would have to be the
MDA, not the Forwarder. Aol.com can see that box67.com has very few spam
reports, and those few have been mistakes by the Recipient. Correcting these
mistakes may take some work, but it could be done.
That work could be eliminated if we get the other parties involved, and improve
the whitelisting procedure for the Recipient. Instead of just a few individual
sender addresses, he should be able to whitelist an entire domain. Any mail
forwarded by box67.com to that Recipient should bypass all further filtering.
Any spam reports on box67.com to aol.com from that Recipient should generate an
automatic response "You must first take this domain off your whitelist".
(Once an honourable mail admin *knows* that a given message is a trusted
forward, he must turn off spam defenses so that he doesn't force Problem B
on an innocent other admin. But in the 2007 discussion here, it was
claimed that most admins will dishonourably comply with customer orders to
spamfilter the forwarded mailstream....
I don't like the assumption that mail admins are dishonest if they don't do
things our way. All that does is generate prejudice against SPF and anyone
associated with SPF.
Fortunately, the recipient admin has no selfish reason not to fix Problem
K, once he has the information and technology needed to fix Problem S.)
Much better! We can talk about motivations and incentives and real-world
economics without insulting anyone. Mail admins right now are not greatly
motivated to support SPF. We need to explore the reasons and figure out ways
to make SPF more relevant to their *self interest*. (Notice I avoid the word
"selfish".)
Seems to me that the big ESPs have sufficient self interest to do their part in
making forwarded mail more efficient. It would help their customers, and
reduce the burden on their own personnel, if we had a simple universal and
automatic procedure for setting up forwarding. What are the requirements of
this procedure? I can think of the following, maybe you can add some others.:
1) No cost to anyone, other than a small administrative burden.
2) Minimum involvement of the Recipient in error-prone details.
3) No vulnerability to spammers.
If we can design a system that meets these requirements, I believe we will
solve the "forwarding problem".
On item 1, adding a simple DNS record would be OK. Installing SRS would be too
much to expect, unless we can make it easily installed on all the popular MTAs.
Individual attention to every forwarder's request would be too much,
especially since we can expect a lot of requests from spammers. The Recipient
can provide the necessary approval.
On item 2, we shouldn't expect the Recipient to properly coordinate the
arrangements between the Forwarder and the MDA. The Recipient should set up
forwarding using whatever procedure the Forwarder expects. Then the Forwarder
should communicate with the MDA, and the MDA should ask only a Yes/No from the
Recipient.
On item 3, we need robust authentication (PASS or FAIL, no NEUTRAL) on the
connection between the Forwarder and the MDA.
-- Dave
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription:
http://v2.listbox.com/member/?member_id=2183229&id_secret=87162493-c8c007
Powered by Listbox: http://www.listbox.com