Re: HELO/EHLO and applicability statement

Richard Rognlie <[email protected]> Tue, 7 Oct 2003 08:50:19 -0400
Newsgroups gmane.ietf.asrg.rmx
Message-ID <[email protected]>
On Tue, Oct 07, 2003 at 12:26:00AM -0400, Yakov Shafranovich wrote:
> Raymond S Brand wrote:
> >
> >> The hope that people will use FQDN's is contentious, of course.  To
> >
> >
> >Most of the legitimate SMTP connections I see have had FQDNs in the EHLO
> >command.
> >
> 
> Do you mean to imply that IP addresses will not be allowed in the HELO 
> command? Is there a conflict with between saying this and RFC 821/2821, 
> in particular section 4.3.1:
> 
> -----------snip--------------
>    Sometimes a host is not known to the domain name system and
>    communication (and, in particular, communication to report and repair
>    the error) is blocked.  To bypass this barrier a special literal form
>    of the address is allowed as an alternative to a domain name.  For
>    IPv4 addresses, this form uses four small decimal integers separated
>    by dots and enclosed by brackets such as [123.255.37.2], which
>    indicates an (IPv4) Internet Address in sequence-of-octets form.  For
>    IPv6 and other forms of addressing that might eventually be
>    standardized, the form consists of a standardized "tag" that
>    identifies the address syntax, a colon, and the address itself, in a
>    format specified as part of the IPv6 standards [17].
> -----------snip--------------

IP addresses *ARE* allowed in RFCs 821 and 2821.  And DRIP can
do nothing to prevent their use.  However, an IP address (whether
IPv4 or IPv6) as the HELO argument is also unverifiable.  As such,
DRIP will eventually "recommend" that the offering host not be 
"trusted".

Whether that results in a rejected connection during the SMTP session
or deferred and factored in as a spamassassin-ish score value is left
as an exercise for the reader...

The current DRIP milter treats an offered IP address that does not
match the IP address from whence the connection is arriving as grounds
for rejecting any mail from the sender.  (Yes, Brad... I know this is
a technical violation of the RFCs, but we've had this discussion)

If the IPs match, it treats the connection as "unknown".  Just like
any other domain that does not have DRIP records implemented for it.

What I *hope* for is a recommendation that if a machine has no defined
name, it SHOULD NOT connect to the "public" internet.  It should connect
to some other machine which IS well defined to the internet at large.
That other machine would have to have some TRUST relationship with the
sending server.  An example of this is my NAT network at home.  Any 
mail my wife/children send (as well as alerts the NAT box itself generates)
are sent to my border MTA.  It knows that the IP of the NAT is
excluded from DRIP checking.

-- 
 /  \__  | Richard Rognlie / Oracle Prophet / Gamerz.NET Lackey
 \__/  \ | http://www.gamerz.net/rrognlie/    <[email protected]>
 /  \__/ | It is dangerous to be right, when the government is wrong.
 \__/    |                                              -- Voltaire