Hacker News Reader

Comment by reidrac | Hacker News Reader

It's been years since I last did some serious email hosting, but it looks like the SPF rule is the problem.

Google is forwarding mail for dnalounge.com but the SPF rule doesn't allow Google's SMTP servers to do that: "v=spf1 a mx ptr ~all". That could explain why the email gets in the spam box; failing SFP should increase the "spam score".

Besides I think SOFTFAIL shouldn't be used in production; and I also doubt that Google should be taking seriously a SOFTFAIL anyway; so please take this comment with a pinch of salt.

SPF is easy to get wrong, and it always backfires at you ;)

EDIT: seems that I may be right, according to this comment http://www.jwz.org/blog/2015/03/google-seems-to-have-broken-...

View on HN

Gmail's "send as" feature doesn't work that way.

"A@dnalounge.com is logged in to GMail Web Client as A@gmail.com and sends a message to B@dnalounge.com. Google's SMTP servers deliver that to cerebrum.dnalounge.com with an envelope sender of A@gmail.com. (THIS IS WRONG ON SO MANY LEVELS.) cerebrum turns around and bent-pipe forwards back to Google's SMTP servers, who determine that Google's SPF record doesn't list cerebrum as a designated sender for gmail.com (given the preserved envelope sender of A@gmail.com)."

http://www.jwz.org/blog/2015/03/google-seems-to-have-broken-...

In my >5 years experience running a mail server through which gmail users send authenticated mail, that is not accurate. To confirm that nothing has changed, I just looked at the mail logs, and in the last 24 hours I don't see a single instance of gmail doing what is described. In every single case, the envelope sender address is user@mydomain, not user@gmail.com.

Are the users' gmail accounts 'gmail.com' or 'mydomain'? Because I've sent mail from servers using a google mailbox to authenticate, and the from field was overwritten with the name of the mailbox used.

The users' gmail accounts are at user@gmail.com, but they're sending mail as user@mydomain, via mydomain's authenticated SMTP server. This is exactly the scenario described in the comment at jwz.org.

I read it as the opposite of jwz. You say your users are sending mail via "mydomain" SMTP. jwz says his users are sending mail "from their phone up to Google's SMTP server".

The goog then sends mail to the receiver at 'dnalounge' MX, where it's then shuffled back to the receiver's gmail mailbox. I don't read his setup as having the sender involved with the dnalounge SMTP server at all.

~all is exactly the problem.

Shame this comment isn't further up.

I have a similar setup, and upon reading the RFC, I though ~all was the flag for the desired behavior. Turns out, it's not.

You are correct. SOFTFAILs should not be used and they will cause problems.

> SOFTFAILs should not be used and they will cause problems

Many SPF docs recommend using SOFTFAILs, including Gmail's docs [1]. What's your recommended SPF setup for his use case?

[1] https://support.google.com/a/answer/178723?hl=en

SOFTFAIL is only contributing to the anti-spam score (in theory) as it is supposed to allow the mail pass, but the host is still unauthorized [1].

Using "~all" means that you can only tell which hosts are definitely allowed to send mail for the domain, and you're unsure of anything else.

IMHO that reduces the effectivity of SPF. SOFTFAIL is useful as a debug method when you're testing rules and you don't want mail to be rejected by mistake; but I think it should be transitory and finally replaced by FAIL ("-all").

If you configure SPF to allow mail being delivered by Google's SMTP servers for that domain, you're again reducing its effectivity (Google's SMTP servers are used to send spam); but still better than a "SOFTFAIL all" I think :)

[1] http://www.openspf.org/RFC_4408#op-result-softfail

It's been some time since I ran my own mail server, but from what I recall, some spam filters actually give more negative weight (i.e. message is more likely to be spam) to a SOFTFAIL (~all) than a FAIL (-all), even though this contrary to the spec.

Spamassassin's rationale was that many of the tutorials online never explained the difference, so the majority of mailservers were just using SOFTFAIL everywhere. More paradoxically, messages that had a hard FAIL result were statistically more likely to be due to a misconfiguration, based on an empirical analysis.

Like I said though, it's been quite a while since I've had to deal with this. I'm not sure if it's still true or not.

Reply on news.ycombinator.com