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