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
