On 01/11/2010 12:42 PM, Ted Mittelstaedt wrote:
Terry Carmen wrote:
On 01/11/2010 05:22 AM, Jason Haar wrote:
Hi there
We've been getting a few of these leaking through in the past couple of
weeks.
http://pastebin.com/m574da717
They aren't triggering (enough) network rule matches, contain a
bayes-killer, and even FuzzyOCR can't manage the swirly image trick
they
pull. Has anyone come up with a way to fight these? (I've actually
added
all the phrases that occur in this image to FuzzyOCR - didn't help)
Unless you changed the headers, it looks like it came from an IP with
no reverse DNS entry.
This is easy enough to stop dead in it's tracks at your MTA. If there
isn't any reverse DNS, the chances of it being a legitimate mail
server are pretty slim.
This is the WRONG way to do this - it amazes me that in 2010 on an
anti-spam mailing list that we have people making such statements.
The SMTP RFC 2821 does NOT mandate the existence of a PTR record for
an SMTP sender. The DNS RFC 1912 also does not mandate a
corresponding PTR
for a mailserver hostname. Implies, yes, but there's no requirement.
There is a very good reason for this.* Blocking at the MTA based on
the lack of a PTR record is incorrect. The correct way is to assign a
spam score in SA to hosts lacking a PTR, the same way you do to mail
that contains HTML, etc.
SA is great software, but scanning is not a lightweight process. If I
can ditch millions of spams before they ever hit SA, and need to
manually whitelist a couple of IPs, that's a great deal as far as I'm
concerned.
Every reasonable ISP I've seen has managed to assign a PTR record for
their mail server. I don't care if it exactly every (or any) domain they
transport mail for, as long as it exists. Sure, it's possible to break
things if you work at it hard enough, but generally speaking, I don't care.
Terry
