Slashdot Mirror
Gmail, SPF, and Broken Email Forwarding?
alek writes "I recently stopped getting Email from a friend ... which turns out to be related to his use of SPF records and my forwarding to gmail. This 'lost Email problem' may get worse with
Google implementing Domain Keys." Alek is looking for a non-complicated solution to this non-trivial problem; read on below for more details.
"Background: Like many people, I have me@mydomain.com as my public facing Email address. When Email comes into my server, I forward it to me@gmail.com. But since my friend has published SPF (Sender Policy Framework) records that say only his server is allowed to send Emails for friend@frienddomain.com, gmail apparently rejects (silently buries actually!) the Email since it is forwarding through my server. Please note that this is exactly what SPF is designed to prevent — spammers from sending Emails with your address — but it breaks forwarding and has other problems.
What's *really* strange is that if I look at the raw sendmail logs on my server, the Email from friend@frienddomain.com comes in, and is forwarded to gmail ... with an "OK" as the response — i.e. the gmail MTA doesn't reject the message as it ideally should. However, the Email then disappears — it's not even in my gmail spam filter ... so there is no trace of it at all. If my friend sends directly to me@gmail.com, it shows up ... since his domain sends directly and the SPF test is passed. Note that on my gmail account, I associate me@mydomain.com with my me@gmail.com account ... so perhaps there should be a recipient test applied before SPF is tested on the sender ... although this arguably defeats the purpose of SPF.
The logical solution is to configure sendmail on my server to do Sender Rewriting — anyone have an easy FAQ to do this? But many people/domains aren't doing this ... and my Email forwarding to gmail is quite common, so I'm surprised that this issue hasn't gotten more attention. Is there another solution?"
What's *really* strange is that if I look at the raw sendmail logs on my server, the Email from friend@frienddomain.com comes in, and is forwarded to gmail ... with an "OK" as the response — i.e. the gmail MTA doesn't reject the message as it ideally should. However, the Email then disappears — it's not even in my gmail spam filter ... so there is no trace of it at all. If my friend sends directly to me@gmail.com, it shows up ... since his domain sends directly and the SPF test is passed. Note that on my gmail account, I associate me@mydomain.com with my me@gmail.com account ... so perhaps there should be a recipient test applied before SPF is tested on the sender ... although this arguably defeats the purpose of SPF.
The logical solution is to configure sendmail on my server to do Sender Rewriting — anyone have an easy FAQ to do this? But many people/domains aren't doing this ... and my Email forwarding to gmail is quite common, so I'm surprised that this issue hasn't gotten more attention. Is there another solution?"
That's outstandingly unhelpful. How about attaching a link to a decent SRS implementation? Or sending them to OpenSPF?
Randomly throwing down on people legitimately asking for some technical help is a big problem in the OSS community. Whether or not /. is the appropriate place to ask this question is debatable, but since it made the front page and there is no helpful SRS faq on this site, might as well direct them somewhere.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
It violates RFCs
I'm giving up mods to post this, but it really needs to be said.
People need to stop blaming things on services who pragmatically choose to violate selected aspects of decades-old standards that don't address today's realities. The problem with modern e-mail is that the standard is hopelessly out of touch with modern demands. There should long ago have been a consistent standard that covered things like sender authentication, encryption and signing, formatted messages ("HTML e-mails"), smart handling of errors without treating them all as e-mails in their own right, and numerous other fundamentally broken parts of the original e-mail specs. But there isn't, so people try to do reasonable things and stay as true to the standard as they can without being dogmatic about it when it's obviously a stupid thing to do.
So no, I don't think silent dropping needs to stop under all circumstances. E-mail has never had useful reliability of delivery (another thing a replacement standard should deal with) so you can't count on it anyway. On the other hand, I'm sick and tired of getting a deluge of hundreds of unwanted e-mails in ten minutes because someone sent out a mail with webmaster@my.domain as the sender, and loads of people who were confident enough that the message was spam to block it still sent back a bounce message to an address that is 99.99% likely to have been faked as well in that case. I'm sorry, but that's just antisocial behaviour, and responsible sysadmins should take steps to avoid it: if you're confident enough to refuse delivery, why aren't you confident enough not to reverse-spam the innocent bystander? If you're running a sensible service where a user can whitelist specific senders or switch off spam filtering altogether for specific receiving addresses if they want to guarantee receiving everything, and they've opted in to your spam filtering, this shouldn't be a problem.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.