[OT] SPF - was Re: Simple Python script as SMTP server for outgoing e-mails?

[Chris Angelico]

On Wed, Jul 24, 2013 at 1:12 AM, Michael Torrie <torriem at gmail.com> wrote:
> On 07/23/2013 03:30 AM, Chris Angelico wrote:
>> On Tue, Jul 23, 2013 at 7:19 PM, Chris Angelico <rosuav at gmail.com> wrote:
>>> Ah, there's a solution to this one. You simply use your own
>>> envelope-from address; SPF shouldn't be being checked for the From:
>>> header.
>>
>> There's an example, by the way, of this exact technique right here -
>> python-list at python.org sends mail to me with an envelope-from of
>> "python-list-bounces+rosuav=gmail.com at python.org" - which passes SPF,
>> since python.org has a TXT record designating the sending IP as one of
>> theirs. It doesn't matter that invalid.invalid (your supposed domain)
>> doesn't have an SPF record, nor would it be a problem if it had one
>> that said "v=spf1 -all", because that domain wasn't checked. Mailing
>> lists are doing the same sort of forwarding that you're doing.
>
> This is good and all, and I think I will modify my local postfix mail
> server I use for personal stuff, just for correctness' sake.

Correctness is a worthwhile reason to do something :)

> I hadn't spent much time studying SPF in depth before, but after reading
> your comments (which were insightful) I'm now more convinced that SPF is
> worthless than ever, at least as a spam prevention mechanism.  Spammers
> can use throwaway domains that publish very non-strict SPF records, and
> spam to their hearts content with random forged from addresses and SPF
> checks pass.  The only way around that is to enforce SPF on the From:
> header in the e-mail itself, which we all agree is broken.  I've been
> reading this:
>
> http://www.openspf.org/FAQ/SPF_is_not_about_spam

There are several things that SPF achieves, but mainly it's a measure
of trust. If you receive email from a domain I run, and the SPF record
permits the IP that sent it to you, you can have a high degree of
confidence that it really is from that domain. Suppose, for instance,
that (pick a bank, any bank) has a strict SPF record. Someone tries to
send a phishing email purporting to be from that bank. They then have
to use a different envelope-from address, which instantly marks the
mail as suspicious to anyone who's checking. But more likely, what
they'll do is simply ignore SPF and send it anyway. That means that
any MTA that checks SPF records is immediately freed of all that bad
mail - which is more than just spam, it's a major vulnerability
(thinking here of corporate networks where all the company's mail goes
through a central server, and then a whole lot of non-technical people
read it). In the same way that banks assure us that they will *never*
ask for your password, they could also assure us that they will
*never* send account information from any other domain.

Spammers look for the easy pickings. If your X million addresses
become (X-1),999,900 because a few servers are rejecting their mail,
what do they care? But those hundred people now haven't seen that
spam. Sure, spammers can easily get around SPF checks... but that
won't get all that likely until the bulk of MTAs start checking. For
now, we can take all the benefit. Later on, the world can look to
other solutions.

ChrisA