New spammer check: too many PTRs

[Chris Wilson-30]

Hi all,

I just found the following unusual message in my Exim logs:

   2009-06-27 21:14:58 host name alias list truncated for 69.10.169.230

Curious, I did a DNS lookup on that IP:

   chris@top ~ $ host 69.10.169.230 | wc -l
   86

   chris@top ~ $ host 69.10.169.230 | head -5
   ;; Truncated, retrying in TCP mode.
   230.169.10.69.in-addr.arpa domain name pointer heavenlydonut.com.
   230.169.10.69.in-addr.arpa domain name pointer pitrivertribe.org.
   230.169.10.69.in-addr.arpa domain name pointer shastawebmail.com.
   230.169.10.69.in-addr.arpa domain name pointer vidalvineyard.com.

Looks like a spammer to me :)

Luckily, Exim provides a way to match senders like this:

   defer
         set acl_c_ptr_count = ${reduce {${lookup dnsdb{>: \
                 ptr=$sender_host_address}}} {0} {${eval:$value+1}}}
         condition = ${if >{$acl_c_ptr_count}{4}}
         message = Too many PTR records ($acl_c_ptr_count)

This matches any host with more than four PTR records. I based the reduce
operation on the one in the manual.
[http://www.exim.org/exim-html-current/doc/html/spec_html/ch11.html#SECTexpcond]

Although this is pretty ugly. I don't suppose anyone wants to implement a
"count" operation to count the number of items in a list? Or would accept
a patch for same?

Cheers, Chris.
--
_____ __     _
\  __/ / ,__(_)_  | Chris Wilson <0000 at qwirx.com> - Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer |
\__/_/_/_//_/___/ | We are GNU : free your mind & your software |

--
## List details at http://lists.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

[Aaron Wolfe]

On Sat, Jun 27, 2009 at 4:51 PM, Chris Wilson<chris+exim@...> wrote:

> Hi all,
>
> I just found the following unusual message in my Exim logs:
>
>   2009-06-27 21:14:58 host name alias list truncated for 69.10.169.230
>
> Curious, I did a DNS lookup on that IP:
>
>   chris@top ~ $ host 69.10.169.230 | wc -l
>   86
>
>   chris@top ~ $ host 69.10.169.230 | head -5
>   ;; Truncated, retrying in TCP mode.
>   230.169.10.69.in-addr.arpa domain name pointer heavenlydonut.com.
>   230.169.10.69.in-addr.arpa domain name pointer pitrivertribe.org.
>   230.169.10.69.in-addr.arpa domain name pointer shastawebmail.com.
>   230.169.10.69.in-addr.arpa domain name pointer vidalvineyard.com.
>
> Looks like a spammer to me :)
>

Although having multiple PTRs is a bad idea and generally doesn't work
as desired anyway, there are 'legitimate' mail hosts that have them.
I recently had to troubleshoot a problem with a mail server that
rejected mail from hosts with "bad" ptrs that was rejecting mail from
a desired source.  Turned out the sender had over 100 PTR records, and
one of them matched, but the receiving mail server (or its resolver)
only looked at the first answer in the list.  I'd only use this in
combination with other sins for blocking purposes.

> Luckily, Exim provides a way to match senders like this:
>
>   defer
>         set acl_c_ptr_count = ${reduce {${lookup dnsdb{>: \
>                 ptr=$sender_host_address}}} {0} {${eval:$value+1}}}
>         condition = ${if >{$acl_c_ptr_count}{4}}
>         message = Too many PTR records ($acl_c_ptr_count)
>
> This matches any host with more than four PTR records. I based the reduce
> operation on the one in the manual.
> [http://www.exim.org/exim-html-current/doc/html/spec_html/ch11.html#SECTexpcond]
>
> Although this is pretty ugly. I don't suppose anyone wants to implement a
> "count" operation to count the number of items in a list? Or would accept
> a patch for same?
>
> Cheers, Chris.
> --
> _____ __     _
> \  __/ / ,__(_)_  | Chris Wilson <0000 at qwirx.com> - Cambs UK |
> / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer |
> \__/_/_/_//_/___/ | We are GNU : free your mind & your software |
>
> --
> ## List details at http://lists.exim.org/mailman/listinfo/exim-users
> ## Exim details at http://www.exim.org/
> ## Please use the Wiki with this list - http://wiki.exim.org/
>

--
## List details at http://lists.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

[W B Hacker]

Aaron Wolfe wrote:

> On Sat, Jun 27, 2009 at 4:51 PM, Chris Wilson<chris+exim@...> wrote:
>> Hi all,
>>
>> I just found the following unusual message in my Exim logs:
>>
>>   2009-06-27 21:14:58 host name alias list truncated for 69.10.169.230
>>
>> Curious, I did a DNS lookup on that IP:
>>
>>   chris@top ~ $ host 69.10.169.230 | wc -l
>>   86
>>
>>   chris@top ~ $ host 69.10.169.230 | head -5
>>   ;; Truncated, retrying in TCP mode.
>>   230.169.10.69.in-addr.arpa domain name pointer heavenlydonut.com.
>>   230.169.10.69.in-addr.arpa domain name pointer pitrivertribe.org.
>>   230.169.10.69.in-addr.arpa domain name pointer shastawebmail.com.
>>   230.169.10.69.in-addr.arpa domain name pointer vidalvineyard.com.
>>
>> Looks like a spammer to me :)

Chris,

Why not have a look at the websites for those domain.tld?

All four seem to be quite legitimate.

What they have in common (do a whois on the IP block holder), is use of the
services of 'shasta.com' - who's website ALSO appears to be legitimate.

Should your server be receiving this traffic?

Pass.

They could be sloppy, or have easily compromised client services or web pages.

But they seem to be entirely too 'visible' to be criminally inclined.

>>
>
> Although having multiple PTRs is a bad idea and generally doesn't work
> as desired anyway, there are 'legitimate' mail hosts that have them.

Aaron,

Correct. Hosting multiple mail domains is one of the few, and rare, but
necessary, reasons for having mulitple <domain>.<tld> homes onto one/few IP.
Low-budget e-commerce *can* be another.

And is provided for in the applicable RFC's.

And is listed as a 'possibly OK' by DNS analysis tools.

> I recently had to troubleshoot a problem with a mail server that
> rejected mail from hosts with "bad" ptrs that was rejecting mail from
> a desired source.  Turned out the sender had over 100 PTR records, and
> one of them matched, but the receiving mail server (or its resolver)
> only looked at the first answer in the list.  I'd only use this in
> combination with other sins for blocking purposes.
>

Chirs,

'Sins' yes. 'Other sins' not.

This one is not a 'sin' - just not common.

>
>> Luckily, Exim provides a way to match senders like this:
>>
>>   defer
>>         set acl_c_ptr_count = ${reduce {${lookup dnsdb{>: \
>>                 ptr=$sender_host_address}}} {0} {${eval:$value+1}}}
>>         condition = ${if >{$acl_c_ptr_count}{4}}
>>         message = Too many PTR records ($acl_c_ptr_count)
>>
>> This matches any host with more than four PTR records. I based the reduce
>> operation on the one in the manual.
>> [http://www.exim.org/exim-html-current/doc/html/spec_html/ch11.html#SECTexpcond]
>>
>> Although this is pretty ugly. I don't suppose anyone wants to implement a
>> "count" operation to count the number of items in a list? Or would accept
>> a patch for same?
>>
>> Cheers, Chris.
>> --

All,

What Exim does already (kindly peruse ~/src/hosts.c) is to build lists and
evaluate for a 'reasonable' match.

And it works as it should. Calling for reverse_host_lookup will pass - ditto a
HELO check - so long as 'among' the multiple PTR returned one is found that matches.

Spambots, OTOH, seldom have even ONE non-generic PTR RR that can pass.

That said, there *are* DNS-registered, rules-abiding, non-bot but still
unwelcome-to-many agencies that are in the direct marketing 'business'.

Some of these MAY utilize multiple domain to PTR mapping, but rarely so, as
these are usually sufficiently well-funded to have access to largish blocks of
IP's and do not need to to this.

Better to specifically BL such critters when you find them being rude to your
client base.

Chris,

Your ruleset (above) is more likely to slam bystanders - those using budget
hosting services of ISP's who have few IP's and are trying to do the best they
can with regard to DNS entries for their mail or online e-commerce services.

Better to catch those on unwelcome content or such.

  If any.

Speaking of which - you have not told us if the message coming from that IP was
in fact unwelcome.

>> _____ __     _
>> \  __/ / ,__(_)_  | Chris Wilson <0000 at qwirx.com> - Cambs UK |
>> / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer |
>> \__/_/_/_//_/___/ | We are GNU : free your mind & your software |
>>
>> --

  ... have a care what that 'freed' mind is *aimed* at...

;-)

Bill


--
## List details at http://lists.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

[Chris Wilson-30]

Hi Bill,

On Sun, 28 Jun 2009, W B Hacker wrote:

>>>   chris@top ~ $ host 69.10.169.230 | head -5
>>>   ;; Truncated, retrying in TCP mode.
>>>   230.169.10.69.in-addr.arpa domain name pointer heavenlydonut.com.
>>>   230.169.10.69.in-addr.arpa domain name pointer pitrivertribe.org.
>>>   230.169.10.69.in-addr.arpa domain name pointer shastawebmail.com.
>>>   230.169.10.69.in-addr.arpa domain name pointer vidalvineyard.com.
>>>
>>> Looks like a spammer to me :)
>
> Chris,
>
> Why not have a look at the websites for those domain.tld?
>
> All four seem to be quite legitimate.

Good point :) I hadn't looked at the sites. They do look legit.

> What they have in common (do a whois on the IP block holder), is use of
> the services of 'shasta.com' - who's website ALSO appears to be
> legitimate.
>
> Should your server be receiving this traffic?

No:

2009-06-27 21:14:58 host name alias list truncated for 69.10.169.230
2009-06-27 21:15:03 no IP address found for host dynamicessentialsinc.co
   (during SMTP connection from [69.10.169.230])
2009-06-27 21:15:03 no IP address found for host
   palocedrocommunitypark.org (during SMTP connection from [69.10.169.230])
2009-06-27 21:15:07 no IP address found for host mantonvin.com (during
   SMTP connection from [69.10.169.230])
2009-06-27 21:15:14 H=youthgotohealth.org (localhost) [69.10.169.230]
   rejected EHLO or HELO localhost: Invalid HELO

I don't like people who say HELO localhost. They go in my sin bin.

>> Although having multiple PTRs is a bad idea and generally doesn't work
>> as desired anyway, there are 'legitimate' mail hosts that have them.
>
> Correct. Hosting multiple mail domains is one of the few, and rare, but
> necessary, reasons for having mulitple <domain>.<tld> homes onto one/few
> IP. Low-budget e-commerce *can* be another.

Why bother with PTRs in that case?

> Spambots, OTOH, seldom have even ONE non-generic PTR RR that can pass.

Yes, because that requires control of the reverse DNS, and zombies don't
control their reverse DNS. This case made me think that the site was a
full-on spamming operation.

> Your ruleset (above) is more likely to slam bystanders - those using
> budget hosting services of ISP's who have few IP's and are trying to do
> the best they can with regard to DNS entries for their mail or online
> e-commerce services.

Well, I've never seen a host with so many PTRs before in the 10 years that
I've known how to check, so I'm mighty suspicious, but OK.

> Speaking of which - you have not told us if the message coming from that
> IP was in fact unwelcome.

Never found out. HELO localhost -> bad boy.

Cheers, Chris.
--
_____ __     _
\  __/ / ,__(_)_  | Chris Wilson <0000 at qwirx.com> - Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer |
\__/_/_/_//_/___/ | We are GNU : free your mind & your software |

--
## List details at http://lists.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

[W B Hacker]

Chris Wilson wrote:

> Hi Bill,
>
> On Sun, 28 Jun 2009, W B Hacker wrote:
>
>>>>   chris@top ~ $ host 69.10.169.230 | head -5
>>>>   ;; Truncated, retrying in TCP mode.
>>>>   230.169.10.69.in-addr.arpa domain name pointer heavenlydonut.com.
>>>>   230.169.10.69.in-addr.arpa domain name pointer pitrivertribe.org.
>>>>   230.169.10.69.in-addr.arpa domain name pointer shastawebmail.com.
>>>>   230.169.10.69.in-addr.arpa domain name pointer vidalvineyard.com.
>>>>
>>>> Looks like a spammer to me :)
>> Chris,
>>
>> Why not have a look at the websites for those domain.tld?
>>
>> All four seem to be quite legitimate.
>
> Good point :) I hadn't looked at the sites. They do look legit.
>
>> What they have in common (do a whois on the IP block holder), is use of
>> the services of 'shasta.com' - who's website ALSO appears to be
>> legitimate.
>>
>> Should your server be receiving this traffic?
>
> No:
>
> 2009-06-27 21:14:58 host name alias list truncated for 69.10.169.230
> 2009-06-27 21:15:03 no IP address found for host dynamicessentialsinc.co
>    (during SMTP connection from [69.10.169.230])
> 2009-06-27 21:15:03 no IP address found for host
>    palocedrocommunitypark.org (during SMTP connection from [69.10.169.230])
> 2009-06-27 21:15:07 no IP address found for host mantonvin.com (during
>    SMTP connection from [69.10.169.230])
> 2009-06-27 21:15:14 H=youthgotohealth.org (localhost) [69.10.169.230]
>    rejected EHLO or HELO localhost: Invalid HELO
>
> I don't like people who say HELO localhost. They go in my sin bin.

One can be stricter on that score rather easily as the RFC at least 'expects'
that a HELO match to a FQDN.

OTOH, pooled mail servers of major ISP's so often are among major / careless
violators that we've dropped to non-fatal 'demerits' points in stead of outright
rejection.

Passing reverse_host_lookup, OTOH, we are adamant about, so at least whatever
arrives at HELO with flaws is more likely to be 'odd' rather than ouright
missing. That said, 'localhost', our own ID, and obvious forgeries remain
hard-fails.

>
>>> Although having multiple PTRs is a bad idea and generally doesn't work
>>> as desired anyway, there are 'legitimate' mail hosts that have them.
>> Correct. Hosting multiple mail domains is one of the few, and rare, but
>> necessary, reasons for having mulitple <domain>.<tld> homes onto one/few
>> IP. Low-budget e-commerce *can* be another.
>
> Why bother with PTRs in that case?
>

Multiple assignment in no way compromises the intent of a PTR RR.

Taken one <domain>.<tld> at a time, the reverse lookup is just as valid a means
of associating a <domain>.<tld> to a specific IP when there are 130+ (the most I
have seen) as when there is only one.

That is all a PTR RR is expected to do.

Any further discrimination or 'steering' is the job of either other DNS records
as MX, A, CNAME, may or may not be on the same box(es), or left to local
server(s) and/or router(s).

>> Spambots, OTOH, seldom have even ONE non-generic PTR RR that can pass.
>
> Yes, because that requires control of the reverse DNS, and zombies don't
> control their reverse DNS. This case made me think that the site was a
> full-on spamming operation.
>

It *could have* been. But not just because of multiple PTR RR assignment.

>> Your ruleset (above) is more likely to slam bystanders - those using
>> budget hosting services of ISP's who have few IP's and are trying to do
>> the best they can with regard to DNS entries for their mail or online
>> e-commerce services.
>
> Well, I've never seen a host with so many PTRs before in the 10 years that
> I've known how to check, so I'm mighty suspicious, but OK.
>

Two or three are not uncommon. Think centralized mail for .com, .org, .net of
the same <domain> different <tld> held by the same entity.

I've seen over 130, wherein an ISP tried diligently to list every customer's
<domain>.<tld>.

Experience says that it is generally better to use a shared and innocuous 'none
of the above' <domain>.<tld> to service outbound mail for all-hands when in a
multi-entity environment.

This primarily because the receiving server will more often list in a 'received'
header the first <domain>.<tld> returned, not bother with parsing the list to
grab a specific match to a HELO 'steered' with helo_data or other-than-Exim
equivalent *even if* it has actually done so separately to 'vet' the incoming.

>> Speaking of which - you have not told us if the message coming from that
>> IP was in fact unwelcome.
>
> Never found out. HELO localhost -> bad boy.
>
> Cheers, Chris.

Given the specific IP (above) I suspect it was more likely a fool than a
charlatan, but there is a a saying about that distinction... so an infected
machine is also a possibility, and 'fair enough'. let *them* fix that problem if
htey want mail to flow.

But that should not lead one into an extra ruleset that penalizes those using
PTR RR in a quite 'legal', if less-common manner.

That relationship is only coincidental.

Best,

Bill

--
## List details at http://lists.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

[Aaron Wolfe]

On Sun, Jun 28, 2009 at 11:16 AM, W B Hacker<wbh@...> wrote:

> Chris Wilson wrote:
>> Hi Bill,
>>
>> On Sun, 28 Jun 2009, W B Hacker wrote:
>>
>>>>>   chris@top ~ $ host 69.10.169.230 | head -5
>>>>>   ;; Truncated, retrying in TCP mode.
>>>>>   230.169.10.69.in-addr.arpa domain name pointer heavenlydonut.com.
>>>>>   230.169.10.69.in-addr.arpa domain name pointer pitrivertribe.org.
>>>>>   230.169.10.69.in-addr.arpa domain name pointer shastawebmail.com.
>>>>>   230.169.10.69.in-addr.arpa domain name pointer vidalvineyard.com.
>>>>>
>>>>> Looks like a spammer to me :)
>>> Chris,
>>>
>>> Why not have a look at the websites for those domain.tld?
>>>
>>> All four seem to be quite legitimate.
>>
>> Good point :) I hadn't looked at the sites. They do look legit.
>>
>>> What they have in common (do a whois on the IP block holder), is use of
>>> the services of 'shasta.com' - who's website ALSO appears to be
>>> legitimate.
>>>
>>> Should your server be receiving this traffic?
>>
>> No:
>>
>> 2009-06-27 21:14:58 host name alias list truncated for 69.10.169.230
>> 2009-06-27 21:15:03 no IP address found for host dynamicessentialsinc.co
>>    (during SMTP connection from [69.10.169.230])
>> 2009-06-27 21:15:03 no IP address found for host
>>    palocedrocommunitypark.org (during SMTP connection from [69.10.169.230])
>> 2009-06-27 21:15:07 no IP address found for host mantonvin.com (during
>>    SMTP connection from [69.10.169.230])
>> 2009-06-27 21:15:14 H=youthgotohealth.org (localhost) [69.10.169.230]
>>    rejected EHLO or HELO localhost: Invalid HELO
>>
>> I don't like people who say HELO localhost. They go in my sin bin.
>
> One can be stricter on that score rather easily as the RFC at least 'expects'
> that a HELO match to a FQDN.
>
> OTOH, pooled mail servers of major ISP's so often are among major / careless
> violators that we've dropped to non-fatal 'demerits' points in stead of outright
> rejection.
>
> Passing reverse_host_lookup, OTOH, we are adamant about, so at least whatever
> arrives at HELO with flaws is more likely to be 'odd' rather than ouright
> missing. That said, 'localhost', our own ID, and obvious forgeries remain
> hard-fails.
>
>>
>>>> Although having multiple PTRs is a bad idea and generally doesn't work
>>>> as desired anyway, there are 'legitimate' mail hosts that have them.
>>> Correct. Hosting multiple mail domains is one of the few, and rare, but
>>> necessary, reasons for having mulitple <domain>.<tld> homes onto one/few
>>> IP. Low-budget e-commerce *can* be another.
>>
>> Why bother with PTRs in that case?
>>
>
> Multiple assignment in no way compromises the intent of a PTR RR.
>
> Taken one <domain>.<tld> at a time, the reverse lookup is just as valid a means
> of associating a <domain>.<tld> to a specific IP when there are 130+ (the most I
> have seen) as when there is only one.
>
> That is all a PTR RR is expected to do.
>
> Any further discrimination or 'steering' is the job of either other DNS records
> as MX, A, CNAME, may or may not be on the same box(es), or left to local
> server(s) and/or router(s).
>
>>> Spambots, OTOH, seldom have even ONE non-generic PTR RR that can pass.
>>
>> Yes, because that requires control of the reverse DNS, and zombies don't
>> control their reverse DNS. This case made me think that the site was a
>> full-on spamming operation.
>>
>
> It *could have* been. But not just because of multiple PTR RR assignment.
>
>>> Your ruleset (above) is more likely to slam bystanders - those using
>>> budget hosting services of ISP's who have few IP's and are trying to do
>>> the best they can with regard to DNS entries for their mail or online
>>> e-commerce services.
>>
>> Well, I've never seen a host with so many PTRs before in the 10 years that
>> I've known how to check, so I'm mighty suspicious, but OK.
>>
>
> Two or three are not uncommon. Think centralized mail for .com, .org, .net of
> the same <domain> different <tld> held by the same entity.
>
> I've seen over 130, wherein an ISP tried diligently to list every customer's
> <domain>.<tld>.
>
> Experience says that it is generally better to use a shared and innocuous 'none
> of the above' <domain>.<tld> to service outbound mail for all-hands when in a
> multi-entity environment.
>
> This primarily because the receiving server will more often list in a 'received'
> header the first <domain>.<tld> returned, not bother with parsing the list to
> grab a specific match to a HELO 'steered' with helo_data or other-than-Exim
> equivalent *even if* it has actually done so separately to 'vet' the incoming.
>
>>> Speaking of which - you have not told us if the message coming from that
>>> IP was in fact unwelcome.
>>
>> Never found out. HELO localhost -> bad boy.
>>
>> Cheers, Chris.
>
> Given the specific IP (above) I suspect it was more likely a fool than a
> charlatan, but there is a a saying about that distinction... so an infected
> machine is also a possibility, and 'fair enough'. let *them* fix that problem if
> htey want mail to flow.
>
> But that should not lead one into an extra ruleset that penalizes those using
> PTR RR in a quite 'legal', if less-common manner.
>

Last I checked into this issue, the RFCs do not explicitly allow or
disallow multiple PTRs.   This translated to inconsistent behavior in
the real world as some resolvers can understand them and some can't.
Unless things have changed, I don't think quite legal or less common
is really the correct term for this, more like good luck and say a
prayer.  But maybe something new has happened?

> That relationship is only coincidental.
>
> Best,
>
> Bill
>
> --
> ## List details at http://lists.exim.org/mailman/listinfo/exim-users
> ## Exim details at http://www.exim.org/
> ## Please use the Wiki with this list - http://wiki.exim.org/
>

--
## List details at http://lists.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

[Edgar Lovecraft]

On Sun, 28 Jun 2009 12:23:38 -0400 Aaron Wolfe <aawolfe@...> wrote:
>
..<snip snip>...
>
> Last I checked into this issue, the RFCs do not explicitly allow or
> disallow multiple PTRs.   This translated to inconsistent behavior in
> the real world as some resolvers can understand them and some can't.
> Unless things have changed, I don't think quite legal or less common is
> really the correct term for this, more like good luck and say a prayer.
> But maybe something new has happened?
>
>

Actualy, the RFCs are very clear that multiple PTR records are allowed for
single IP addresses.

Refernces:
RFC 2181 Section 10.2

RFC 1034 Section 5.2.1 sub-section 2
      "A type PTR query is used to get the RR with the primary name of
      the host.  For example, a request for the host name
      corresponding to IP address 1.2.3.4 looks for PTR RRs for
      domain name "4.3.2.1.IN-ADDR.ARPA"."

Please take note of the "looks for the PTR RRs", 'resouce records', not
just 'resource record'.


..<snip snip>...
>


--

--EAL--

--



--
## List details at http://lists.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

[Aaron Wolfe]

On Sun, Jun 28, 2009 at 8:15 PM, Edgar Lovecraft<exim-list@...> wrote:

> On Sun, 28 Jun 2009 12:23:38 -0400 Aaron Wolfe <aawolfe@...> wrote:
>>
> ..<snip snip>...
>>
>> Last I checked into this issue, the RFCs do not explicitly allow or
>> disallow multiple PTRs.   This translated to inconsistent behavior in
>> the real world as some resolvers can understand them and some can't.
>> Unless things have changed, I don't think quite legal or less common is
>> really the correct term for this, more like good luck and say a prayer.
>> But maybe something new has happened?
>>
>>
>
> Actualy, the RFCs are very clear that multiple PTR records are allowed for
> single IP addresses.
>
> Refernces:
> RFC 2181 Section 10.2
>
> RFC 1034 Section 5.2.1 sub-section 2
>      "A type PTR query is used to get the RR with the primary name of
>      the host.  For example, a request for the host name
>      corresponding to IP address 1.2.3.4 looks for PTR RRs for
>      domain name "4.3.2.1.IN-ADDR.ARPA"."
>
> Please take note of the "looks for the PTR RRs", 'resouce records', not
> just 'resource record'.
>

Yes, I remember this and this is the part that isnt clear, isn't it?
Not trying to restart any kind of debate, but doesn't this reference
also mention "the RR" with "the primary name", both singular?  English
can be unclear.  Consider the phrase, "I'm driving down the street
looking for houses with the address 123", which maybe isn't a great
example but hey i'm not a cunning linguist.

Regardless, the important thing, and what I was interested in most was
whether the behavior was now more consistent.   This is what matters
if you're going to use them.  Can we trust that multiple PTRs will
mostly work on most platforms now?  As in the resolvers will return
multiple results, and most software will sift through many results
instead of just taking the first one? This did not seem to be the case
a couple years ago.

-Aaron

>
> ..<snip snip>...
>>
>
>
> --
>
> --EAL--
>
> --
>
>
>
> --
> ## List details at http://lists.exim.org/mailman/listinfo/exim-users
> ## Exim details at http://www.exim.org/
> ## Please use the Wiki with this list - http://wiki.exim.org/
>

--
## List details at http://lists.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

[W B Hacker]

Aaron Wolfe wrote:

> On Sun, Jun 28, 2009 at 8:15 PM, Edgar Lovecraft<exim-list@...> wrote:
>> On Sun, 28 Jun 2009 12:23:38 -0400 Aaron Wolfe <aawolfe@...> wrote:
>> ..<snip snip>...
>>> Last I checked into this issue, the RFCs do not explicitly allow or
>>> disallow multiple PTRs.   This translated to inconsistent behavior in
>>> the real world as some resolvers can understand them and some can't.
>>> Unless things have changed, I don't think quite legal or less common is
>>> really the correct term for this, more like good luck and say a prayer.
>>> But maybe something new has happened?
>>>
>>>
>> Actualy, the RFCs are very clear that multiple PTR records are allowed for
>> single IP addresses.
>>
>> Refernces:
>> RFC 2181 Section 10.2
>>
>> RFC 1034 Section 5.2.1 sub-section 2
>>      "A type PTR query is used to get the RR with the primary name of
>>      the host.  For example, a request for the host name
>>      corresponding to IP address 1.2.3.4 looks for PTR RRs for
>>      domain name "4.3.2.1.IN-ADDR.ARPA"."
>>
>> Please take note of the "looks for the PTR RRs", 'resouce records', not
>> just 'resource record'.
>>
>
> Yes, I remember this and this is the part that isnt clear, isn't it?
> Not trying to restart any kind of debate, but doesn't this reference
> also mention "the RR" with "the primary name", both singular?  English
> can be unclear.  Consider the phrase, "I'm driving down the street
> looking for houses with the address 123", which maybe isn't a great
> example but hey i'm not a cunning linguist.
>
> Regardless, the important thing, and what I was interested in most was
> whether the behavior was now more consistent.   This is what matters
> if you're going to use them.  Can we trust that multiple PTRs will
> mostly work on most platforms now?  As in the resolvers will return
> multiple results, and most software will sift through many results
> instead of just taking the first one? This did not seem to be the case
> a couple years ago.
>
> -Aaron
>
>
>> ..<snip snip>...
>>
>> --
>>
>> --EAL--
>>
>> --
>>

Agree it *was not* the [general] case until fairly recently, where '..recently'
seesm to be about 2 or 3 years.

Though Exim has had the code to build lists etc for far, far, longer, a simple
'host [IP number]' on one I run with 3 domain.tld pointed to used to return a
different one - but only - one - at each go. For about two years now it has
returned all three.

What has changed? Well - first off, I'm at FreeBSD 6.X or 7.X, no longer at
4.11, so the 'host' utility code is probably different. Secondly, my upstream.
where the records are stored, has at least twice upgraded their DNS software,
though I know not from what or to what.

Pure speculation here, but one of the drivers MAY have been hangover from the
dot-com 'bust'.

Going into it, it was a clear bet that 'the world' would soon exhaust IPV4
address space - yet IPV6 which would (among other things) once again provide
plentiful IP addresses was nowhere near gaining universal acceptance, and still
is not.

Further - plentiful or not, larger IP blocks were not going to be 'free' at the
end-point of distribution - ISP/Co-Loc or other IP-block holder who want at
least admin fees for putting them into their all-important router tables even if
one has registered for a block of their own.

Result?

Globally, folks seem to have paid attention to more flexible NAT, routing, and
DNS improvements to make better use of such IPV4 address space as was already
in-hand. 'belt tightening' so to speak.

As said - speculative.

But the reality IS largely in-place, and not just within Exim.

We have yet to be rejected on PTR RR or HELO mismatch. Though - to be fair,
while favorite filtering tools of *ours*, many others would seem to pefer to
take onboard all-comers, even from dynamic-IP blocks, then concentrate on
content scanning.

Conversely, we've been running w/o SA or such *at all* on a test server, (still
have ClamAV) and may soon be able to drop SA (hence perl) entirely.

Not that it isn't useful or accurate - but because the remaining traffic it
blocks has become vanishingly small and the absence would mean going from one
sequestered spam per user per every third day to two or three a day, worst-case
- either number being well within the tolerance range of the Mark One eyeball.

Differences in user-community can be as great as any other factor, so 'YMMV'

Bill



--
## List details at http://lists.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/