On 25-Feb-2010, at 10:29, Marc Perkel wrote:
>
> The anti-SPF bandwagon is not ego driven but results driven. Than you for
> admitting that SPF in not a spam filtering solution. However it is also not a
> white listing solution because as many people have said here - spammers are
> the ones who are using SPF correctly.
If you blindly accept any email with a valid spf as being 'good' email then
your not understanding the system.
Here's where spf is useful. You have an emailer (a bank, a company, aol,
hotmail, whatever) that is a frequent target of spoofing. You can either spend
a lot of time and resources trying to catch the spoof emails while not trashing
the real ones, or you can enable spf.
So, if an email comes in to my mailspool from paypal.com and it passes spf, it
is treated as a normal message. It still goes through SA. But if it comes in
"from" paypal.com and DOESN'T pass spf, it instantly gets 5 points added to it
because if it's claiming to be from paypal AND it fails SPF, it is *not* from
paypal.
So, while SPF is *not* an anti-spam tool, in the case of paypal, and ebay, and
citibank (but not the mentally challenged lemurs at bankofamerica) the *lack*
of SPF become an anti-spam tool (more often a anti-phishing tool, really).
How any mailadmin can think this is a bad thing is staggering.
> I can see some theoretical benefits that if you have a list of banks with
> SPF and you receive an email from an address that the bank lists then you can
> safely pass it. But I find that an easier way to do that is to use FCrDNS to
> do the same thing.
Which fails when you have someone that has multiple domains that may be sending
mail "from" the same organization. Mail to me from Citi may comes from any one
of at least 6 different domains, and the mailserver is not necessarily in the
same domain.
> On the down site SPF breaks email forwarding
uh huh. For certain values of "breaks" and "forwarding". Resend the message as
a rfc2822 attachment and... zomg, nothing is broken. Recipient gets the
original unaltered message and the SMTP process doesn't have to lie about who
the sender of the message is. But that takes some degree of effort on the part
of mailserver, so it is widely ignored as it would constitute work.
Also, keep in mind that SPF has THREE states. Pass, fail, soft fail.
$ dig kreme.com txt +short
"v=spf1 mx include:covisp.net ~all"
only my mx server or the specific domain covisp.net is allowed to send email
'from' my domain. No other host sending mail from my domain is to be considered
valid.
I could do, instead:
"v=spf1 mx include:covisp.net ?all"
This means, hey, my mx server or any machine at this domain will send mail for
me. If the email comes from there, SPF passes, but if it DIDN'T come from
there, it might still be me, so only do a soft fail. because sometimes I route
my mail out over gmail, or my friend ziggy.tld."
Many admins will reject both fail and soft-fail as failures, which is wrong.
> and it creates a false sense that people are doing something to fight spam or
> protect ham that is not supported by reality. SPF has received intellectual
> welfare because stuff that doesn't work tends to be culled out of spam
> assassin and other than backscatter most people here are telling the SPF
> supporters that it doesn't work. If SPF is becoming more popular it just
> means that more people are misled.
SPF is becoming more popular because it is *effective* at what it does.
Currently I only use SPF within SA checks because it makes it trivial to catch
most of the phishing scams.
--
They say only the good die young. If it works the other way too
I'm immortal
