2

I run a very good anti-spam setup, except for one nagging little problem: Google.

Some legitimate users use Google's mail service with custom mail domains. In other words, they do not use a user@gmail.com sending identity, but their own.

I find that almost all SMTP traffic from a mail*.google.com host which is not from a @gmail.com sender, however, is spam. There is not a lot of it, but it's a nuisance.

These mails with custom domains don't seem to have any clue as to the Google identity of the originating user, so it is impossible to report the user to Google. You also obviously can't just blacklist Google servers because it's a very popular e-mail service with a large number of legitimate users.

(Of course, a user@gmail.com sender could also spam, but that doesn't seem to be a big problem at all; I can't remember the last time I saw a spam that directly identified a gmail account in any way. That makes me unconcerned about @gmail.com senders.)

Is there some good way to block the spam (ideally reject it at the SMTP level, without even looking at headers), while avoiding false positives: blocking non-spamming owners of custom mail domains who use Google for sending mail?

Kaz
  • 477
  • 2
  • 11
  • Surely specifying the email address (and other mail headers) should be enough when reporting this to Google? – Håkan Lindqvist Jun 11 '14 at 22:21
  • If you provide a bit of information about your mail server and your existing "anti-spam setup," perhaps we can provide more specific guidance as to how you can implement a solution. – Skyhawk Jun 11 '14 at 22:23
  • 1
    @HåkanLindqvist I don't want to waste my time reporting anything to Google. – Kaz Jun 11 '14 at 22:24
  • 2
    @Kaz I was merely commenting on your statement "These mails with custom domains don't seem to have any clue as to the Google identity of the originating user, so it is impossible to report the user to Google". If you don't want to "waste your time" reporting abuse I think you should edit the question to reflect this instead of claiming that it's not possible to do so for whatever reason. (This to avoid having people waste their time trying to help you.) – Håkan Lindqvist Jun 11 '14 at 22:33
  • 1
    I think you are jumping to conclusions. I see lots of legitimate email send through Gmail without using `@gmail.com` addresses. I see lots of spam using `@gmail.com` addresses but that is not send through Gmail. – kasperd Jun 11 '14 at 22:59
  • Agreed with @kasperd. I see a *lot* of legit traffic from google's SMTP servers that aren't gmail.com. In fact, non-gmail addresses far exceed gmail addresses. – EEAA Jun 11 '14 at 23:41
  • @kasperd Well, obviously I care about separating false positives from spam regardless of the ratio. – Kaz Jun 11 '14 at 23:44

1 Answers1

3

Absolutely. This is what SPF records are for. Read the Introduction to the Sender Policy Framework and implement SPF checking on your e-mail servers.

Skyhawk
  • 14,200
  • 4
  • 53
  • 95
  • 2
    Exactly. I cannot fathom what a "very good" anti spam setup looks like if it doesn't even consider SPF. – EEAA Jun 11 '14 at 22:25
  • Thanks a lot. So with SPF, basically we can have information, for a sender domain with a SPF record, that "yes, this domain routes through google". – Kaz Jun 11 '14 at 22:27
  • Yes. If there's no SPF record including "_spf.google.com", then it's not a properly configured Google Apps domain. Just implement SPF lookups and you'll be fine. – Skyhawk Jun 11 '14 at 22:34
  • Roger. But I'm now making it a priority to **publish** an SPF for my domain before dealing with this. – Kaz Jun 11 '14 at 22:37
  • @EEAA Turns out, I had already turned on SPF long ago. The particular messages I've received lately actually pass SPF, though! The issue is different; these are *backscatter* messages generated by some bounce robot at Google. The envelope sender is peculiar to that robot, and its sending domain is of course allowed for the IP address. Publishing my SPF (which I had neglected to do, but is now done and working!) might possibly protect me against such backscatter. I'm also blocking SMTP traffic from that particular "bounce bot" by its sender domain. – Kaz Jun 12 '14 at 01:50
  • Be sure to end your SPF record with "-all" instead of "~all" unless you have a really good reason to expect potentially valid mail to come from unlisted servers. – Skyhawk Jun 12 '14 at 03:52