[1] If folks are going to say "spf-like," "rmx-like," I am going to say it.
I'm not set on the current spec of SPF. I just like the concept. (I
actually find the syntax baroque, as others have complained of.) It does
work in every test I've made, though, so while a bit dated seeming, it
does the job. Here are the use cases I come in contact with:
* My users already use SMTP AUTH, because many of them come from a
shared network used by many ISPs.
* I have ports 25 and 587 both open for MUA to MTA message submission:
587 was opened first because my users are already having their mail
blocked while traveling -- one at a hotel, one on a cable network at
their office, and several others on a wireless ISP.
* I see 50% of the mail I deliver as spam, or is virus payload. I
* outright reject at least the same volume based on Spam Assassin
scoring.
* Some 5% of the unwanted mail (a good portion of those are virii)
is sent with a null sender, but could be rejected with a system like
SRS -- and since my systems would be the only ones who have to
handle it specially, I plan to deploy such a system shortly.
* I've run into the case of an ad-hoc SPF-like system already
deployed, where messages my systems forwarded (without sender
rewriting) was rejected because my system "didn't appear to be
the sending domain" -- people are desparate to stop spam, and it
looks like the traveling mailman will be the first casualty. At
least with a DNS-based designated-sender system that's easily
updatable, there's some chance of having it work.
Thoughts to ponder.
Ari