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.
Ted
* The reason this is NOT mandated anywhere is because if it was then
sites running multiple mailing domains on a single server could easily
overflow the DNS UDP packet space with a list of PTR's for the server -
causing the resolver to exceed 512 bytes on the DNS UDP response, or
causing a switch to TCP - either of which can break some firewalls.
For example the Cisco PIX came standard out-of-the-box with a DNS
filter that blocked DNS UDP packets larger than 512.
