You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Jason Bertoch <ja...@i6ix.com> on 2010/12/29 16:54:04 UTC
Single dot PTR
I'm starting to see a (new to me) pattern of spam, and only spam, with
PTR records consisting of a single dot, such as:
Received: from ejru38.pindmosel.info (. [184.154.78.38] (may be forged))
It doesn't appear that there is a stock rule yet to identify this
particular case. RDNS_NONE matches, but I believe a more specific rule
may be in order, or maybe even something at the MTA level if this
pattern proves reliable. Has anyone else identified this pattern in
their mail flow?
--
/Jason
Re: Single dot PTR
Posted by mouss <mo...@ml.netoyen.net>.
Le 29/12/2010 16:54, Jason Bertoch a écrit :
>
> I'm starting to see a (new to me) pattern of spam, and only spam, with
> PTR records consisting of a single dot, such as:
>
> Received: from ejru38.pindmosel.info (. [184.154.78.38] (may be forged))
I used to block these and others in postfix:
pcre = pcre:/etc/postfix/maps/pcre
db = cdb:/etc/postfix/maps/cdb
smtpd_recipient_restrictions =
...
reject_unauth_destination
...
check_helo_access ${pcre}/access_host
check_reverse_client_hostname_access ${pcre}/access_host
== /etc/postfix/maps/pcre/access_host
/^\.$/ REJECT invalid PTR (single dot)
/^.(arpa|invalid|inv|local|lokaal|private|root|kornet|speedportw700v|firewall|home)$/
REJECT blah blah
...
>
> It doesn't appear that there is a stock rule yet to identify this
> particular case. RDNS_NONE matches, but I believe a more specific rule
> may be in order, or maybe even something at the MTA level if this
> pattern proves reliable. Has anyone else identified this pattern in
> their mail flow?
>
header PTR_DOT_ONLY X-Spam-Relays-External =~ /^[^\]]+ rdns=\. /i
we can also try catching bogus TLD's: .arpa, kornet, speedportw700v, ...
header PTR_BOGUS_TLD X-Spam-Relays-External =~ /^[^\]]+
rdns=\S+\.(?:arpa|kornet|speedportw700v|invalid) /i
Re: Single dot PTR
Posted by Jason Bertoch <ja...@i6ix.com>.
On 2010/12/29 11:55 AM, Benny Pedersen wrote:
> On ons 29 dec 2010 17:29:05 CET, Jason Bertoch wrote
>> In the sited example, yes, the PTR is set by the ISP and not delegated
>> to the spammer, but a pattern is a pattern and that's what we're here
>> for. Plus, for all we know, the ISP has a web interface for setting
>> PTR records rather than using delegation.
>
> its not fqdn with just a dot, is your mta sendmail ?
>
Yes, but I like to test in SA and consult peers before putting a boolean
axe in sendmail.
> and my isp sets my ptr yes, but thay will have to make sure i did add it
> as a a record first, the spammers isp above is clueless in that term
>
> i think its the way it should be in a perfect world
>
Agreed, and that's how I run PTR records on my network. Plus, I cron
checks that the PTR records continue to match over time.
--
/Jason
Re: Single dot PTR
Posted by Benny Pedersen <me...@junc.org>.
On ons 29 dec 2010 17:29:05 CET, Jason Bertoch wrote
> In the sited example, yes, the PTR is set by the ISP and not
> delegated to the spammer, but a pattern is a pattern and that's what
> we're here for. Plus, for all we know, the ISP has a web interface
> for setting PTR records rather than using delegation.
its not fqdn with just a dot, is your mta sendmail ?
and my isp sets my ptr yes, but thay will have to make sure i did add
it as a a record first, the spammers isp above is clueless in that term
host 2.104.223.10
gives home.junc.org
dig home.junc.org
gives 2.104.223.10
i think its the way it should be in a perfect world
--
xpoint http://www.unicom.com/pw/reply-to-harmful.html
Re: Single dot PTR
Posted by Jason Bertoch <ja...@i6ix.com>.
On 2010/12/29 11:42 AM, Adam Moffett wrote:
>
>> In the sited example, yes, the PTR is set by the ISP and not delegated
>> to the spammer, but a pattern is a pattern and that's what we're here
>> for. Plus, for all we know, the ISP has a web interface for setting
>> PTR records rather than using delegation.
>>
> In the cited example, I picked a few others IP's at random that were in
> the same /16 and they all had a period for a PTR record. I think you
> would just score up anything that came from that ISP.
I understand that a rule of this type will likely penalize an ISP if it
is their policy for PTR records, but I've not seen the volume of this
pattern in the past that I'm seeing now. In my case, 100% has been spam
and has sourced from numerous address blocks, not just a single ISP.
> If that ISP is a
> consistent source of spam they'll end up in one or more of the RBL's and
> the message will already get scored up.
>
While many of these are already flagged by BL's, not all are. Plus, we
wouldn't need SA at all if we sat back and waited for BL's to identify
and block for us.
> I'm not trying to be a killjoy, I just find it hard to believe that the
> period PTR is meaningful. I've been wrong once or twice though.
>
I understand. The intent of the original question was to see if anyone
else had identified this pattern and found it useful or had any ham from
an unfortunate configuration like this.
--
/Jason
Re: Single dot PTR
Posted by Jason Bertoch <ja...@i6ix.com>.
On 2010/12/29 11:24 AM, Adam Moffett wrote:
> The PTR is set by the ISP, not the spammer. My guess would be that the
> period for a PTR would be a policy of a particular network operator or
> group of operators. So matching it in spam assassin would be scoring
> messages on the ISP they came from rather than their spaminess.
In the sited example, yes, the PTR is set by the ISP and not delegated
to the spammer, but a pattern is a pattern and that's what we're here
for. Plus, for all we know, the ISP has a web interface for setting PTR
records rather than using delegation.
--
/Jason
Re: Single dot PTR
Posted by Adam Moffett <ad...@plexicomm.net>.
The PTR is set by the ISP, not the spammer. My guess would be that the
period for a PTR would be a policy of a particular network operator or
group of operators. So matching it in spam assassin would be scoring
messages on the ISP they came from rather than their spaminess.
>
> I'm starting to see a (new to me) pattern of spam, and only spam, with
> PTR records consisting of a single dot, such as:
>
> Received: from ejru38.pindmosel.info (. [184.154.78.38] (may be forged))
>
> It doesn't appear that there is a stock rule yet to identify this
> particular case. RDNS_NONE matches, but I believe a more specific
> rule may be in order, or maybe even something at the MTA level if this
> pattern proves reliable. Has anyone else identified this pattern in
> their mail flow?
>