On Wed, Jul 24, 2013 at 1:12 AM, Michael Torrie <torr...@gmail.com> wrote: > On 07/23/2013 03:30 AM, Chris Angelico wrote: >> On Tue, Jul 23, 2013 at 7:19 PM, Chris Angelico <ros...@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@python.org sends mail to me with an envelope-from of >> "python-list-bounces+rosuav=gmail....@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 -- http://mail.python.org/mailman/listinfo/python-list