[Maybe OT] - RFC compliance checking at session

[Glenn Steen]

On 29/02/2008, mikea <mikea at mikea.ath.cx> wrote:
> 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.
>
Not disagreeing (much, here either:-), but the only policy decision I
see is whether you decide to enforce 1123 and 2821 or not.
They are rather clear on this... formal error... and (unfortunately)
also clear that you cannot use a reverse lookup for rejections,
although you are free to do one.

Cheers
-- 
-- Glenn
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se