>...
>
>List Mail User wrote:
>>
>> Certainly not (no dunce cap). Public airing of ideas generally
>> has merit - quite possibly this idea can be refined to something similar
>> that will provide a benefit (I admit, I have not given it a lot of thought).
>>
>
>one thing that an MTA can do is to delay its rDNS lookup until it gets
>the helo name. then do a forward lookup on the helo name.
>if one of the returned IPs matches the client IP, there will be no need
>for the classical double lookup.
>
>if one assumes that most helo names are correct, then this would be a
>minor improvement. and the benefit is that it automatically checks for
>helo validity (I don't mean one would reject the helo, but he knows if
>it's good or not).
>
>(I think iMail does something like this, but I can't say for sure).
>
A quick check of my own stats shows (after client IP blocking), that
about 35% of HELO/EHLO arguments are bogus - i.e. don't resolve or belong
to a domain unrelated to the client or sender IP. As a result, I have things
configured to always do the double lookup, but only log a message when they
don't match (i.e. not "strict" FCrDNS); Still > 25% of all EHLO/HELO arguments
have no rDNS or aren't FQDNs; Some of this is list-washing - For a year ago,
the numbers were almost double these (much worse). And the number or client
IPs lacking rDNS is > 40% (again, after blocking on client IPs - presumably
for people who don't block at the MTA level on client IPs, the numbers are
much worse). Of course, there is a very large overlap between requests with
invalid or bad HELO/EHLO names and invalid rDNS for the client IP (i.e. liars
lie about everything usually, at least for SMTP transactions).
Paul Shupak
[EMAIL PROTECTED]
