[Maybe OT] - RFC compliance checking at session

[mikea]

On Fri, Feb 29, 2008 at 02:48:50PM -0600, Richard Frovarp wrote:
> Rick Cooper wrote:

> >    We use Exim for both inbound and outbound message handling around
> >    MailScanner, and on the inbound, some quite complex ACL’s to
> >    validate the session to try and cut down the amount of spam our
> >    users get. The first check we run is to ensure that the HELO/EHLO
> >    is an FQDN. We don’t then validate if this FQDN can be resolved,
> >    or even if it is valid, it just has to be host.domain.tld, and
> >    this significantly cuts the number of RBL lookups we do. This
> >    hasn’t caused us any problems with rejecting valid mail until now.
> >
> >    One of our users complained that they were no longer receiving a
> >    newsletter they signed up for. I managed to find it in the exim
> >    reject logs, and sure enough, it was failing the host checking –
> >    the EHLO it sends is “(server3549)”, and exim declines the session
> >    with a 550 – permanent reject for policy reasons.
> >
> >    Now comes the fun part. That 550 is not enough for the sender – it
> >    ignores it and constantly retries the send, treating it more like
> >    a 450, but not following any normal MTA retry period I can
> >    establish. That would be enough for me to leave them blocked, but
> >    checking further, the IP for that host has no RDNS, also a big
> >    no-no in my opinion for a valid mail server, and the IP does not
> >    accept return SMTP – indicating that it’s probably a web server
> >    and not an MTA itself. I even took the liberty of doing an
> >    IPWhois, phoning the helpdesk of the company responsible for the
> >    IP (only because they are UK based the same as us) and pointing
> >    the problem out, only to be met with “yeah, we know about that,
> >    it’ll be fixed sometime next year when we put a new server in”,
> >    even after I pointed out that they wouldn’t be getting successful
> >    deliveries to organisations such as AOL (RDNS is a must) and
> >    BT/Yahoo (whose policies are incredibly strict)!
> >
> >    </rant>
> >
> >    So what do you guys think? Am I just being particularly awkward on
> >    a Friday afternoon and should I spend my time re-working our
> >    config to work around an organisation who is blatantly ignorant of
> >    common mail server practise, or just tell my user that the sending
> >    organisation needs to get their act together?
> >    [Rick Cooper]
> >
> >    I also enforce a proper helo name. I just went through this with a
> >    rather large insurance company that switched mail servers and the
> >    new server was incorrectlu configured so it helo'd with something
> >    like boogabooga.internal (I don't remember the host name part).
> >    The smart ass mail admin said "what if that host doesn't have a
> >    FQDN" and I replied dotted quad in square brackets according to
> >    the RFCs... bud.
> >
> >    I come across this now and then and I always try and contact the
> >    sender's responsible party to clear it up, it wrong, it breaks
> >    SPF, it breaks RFCs and it's VERY common to see unqualified names
> >    coming from BOTS, virus and spam. I bet if you look though your
> >    logs you will see most hosts that helo with a non FQDN or
> >    .internal/.local/.localdomain are mostly dynamic DSL or cable
> >    hosts. I dump a ton of them everyday.
> >
> >    I also run Exim and I have a !hosts =
> >    /ListOfDickHeadsIHaveToAccept before each compliance check
> >    condition. For instance a Zurich subsidiary that helo'd as
> >    something_stupid.local, no RDNS, they did about everything but
> >    spit on the RFCs and we had to have thier mail. I put them in the
> >    list, inform the maintainers and remove them after 90 days and see
> >    what happens. The file can be just a flat text file in the format of
> >
> >    10.10.10.10 # Remove in April
> >
> >    10.10.10.1 # Remove In May
> >
> >    They do not, of course, get a pass around virus, attachment, etc
> >    checking, just compliance checks.

> I thought that rejecting on helo alone was against the RFCs.

It's my understanding that rejecting *because the hostname in the HELO
can't be resolved* is in some senses contrary to the RFCs. Rejecting
because the hostname in the HELO is totally bogus (not an FQDN, for
example, or otherwise not compliant with RFC 2821) comes under policy
decisions, which the server operator is free to make as he or she sees
fit.

>From RFC 2821: 

: 2.3.5 Domain
: 
:    A domain (or domain name) consists of one or more dot-separated
:    components.  These components ("labels" in DNS terminology [22]) are
:    restricted for SMTP purposes to consist of a sequence of letters,
:    digits, and hyphens drawn from the ASCII character set [1].  Domain
:    names are used as names of hosts and of other entities in the domain
:    name hierarchy.  For example, a domain may refer to an alias (label
:    of a CNAME RR) or the label of Mail eXchanger records to be used to
:    deliver mail instead of representing a host name.  See [22] and
:    section 5 of this specification.
: 
:    The domain name, as described in this document and in [22], is the
:    entire, fully-qualified name (often referred to as an "FQDN").  A
:    domain name that is not in FQDN form is no more than a local alias.
:    Local aliases MUST NOT appear in any SMTP transaction.
: 
: and 
: 
: 3.6 Domains
: 
:    Only resolvable, fully-qualified, domain names (FQDNs) are permitted
:    when domain names are used in SMTP.  In other words, names that can
:    be resolved to MX RRs or A RRs (as discussed in section 5) are
:    permitted, as are CNAME RRs whose targets can be resolved, in turn,
:    to MX or A RRs.  Local nicknames or unqualified names MUST NOT be
:    used.  There are two exceptions to the rule requiring FQDNs:
: 
:    -  The domain name given in the EHLO command MUST BE either a primary
:       host name (a domain name that resolves to an A RR) or, if the host
:       has no name, an address literal as described in section 4.1.1.1.
: 
:    -  The reserved mailbox name "postmaster" may be used in a RCPT
:       command without domain qualification (see section 4.1.1.3) and
:       MUST be accepted if so used.
: 
: and 
: 
: 4.1.1.1  Extended HELLO (EHLO) or HELLO (HELO)
: 
:    These commands are used to identify the SMTP client to the SMTP
:    server.  The argument field contains the fully-qualified domain name
:    of the SMTP client if one is available.  In situations in which the
:    SMTP client system does not have a meaningful domain name (e.g., when
:    its address is dynamically allocated and no reverse mapping record is
:    available), the client SHOULD send an address literal (see section
:    4.1.3), optionally followed by information that will help to identify
:    the client system.  The SMTP server identifies itself to the SMTP
:    client in the connection greeting reply and in the response to this
:    command.
: 
:    A client SMTP SHOULD start an SMTP session by issuing the EHLO
:    command.  If the SMTP server supports the SMTP service extensions it
:    will give a successful response, a failure response, or an error
:    response.  If the SMTP server, in violation of this specification,
:    does not support any SMTP service extensions it will generate an
:    error response.  Older client SMTP systems MAY, as discussed above,
:    use HELO (as specified in RFC 821) instead of EHLO, and servers MUST
:    support the HELO command and reply properly to it.  In any event, a
:    client MUST issue HELO or EHLO before starting a mail transaction.
: 
:    These commands, and a "250 OK" reply to one of them, confirm that
:    both the SMTP client and the SMTP server are in the initial state,
:    that is, there is no transaction in progress and all state tables and
:    buffers are cleared.
: 
:    Syntax:
: 
:       ehlo            = "EHLO" SP Domain CRLF
:       helo            = "HELO" SP Domain CRLF

"Local aliases MUST NOT appear in any SMTP transaction" is pretty 
definitive. This means that "HELO joe-computer", "EHLO ditlq", and 
"HELO Wireless_Broadband_Router", all of which just flew through my 
maillog at high speed, fail to comply with RFC 2821. 

Similarly, "HELO 123.234.134.124", with bare numbers and dots
not enclsed by "[" and "]", is not compliant with RFC 2821,
because 123.234.134.124 is not an address literal and there
are no Top-Level-Domains (TLDs) which are all-numeric. "HELO
[123.234.134.124]" would be compliant.

I get to make a policy decision that non-compliant HELO/EHLO values   
and certain other RFC violations will get that SMTP transaction       
REJECTed, and I do: HELO/EHLO with no dots in the HELO domain value
will get your mail rejected, and HELO/EHLO with a domain value that 
is all (numbers and dots) will get your mail rejected. 

It keeps a _lot_ of spam out. Occasionally some vendor's IT staff will 
forget to set a mailer up with a valid FQDN, we'll reject the mail, 
they'll call me or write me (out of band) to ask why. So far the 
result has uniformly been an embarrased "Oh. Forgot about that. Oops!"
followed by a note checking if it's set up correctly now. 

Mind you, I have pretty free rein here, and since we're a government 
agency, we can be pretty stiff about what we'll accept. Your Mileage
May Vary. 

-- 
Mike Andrews, W5EGO
mikea at mikea.ath.cx
Tired old sysadmin