--On Tuesday, January 27, 2009 11:37 AM +0000 Paul Smith
<paul(_at_)pscs(_dot_)co(_dot_)uk> wrote:
The only 'correct' ways I can come up with are to use the
internal IP address literal, or (if the SBS owner is a techie)
to have something like 'company.dyndns.org'. The first of
these is totally useless to anything else, and the second is
arguably less useful than the technically incorrect
'company.com' or 'mail.company.com' (because there is no DNS
record pointing those names back at the dynamic IP address)
One could also put in a record that looks like
mail.company.com. IN CNAME company.dyndns.org.
But, while it gives more information than the Dyndns address, an
EHLO argument using the "mail.company.com" address isn't
5321-valid because that is not the primary host name.
I don't remember the details of the discussion that led to the
prohibition on rejection in RFC 1123, but the issues more
generally are very much like the ones the Paul raises (and that
I tried, less successfully, to identify in an earlier note).
The historical goal of EHLO is to provide the maximum amount of
information possible to help the server identifying the client
host and its administration. Simply delivering the public IP
address of that host is actually fairly useless from an added
information point of view -- the server already knows that --
and, from that point of view, the permission in RFC 2821 to use
an IP address literal doesn't add much. That "as much
information as possible" principle was also, I think, what
motivated DRUMS to permit, in 2821, a host-identifying comment
after the EHLO domain. We took that back out of 5321 because
it was not widely implemented and causes problems, but the
principle was probably still right.
In that context, this discussion is ultimately about a tradeoff
between "get the Good Guys to provide maximum information" and
"see if we can use the EHLO argument to trap the Bad Guys". The
decision to favor the first was made with RFC 1123 twenty years
ago and even that was arguably just a clarification to the
intent of RFC 821. Tempting as it might be from some
perspectives, trying to change the semantics of that argument to
help in spam-rejection just isn't going to work, at least IMO.
There is too large an installed base of clients designed around
"supply maximum useful information" and one doesn't want to
discourage the Good Guys from supplying useful information (even
if it is a valid IP address in private space). In addition,
even if one could insist on a domain name that "matches" the
public IP address and deploy servers widely that enforced that
provision, one would only temporarily inconvenience the spammer
and then, in the words of Paul Vixie and others, make them
smarter. It really isn't all that hard to figure out the public
IP address associated with the private one that one is using (at
least if there is only one level of NAT involved). It is
certainly not hard to take that public address and reverse-map
it to obtain a domain name and, if there is no reverse-mapping,
not much harder to use a temporary domain and dynamic dns to
make a name that will pass any test made at SMTP connect time.
It might take the spammers a while to deploy software,
especially bot software, that would do those things, but, once
they did, one would have another nearly-useless anti-spam tool
and a dramatically weakened debugging environment for more
legitimate and desired messages.
Using this as a back door to get rid of SMTP clients that send
mail from private address space directly into public Internet
address space is a different problem. It just isn't the way to
do that, independent of how desirable one might believe it to
be. Even its desirability is in doubt give IPv4 address space
shortages and the belief that we will be seeing ever more of
those addresses in the coming years. If you want to pursue that
option, please get the RIRs and the various network operations
groups to sign off on it first.
I think I've now said about as much as I usefully can on this
topic.
john