[CentOS] Re: postfix tightening

[Gavin Carr]

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