On Sat, Apr 02, 2005 at 09:41:41PM -0600, Les Mikesell wrote:
> On Sat, 2005-04-02 at 21:14, Gavin Carr wrote:
> > On Sat, Apr 02, 2005 at 03:54:37PM -0600, Les Mikesell wrote:
> > > > Anyway, the point of checking that a system that's trying to deliver
> > > > email to you has a name that resolves to the address it's using, that
> > > > that address resolves back to the name, and that the HELO specifies
> > > > the correct name as well, is that most privately owned Windows PCs
> > > > don't fulfill those requirements.
> > >
> > > There is no requirement for the HELO to match anything else. It must
> > > be syntactically correct but it does not have to have anything to do
> > > with the particular interface you happen to be using. On the other
> > > hand the From: address does have to be resolvable - otherwise you
> > > wouldn't be able to reply anyway.
> >
> > Wrong. RFC2821 says:
> >
> > 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 SHOULD is not a requirement. A MUST would be a requirement. Even
> if it did mention a requirement, there is nothing that says a
> host with multiple addresses should use the name matching the
> connected interface each time. There is certainly nothing there
> to override the earlier RFC (which I've forgotten) that specifies
> a similar recommendation but goes on to say that the receiver
> MUST NOT reject the message based on an address lookup mismatch
> for the HELO/EHLO name (obviously written by someone who realized
> that multi-homed servers are common and that corporate servers
> often live behind NAT firewalls and don't even know the address
> that will be used the public side).
I agree with your specific point that using a HELO domain that does
not match your ip address (if a literal) or your reverse mapping
record does not mean you are in violation of the RFCs. And therefore,
denying mail on that basis is bad.
But your initial:
> > > There is no requirement for the HELO to match anything else.
is too strong. There *is* a general requirement (the SHOULD) that
the HELO domain belongs to the client. Syntactic goodness is not
sufficient.
I reject all mail where the sender HELO's with any of my ip address
literals, for instance, which I do consider a violation of the RFCs,
and removes a surprisingly large chunk of spam.
Cheers,
Gavin
