Live data from Hacker News

The Cat-And-Mouse Story of Implementing Anti-Spam for Mail.ru

highscalability.com

1–10 of 28 posts

Re: The Cat-And-Mouse Story of Implementing Anti-Spam for Mail.ru

#3
One powerful rule that I use in my Exim setup is to drop any SMTP connection that doesn't have forward and backward DNS that match. This catches a big majority of all spam, with hardly any false positive downside. No credible in SMTP forwarding host has broken DNS (by definition, practically). Lots of spamming machines do. Of course, not all, but this is a game of percentages and multiple stages.

Re: The Cat-And-Mouse Story of Implementing Anti-Spam for Mail.ru

#5

One powerful rule that I use in my Exim setup is to drop any SMTP connection that doesn't have forward and backward DNS that match. This catches a big majority of all spam, with hardly any false positive downside. No credible in SMTP forwarding host has broken DNS (by definition, practically). Lots of spamming machines do. Of course, not all, but this is a game of percentages and multiple stages.

You'll definitely lose email from Amazon SES then. What about checking SPF records instead?

Re: The Cat-And-Mouse Story of Implementing Anti-Spam for Mail.ru

#7
post #5

One powerful rule that I use in my Exim setup is to drop any SMTP connection that doesn't have forward and backward DNS that match. This catches a big majority of all spam, with hardly any false positive downside. No credible in SMTP forwarding host has broken DNS (by definition, practically). Lots of spamming machines do. Of course, not all, but this is a game of percentages and multiple stages.

You'll definitely lose email from Amazon SES then. What about checking SPF records instead?

My darned residential cable line has forward and reverse DNS that match.

If the Amazon SES can't figure this out, they have no business sending SMTP e-mail.

I do apply the SPF check and reject the SMTP if it comes up as a confirmed negative: the sending domain has an SPF record, with strict semantics, and the IP doesn't match.

SPF speaks to a different problem (not the problem of "is this host a spammy host?"), and generally has no teeth. Passing SPF only informs me that the IP address sending to me is allowed to use the given envelope sender domain. A spammer can register a bunch of domains and set up SPF records for them, and then use the domains as envelope addresses. (Of course, these envelope sender addresses don't necessarily have anything to do with what is in the From: header).

You can't expect some sort of free pass just because you made a SPF record. What the SPF record does is protect your domain from being used by other people the bases of a sender envelope address. This is of low value, because most recipients don't even see the envelope address.

SPF can be applied against From: too but that's fraught with problems, because of forwarding via mailing lists, or people using alternative sending identities which are legitimate.

Re: The Cat-And-Mouse Story of Implementing Anti-Spam for Mail.ru

#8
post #6

You suck! I ran an email server from my home for several years. I could get a static ip but my isp wouldn't set my rdns for some reason. I had both spf and dkim correctly configured but people like you eventually forced me to move to commercial hosting.

Resolving MX records from your home and contacting hosts directly on their port 25 is a nonstarter. I wouldn't even think of doing it. Instead, I forward to my ISP's SMTP forwarding hosts (via an authenticated SMTP connection).

It's not necessarily the "working DNS" rule that will reject you, but other methods, like anti-spam databases that list residential line IP addresses. For example, my residential line, in fact, has forward and backward DNS that match. If I directly contact someone's mail server which has this rule, I can get past that rule. That's not what will "get" me.

Re: The Cat-And-Mouse Story of Implementing Anti-Spam for Mail.ru

#9

One powerful rule that I use in my Exim setup is to drop any SMTP connection that doesn't have forward and backward DNS that match. This catches a big majority of all spam, with hardly any false positive downside. No credible in SMTP forwarding host has broken DNS (by definition, practically). Lots of spamming machines do. Of course, not all, but this is a game of percentages and multiple stages.

So, do you require the PTR and A records of the remote host to match?

Re: The Cat-And-Mouse Story of Implementing Anti-Spam for Mail.ru

#10
post #6

You suck! I ran an email server from my home for several years. I could get a static ip but my isp wouldn't set my rdns for some reason. I had both spf and dkim correctly configured but people like you eventually forced me to move to commercial hosting.

Resolving MX records from your home and contacting hosts directly on their port 25 is a nonstarter. I wouldn't even think of doing it. Instead, I forward to my ISP's SMTP forwarding hosts (via an authenticated SMTP connection). It's not necessarily the "working DNS" rule that will reject you, but other methods, like anti-spam databases that list residential line IP addresses. For example, my residential line, in fact…

> Resolving MX records from your home and contacting hosts directly on their port 25 is a nonstarter.

Google, Yahoo, and Microsoft accepted mail from my server without any issues. My server never sent spam and was never on spam blacklists.

What's your problem? Maybe you suck.

Post reply on HN