You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Dan Barker <db...@visioncomm.net> on 2005/05/05 15:39:25 UTC
PTR Rules
I can't find any doc on PTR rules. Specifically, I'd like to make my
SpamAssassin 3.0.1 score if there is no PTR record for the first "foreign"
IP in the "Received by" chain.
This can't be difficult, but I've scanned the doc to the best of my ability
(my best may not be particularly good<g>) and come up empty.
Dan
Re: PTR Rules
Posted by Kevin Peuhkurinen <ke...@meridiancu.ca>.
Dan Barker wrote:
>I guess rnaiewno.com is the HELO or some such, because it sure isn't a name
>from 66.0! I guess I'm just screwed. We went from 2k emails a day (1900
>spam) to 4K with the latest worm, and SA doesn't appear to be able to help
>at all. Sigh.
>
>Dan
>
>
>
>
Dan, I have to agree with Matt here. Greylisting is the way to go. I
recently implemented greylisting under the following conditions:
1. Sending host uses IP address in HELO
2. Sending host uses my domain name in HELO
3. Sending host's address fails reverse DNS
4. Sending host's address is in APNIC or LACNIC
Doing this has utterly decimated the number of spams and viruses we have
to deal with. For instance, I hear that some companies have seen lots
of viruses over the last couple of days. Yesterday, out of almost 3000
incoming emails, only 33 had executable attachments. Meanwhile,
greylisting blocked almost 800 emails from being recieved. There's no
way of knowing how many of those 800 were spam versus virii, but the
number for the same day last week was only 540 so I think it is safe to
say that there were hundreds of virii in that figure. Remember as well
that since you are implementing this on the MTA before the data is sent,
you are saving tons of bandwidth as well as processing and storage
resources. It's enough to make a sysadmin dance a little jig just
thinking about it.
Kevin
RE: PTR Rules
Posted by Dan Barker <db...@visioncomm.net>.
It looks to me like your rule says if it's got a "([<ip address>", it's got
no PTR and if it's got a "{<something>[<ip address>" it has one. That could
be useful, except my mailer doesn't do such things.
Bad Header:
Received: from rnaiewno.com [66.0.118.65] by visioncomm.net
(SMTPD32-8.15) id A940495001E; Thu, 05 May 2005 11:18:24 -0400
Good Header:
Received: from dazed.lightbridge.com [206.35.13.66] by visioncomm.net with
ESMTP
(SMTPD32-8.15) id AD4A8D30072; Thu, 05 May 2005 11:35:38 -0400
I guess rnaiewno.com is the HELO or some such, because it sure isn't a name
from 66.0! I guess I'm just screwed. We went from 2k emails a day (1900
spam) to 4K with the latest worm, and SA doesn't appear to be able to help
at all. Sigh.
Dan
-----Original Message-----
From: Matt Kettler [mailto:mkettler@evi-inc.com]
Sent: Thursday, May 05, 2005 11:28 AM
To: Dan Barker
Cc: users@spamassassin.apache.org
Subject: Re: PTR Rules
Dan Barker wrote:
>I can't find any doc on PTR rules. Specifically, I'd like to make my
>SpamAssassin 3.0.1 score if there is no PTR record for the first "foreign"
>IP in the "Received by" chain.
>
>This can't be difficult, but I've scanned the doc to the best of my ability
>(my best may not be particularly good<g>) and come up empty.
>
>
>
There's no "easy" way to do this if you want SA to perform the PTR
lookup. You'd have to do that as a plugin, which involves writing some
perl code that makes use of Net::DNS.
However, if your mailserver normally does the lookup you can write a
regex to look for a Received: header from your MX that has no hostname.
Take this Received: header for example (sendmail generated)
Received: from eyou.com ([218.6.19.122]) by xanadu.evi-inc.com ....
Compared to
Received: from fsmail432.com (H1b65.h.pppool.de [85.72.27.101])
by xanadu.evi-inc.com ...
A rule like this would work for my mailserver:
header L_NO_RDNS_RCVD Received =~/from [\w.]{0,20}
\(\[\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\]\) .{0,50} by xanadu\.evi/
score L_NO_RDNS_RCVD 0.1
For what it's worth, I've seen a lot of legitimate servers lacking RDNS
entries, so I'd keep the score on this under 2.5.
(That said, one measure I do already take is I greylist all servers with
no RDNS.. Selective greylisting works pretty well. )
Re: PTR Rules
Posted by Matt Kettler <mk...@evi-inc.com>.
Dan Barker wrote:
>I can't find any doc on PTR rules. Specifically, I'd like to make my
>SpamAssassin 3.0.1 score if there is no PTR record for the first "foreign"
>IP in the "Received by" chain.
>
>This can't be difficult, but I've scanned the doc to the best of my ability
>(my best may not be particularly good<g>) and come up empty.
>
>
>
There's no "easy" way to do this if you want SA to perform the PTR
lookup. You'd have to do that as a plugin, which involves writing some
perl code that makes use of Net::DNS.
However, if your mailserver normally does the lookup you can write a
regex to look for a Received: header from your MX that has no hostname.
Take this Received: header for example (sendmail generated)
Received: from eyou.com ([218.6.19.122]) by xanadu.evi-inc.com ....
Compared to
Received: from fsmail432.com (H1b65.h.pppool.de [85.72.27.101])
by xanadu.evi-inc.com ...
A rule like this would work for my mailserver:
header L_NO_RDNS_RCVD Received =~/from [\w.]{0,20}
\(\[\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\]\) .{0,50} by xanadu\.evi/
score L_NO_RDNS_RCVD 0.1
For what it's worth, I've seen a lot of legitimate servers lacking RDNS
entries, so I'd keep the score on this under 2.5.
(That said, one measure I do already take is I greylist all servers with
no RDNS.. Selective greylisting works pretty well. )
Re: PTR Rules
Posted by "Eric A. Hall" <eh...@ehsco.com>.
On 5/5/2005 9:39 AM, Dan Barker wrote:
> I can't find any doc on PTR rules. Specifically, I'd like to make my
> SpamAssassin 3.0.1 score if there is no PTR record for the first
> "foreign" IP in the "Received by" chain.
>
> This can't be difficult, but I've scanned the doc to the best of my
> ability (my best may not be particularly good<g>) and come up empty.
http://www.rulesemporium.com/forums/showthread.php?s=&threadid=105 has a
collection of tests that look for this and some other SMTP "problem"
cases, using the X-Spam-Relays-Untrusted psuedo-header that spamassasin
generates during its testing.
If you don't want to use the meta ruleset, the specific sub-rule you want
from there is __L_RCVD_HOST_NO_RDNS:
#
# This rule looks at the top 'rdns' field of the X-Spam-Relays-Untrusted
# psuedo-header, and if the field value is null, it assumes that the
# server was unable to resolve the reverse-DNS lookup. Note that this
# can happen due to resolver difficulties with the server, delegation
# errors at the provider, or any number of other reasons, and should
# only be enabled judiciously. Also note that this rule will not fire
# if the HELO identifier is an IP address or domain-literal, or if the
# 'helo' field is empty.
#
This stuff seems to have proven pretty stable, so I guess I should find
out what's needed to get it formalized
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/