Messaging Gateway

A couple of blatant spams today got through BMG, about four hours apart, source is the same IP.

Checked reputation in the BMG UI, that IP is not on any bad reputation lists. (78.129.221.169 - seems to be owned by Rapidswitch Ltd in the UK)

OK, that's not the biggest news in the world, but the spammer forged a Gmail address in the MAIL FROM, and clearly this was not delivered from a Google IP address, so given that Google has working SPF records, why didn't BMG block these messages?

(Aside: I note that the message used TLS. Ever since I enabled TLS on this box, I've noticed that some spammers seem to prefer it, perhaps because it obscures the message content to some systems? They never seem to provide a certificate, but I can't see a way to enforce that.)

Google and Gmail do not have SPF records that have a hard fail (-all). It's my understanding that the SBG will ignore any records that don't have a hard fail.

Check here: http://spf-all.com

Oh, lovely. So they have an SPF record that essentially serves no purpose whatsoever (the "?all" token seems to mean essentially zero), and they are the only major webmail provider I know of which allows webmail users to send messages without any source IP information ever visible in email headers. (making them the favorite of Nigerian scammers)

Sometimes I really hate that company.

Thanks for the info.

Hi,

We noticed spammers using TLS when sending spam earlier on this year from the rustock botnet. More details in this blog: http://www.symantec.com/connect/blogs/death-thousand-cuts-rustock-botnet-sending-more-encrypted-spam

Levels had subsided since though.

Amanda

Amanda - thanks for the link to that interesting and detailed blog post.

My wishlist for BMG includes being able to force certificate presentation for all TLS transactions.

And after reading that blog post, a mechanism to only require TLS for certain connecting clients after they've authenticated. (Which actually wouldn't impact us because we're only using it for an incoming gateway and not as a relay)

I may just turn TLS off for incoming, since that's not our primary security concern, considering all the other places in the message chain (that we have no control over) where a message might be transported in plaintext.