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/
>
