7. BCP - Mail Administrators: Checking HELO (was: [Asrg] 0. General - Ad

[changing the subject]

On 2003-08-28 23:59:29 +0200, Brad Knowles wrote:
> At 5:04 PM +0200 2003/08/28, Peter J. Holzer wrote:
>
> > Still, I don't think there are many legitimate sites which don't have an
> > A record.  Requiring the sender to send a FQDN which resolves to the
> > sender's IP address doesn't seem unreasonable to me (even for dynamic
> > IP-Addresses, you can use dyndns.net or a similar service).
>       Check the recent traffic on NANOG.  Because of stupidity on the 
> part of AOL, they've been discussing this subject intensively.  I've 
> been tagging 75-90% of the recent messages as input for the BCP 
> review.
I think you mean the thread "Fun new policy at AOL" starting at
http://www.cctec.com/maillists/nanog/current/threads.html#05061

This is something different. The thread started because AOL blocks
"residential" addresses, which is essentially the same as a DUL. 

It was also mentioned in the thread that AOL blocks connections from IPs
without rDNS. (see http://postmaster.info.aol.com/standards.html for
AOL's policy).

AFAICS, checking the argument to HELO wasn't even mentioned in the
thread.

I'll try to summarize how HELO can be checked and the implications of
various methods.

1) Formal correctness. 

    RFC 2821 specifies that the parameter must be an FQDN or an address
    literal. So you can check against regexps or a grammar.

    This will disallow unqualified host names and random garbage. 
    Unqualified host names are often (legitimately) used by broken MUAs. 
    I think I have also seen it from misconfigured Exchange servers. 
    Some viruses/worms (Sobig) and some spammer software also uses unqualified
    host names - this would be blocked.

2) Check whether the parameter corresponds to the sender IP address.
    I.e., if the parameter is an FQDN, look up its A record(s) and
    compare to the sender IP, if it is an address literal, compare it to
    the sender IP.

    This would in addition catch all the software which lies about its
    own address. Examples are again MUAs (at least some use either the
    server address or the domain name of the sender) and lots of spammer
    software which sends "HELO yahoo.com" or similar.

3) Require the parameter to be an FQDN and check whether its A record
   matches the sender IP.

    This will additionally block all senders which don't have an FQDN or
    don't know it (which currently seems to be true for a lot of open
    proxies, but may change quickly). 

4) Require the parameter to be an FQDN and check whether the PTR record
   of the sender IP matches the parameter.

    This will block all addresses for which rDNS isn't available, and
    those for which rDNS gives a different name than the "canonical"
    name of the host. This includes lots of cable/dsl customers.


RFC 2821 allows checking the HELO parameter only for logging and tracing
purposes. I think that the decision which mails to accept and which to
reject must be made by the administrator of each system (who is
responsible to his employer and/or his customers) not by some RFC. 

I also think that rejecting mail because it fails a single test (like no
rDNS record or being listed in a single BL) is not good practice (I am
still guilty of that, because that's how sendmail handles BLs, but I am
trying to move to more robust schemes without a single point of
failure).

That said, I think that checking the HELO parameter gives valuable
results for a mail relay which recieves mail only from other servers
(MUAs are way too broken in that regard and probably won't be fixed).

I see very little legitimate mail in my log files which doesn't pass
tests 1) to 3). For the few cases which would break on 3), I would
consider it reasonable for the administrator on any legitimate server to
get an FQDN and a matching A record. This is even possible for dynamic
IP addresses via dyndns.net and similar services. 

Test 4 OTOH cannot be passed by many people with "residential" or
"consumer" cable, dsl or dial-up lines, since providers often don't
provide rDNS mapping, or inconsistent mapping (forward and reverse
lookup don't match), and in any case the "canonical" name of the
computer isn't the unwieldy automatically generated name in the rDNS
record (e.g., my laptop (chthon.hjp.at) has IP address 62.99.236.100
when I'm at home, but the PTR for that address points to
62-99-236-100.C-VTreustrasse.Xdsl-line.inode.at.)

(and BTW, last time I looked the ASRG mailing list server wouldn't have
passed test 4 either)

So for a BCP document I would recommend:

1) Combine different tests (for example by summing scores like
   SpamAssassin does) and reject only if some threshold is exceeded.

2) Of the 4 tests I outlined, give the first 3 a high score, and the
   fourth a low to medium score.


> > looking at my log files this seems to be a very good indicator of
> > legitimate mail servers (I checked several weeks of logs some time ago
> > and only found one legimitate server which identified itself with an
> > unresolvable name (I think the box is NATted).
>       I'm NAT'ed.  Many people on NANOG appear to be in similar 
> situations, or have run into them frequently.
At least in the case I cited the admin knows the address of the gateway
and could easily arrange for his server to send a HELO parameter
resolving to the NATed address. He probably would if I started to block
his mail, but as long as it doesn't matter, why should he fix his
configuration?

Maybe I am overlooking something, but I cannot think of any situation
where tests 1-3 cannot be met, even for NAT and dynamic IPs.

Test 4 is different, because it requires collaboration of your ISP.
"Get a clueful ISP" is not always an option.

        hp

-- 
   _  | Peter J. Holzer    | Humor ohne Emoticons ist trockener Humor.
|_|_) | Sysadmin WSR       | 
| |   | hjp(_at_)hjp(_dot_)at         | -- Toni Grass in aip
__/   | http://www.hjp.at/ |

pgpNr9TIOj0tb.pgp
Description: PGP signature