dmquigg-spf at yahoo
Jan 17, 2008, 3:05 PM
Post #41 of 50
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
>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 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.
Sender Policy Framework: http://www.openspf.org
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=87160799-6b671c
Powered by Listbox: http://www.listbox.com