The Trouble with SPF and email
Over the last couple of weeks it seems that some email servers are strictly enforcing the rejection of email when a domain’s email address header does not have a matching SPF record. The problem is further compounded since very few ISP’s actually allow you to utilize your domain’s email server (smtp) directly if they are not hosting your domain.
While most ISP’s pass through the sender’s email address (user@yourdomain.com), the actual email header contains the address of your ISP’s smtp service.
Microsoft was the first to begin enforcing this proposed standard a couple of years ago. The SPF proposal has yet to receive endorsement and it is not an approved standard. The proper way to handle this situation is embodied in the approach taken by Qmail and the Open Source community. Qmail does not reject email on this basis although you can patch it to do so. SpamAssassin will add a small penalty to an email’s total score but this is usually not enough to cause an email to be flagged and rejected.
The problem is further compounded when openspf.org posts a seriously misleading statement of error regarding the cause. Their recommendation is to contact your email administrator with a recommendation that the postmaster fix the email server’s configuration.
Nothing could be further from the truth. It is the email recipient’s email server that is rejecting the email. It is highly unlikely that your postmaster has any control at all of the recipient’s email server, unless they run email service for both parties.
Secondly, the fix has nothing to do with an email server. The SPF record is part of your domain service records that are served up by a DNS server, not an email server.
Of course, just try explaining that to an irate customer.
The fix is to add a SPF record to your domain records which is accomplished by contacting your domain registrar.
The biggest problem I see with this issue, besides not being totally convinced that this is a solution that can or will reduce SPAM, is that the arbitrary enforcement of this proposed standard violates one of the fundamental tenants of computer science.
DO NOT CREATE CONTENTION WHEN NONE EXISTS!
The enforcement of this proposed standard creates contention on multiple levels, the most important level is that of customer satisfaction. Customers get angry. False impressions of SPAM are created. And your customer’s customers get angry.
I would hope that openspf.org would get it’s act together. They are giving out a lot of black eyes and I am none too happy about it.
I fully expect to field more customer complaints when their ISP arbitrarily changes the address of their SMTP server, which happens quite frequently. If SPF is to be useful, then ISPs will need to develop a way to relay requests from their customers to their customer’s email server so that the proper email headers can be generated.
Otherwise, SPF is just a waste of time and effort.
