[Top] [All Lists]

Re: [ietf-smtp] Private Domain Names and the EHLO/HELO Command

2013-03-27 09:01:09
On 27 Mar 2013, at 10:44, Tony Finch wrote:
Sabahattin Gucukoglu <listsebby(_at_)me(_dot_)com> wrote:
Once again I am faced with the question of what to do (as a "Dumb" SMTP client) when my outgoing interface has a private IP address and the name is
locally administered.

I saw your question on twitter, but 140 characters wasn't enough for an

No. :-)

There are about three cases to consider:

(1) This is excluded since you are asking about a dumb client, but for
mail across the public internet to an MX, the sender should be configured
to put a proper host name in its EHLO command.

Agree 100%. I can't think of a single MTA that is still unable to have this configured as a critical option. Exchange included.

(2) Client talking to an internal relay / smarthost.

(3) Message submission.

In the latter cases, and especially (3), pretty much anything is OK, since
the server has a relatively close relationship with the client. So the
client should just try to send something syntactically valid and not worry too much about NAT making the client's view of the network appear nonsense
to the server.

Mmm, yeah. I would hope that the submission or downstream hub would not be too picky about the names given. Hopefully IPv6 makes at least the address literal form more useful (and less obviously wrong). Of course if the client has the option to configure the EHLO string, then have it send a name that represents the external-facing interface of the NAT box(es) as discussed here previously. We can't discover this ourselves without consulting an external server.

For example, while a EHLO domain ending in .lan or .home is an almost
certain indication that the client is a spam bot in case (1), it's
OK and quite normal for (3).

Agreed. I think it is more that the current spec simply doesn't make it clear that such fallout occurs in normal use. Quite a few clients now simply send out private addresses without checking first whether they are canonical or meaningful. I can see why this happens. (Incidentally the same sort of thing sometimes happens with Message-Id fields appearing in some mail and news headers, even though this is completely useless against collisions.)

If you are a client author, you need to be careful about host names
since they can contain surprising kinds of garbage.

This is partly what inspired this question. :-)

So in summary:

1. Perform the usual reverse-forward-FQDN-search routine to find our "FQDN".

2.  If it's safe to send according to hostname rules, then send it, or

3.  Send our private IP address as an address literal.

This should, I think, avoid the maximum number of pitfalls. It also happens to be a popular option among existing clients, and be forward-compatible with IPv6 with registered domain names. :-)

ietf-smtp mailing list