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

On 2003-08-30 17:38:50 +0200, Brad Knowles wrote:
> At 5:34 PM +0200 2003/08/29, Peter J. Holzer wrote:
>
> > 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.
>       Many hosts in the world are configured (misconfigured?) to have 
> unqualified hostnames.  Some sites even have an explicit policy that 
> all hostnames will be unqualified.
The name sent in the HELO parameter is not necessarily the same as the
one returned by the "hostname" command (or equivalent). A mail server
may have a hostname of "rumpelstilzchen" and still identify itself as
"mail-out.example.com" in the HELO command.

RFC 2821 requires the parameter to be either an FQDN or an address
literal. A client which sends an unqualified hostname is in violation of
the RFC without any good reason. (broken software and lazy
administrators are not good reasons, IMHO)

(Please note that I'm talking about servers sending to other servers
over the internet. User agents talking to their servers or one
department's server talking to another within a corporation's intranet
are out if scope of this group IMHO).


> > 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.
>       I have over a dozen different e-mail addresses that I use.  Only 
> one of them might potentially correspond to the server that I use 
> over an ssh tunnel as my outbound mail relay.
I wasn't talking about mail addresses, but about IP adresses.


>       If I were to host my own outbound mail relay here in the house, 
> because I am behind a NAT you might see my server identify itself as 
> 10.0.1.5, when the real external IP address is something completely 
> different.
Any reason why it must identify itself as [10.0.1.5]? Why not with the
external IP address or as bradknowles.dyndns.net? 

> > 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).
>       This would require a change to RFC 2821. 
That would be nice, but it's not required. We are working on a BCP for
mail administrators here, not on a technical specification for the SMTP
protocol. 

So we can recommend that a sending MTA SHOULD always send an FQDN which
resolves to its IP address, because a server MAY interprete a failure to
do so as an indication that the sender is not a properly configured MTA
and reject mails while RFC 2821 can still allow address literals for
situations where they are appropriate.


> Moreover, it would 
> break anyone who has an IP address assigned to them (maybe in PI 
> space), but does not necessarily have an FQDN.  See above items 1 & 2.
You can get an FQDN for free in a few minutes. If want to run a properly
configured mail server that is the least of you worries.

(Of course this is also true for spammers - they might adapt quickly if
people start to check helo parameters)

> > 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.
>       And lots of customers or service providers that run their own 
> mail servers on valid public IP space, but who don't properly 
> understand the concept of reverse DNS or how to implement it properly.
One could argue that if they don't understand DNS, they shouldn't run a
mail server. In fact that was the reasoning behind the rDNS checks in
Klaus Assmann's anti-spam hacks for sendmail: If they can't even get DNS
right, how can you expect them to close an open relay (which wasn't easy
at that time)?

I specifically mentioned cable/dsl customers because lack of
understanding isn't their problem. They cannot set up rDNS themselves
because they don't own their namespace in in-addr.arpa. and can't buy it
(unlike a domain name). Changing to a provider which does offer a fixed
IP address and rDNS entries or even delegation for sub-/24 nets (as in
RFC 2317 or similar) is often not possible (there may not be one in your
area, or it may be prohitively expensive).


> > 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.
>       Agreed.
>
> > 2) Of the 4 tests I outlined, give the first 3 a high score, and the
> >    fourth a low to medium score.
>       The benefits and drawbacks of each specific criteria should be 
> discussed, with recommendations for higher or lower score values, 
> based on expected probability of occurrence and probabilities and 
> costs of false positive and false negative matches.
Agreed. My (entirely subjective) recommendation was based on the log
files of my private server and from looking at Received headers of many
spam- and non-spam messages (usually for other reasons). I don't have
hard figures at this time, only a gut feeling. I plan to switch to
qpsmtpd at the WSR next week, which will write the complete SMTP
conversation (except the contents of the mail, of course) to a log file,
so I will have a bit better statistics in a few weeks. (still only for
about 150 users or so - the results of a large ISP would be
interesting).

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

pgpRGkAlZSDBW.pgp
Description: PGP signature