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
answer...
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.
http://fanf.livejournal.com/124413.html
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. :-)
Cheers,
Sabahattin
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp