[Maybe OT] - RFC compliance checking at session
glenn.steen at gmail.com
Fri Feb 29 21:54:00 GMT 2008
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
> >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 ) are
> : restricted for SMTP purposes to consist of a sequence of letters,
> : digits, and hyphens drawn from the ASCII character set . 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  and
> : section 5 of this specification.
> : The domain name, as described in this document and in , 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 18.104.22.168.
> : - The reserved mailbox name "postmaster" may be used in a RCPT
> : command without domain qualification (see section 22.214.171.124) and
> : MUST be accepted if so used.
> : and
> : 126.96.36.199 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 188.8.131.52", with bare numbers and dots
> not enclsed by "[" and "]", is not compliant with RFC 2821,
> because 184.108.40.206 is not an address literal and there
> are no Top-Level-Domains (TLDs) which are all-numeric. "HELO
> [220.127.116.11]" 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.
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se
More information about the MailScanner