Marc Perkel wrote:
SPF blocks no spam but
it does create false positives on legitimate email.
Well, so does any other method of trying to decide if a message is legit
or not. If I work for $company, and $company publishes a restrictive
SPF record, then (presuming the sysadmin is competent) a decision has
been made as to where $company email may originate. I can either
cooperate and send email as designated, or take the risk that my email
does not meet company policy (and therefore may get tagged as spam by my
intended recipient).
For an ISP, I agree that SPF is of very limited use. IMO setting up TLS
and SMTP-AUTH is a *very* small price to pay - once - to enforce company
or personal policies on company or personal email domains respectively.
It's anti spam technology.
Erm, maybe we're getting into a semantic debate on this point, but SPF,
in and of itself, is not an antispam technology. It's not much use in
positively identifying any great volume of spam except for the
occasional idiot spammer that uses an SMTP sender address from a domain
that has a very restrictive SPF record.
It *is* intended to allow domain owners to specify which systems are
allowed to generate new SMTP traffic using their domain as the SMTP
sender - AKA an anitforgery technology.
The reason people use it is because spammers
are forging email addresses.
Hrm. I don't see much of that any more (maybe someone else can point
out some hard numbers?); with cheap throwaway domains it's easy enough
to just use those, and bypass SPF by either not publishing a record, or
publishing a very open SPF record.
Matt Kettler wrote:
That said, your comment about blocking no spam is pure horsehockey. I
have plenty of spam matching SPF_FAIL and SPF_SOFTFAIL.
I've also have had no FPs from SPF, except websites like hire.net that
insist upon forging my domain as the envelope sender when generating
emails to my HR staff. Actually, MAIL FROM, RCPT TO, From: and To: are
all identical. Brilliant.
Yep - they are using "normal" email technology.
Er, no; it means that if $thirdpartysite can't deliver a message on my
behalf, *I* get the bounce. This Is Bad. Particularly if it's *my*
receiving server that's temporarily unavailable - the real sender
($thirdpartysender) won't know that I haven't received their message.
Or $thirdpartysender won't be able to send word back to whoever
contacted me through their website that I haven't received the message.
> That's supposed to work.
Er, no; it's just a consequence of SMTP's origins and the changing
Internet landscape. In "The Old Days" (AKA more than about 15 years
ago), spam was rare (never mind spam sent via forged sender).
Anyone that sends email on my behalf, using *my* email address as the
SMTP sender, is someone I'm likely to quit doing business with. In an
extreme case I may decide to drop their SMTP server's IP in my firewall.
That's what SPF breaks. It also breaks email forwarding.
And SRS does not break the ability to do conditionals, because the true
envelope from address is still a part of the rewritten envelope from.
You just need to make your conditionals match the SRS version.
You have to rewrite all your conditionals to support the broken technology.
Well, yes, any time the technology changes anything that relies on it
has to change. This is new and unusually problematic how, exactly?
(Email transport has not changed significantly in *how* many years now?)
There comes a point where maintaining complete backwards compatibility
is what's *causing* most of the trouble in the first place.
(FWIW, I've yet to understand the delight people take in forwarding mail
all over the place; even without SPF, mail forwarding is prone to
painful and ugly failures. Set up multiple POP accounts feeding a
single inbox and be done with it. IIRC there was one customer here
whose forward destination got truly *horribly* misconfigured for a day
or two, creating 5 or 6-hop mail loops. Mail Loops Are Bad.)
-kgd
