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

On 3/26/2013 12:17 PM, Sabahattin Gucukoglu wrote:
> Hi,
>
> 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 checked RFC 5321 and can't get a 
> *definitive* answer concerning whether or not a name like 
> "Computer-Name.local" or "something.lan" is actually fully-qualified 
> or not; certainly it is not *publicly* resolvable, but it is 
> resolvable within the environment.  My feeling is that it does not 
> meet the definition of an FQDN.  I cannot determine my name with only 
> a private address, and my name is likely to be meaningless if I 
> resolve it.

Thats correct.

> So, what should I do when sending the HELO/EHLO command again?  Is it 
> worthwhile providing a "What is my name?" callback (that can be 
> overridden) to try and automagically detect whether or not our name is 
> likely to be meaningful based on domain suffix or IP address, and if 
> not, use address literal? 
Yes, that is the expectation.  If the domain can not be publicly 
resolved, then you should use a square-bracketed IP address.  I believe 
that is the spec, at least at the ESMTP (Extended SMTP) level which 
means EHLO support, not HELO.

> Or, given how some sites hate address literals, would it be easier and 
> simpler to just churn out a completely useless "FQDN"?  (I can't 
> really see any convincing privacy argument in favour of one over the 
> other, either.)
Don't worry about hurting a computer's feeling! <g>    Follow the 
expectation because there is FILTERING going on.
I believe SMTP says that the value of HELO/EHLO  MUST be correct 
(expected to be resolvable) but due to history of operations, it may not 
be reliable (not always correct). There are legitimate reasons why the 
value was wrong in scaled out layouts.  Unless the SMTP client automated 
preparing the value, a static value setup for one original machine would 
be wrong on multiple outbound computers if they use the same single 
source setup.  Thats one reason why it may not be reliable.  Need a new 
SMTP client worker? Easy! Just the setup of a working one!
That said, I think the practice by Windows based systems, namely 
OUTLOOK, was to use the NETBIOS name of the computer when there was no 
public domain for the machine and this name did not have dot(s), at 
least for the early 8 character limit version.   The dotting as a norm, 
even for private networks (like Active Directory) came later.
This is our current, out of the box, logic for HELO/EHLO checking:

1) No dot presented, assume NETBIOS and skip checking.  This makes it 
backward compatible with legacy systems.   Except for one check noted 
below, its not possible to do a valid check outside the private 
network.  Just move on.   If the domain is "LocalHost" then the 
connected IP must be a loop back address.
2) If squared bracketed, by specification assume a dotted IP address and 
by SMTP specification this allows for a simple SMTP compliancy check to 
verify the IP of the connection matches the provided IP literal.   You 
are allowed to do this because when a IP Literal is presented, it MUST 
machine the connected client IP address.  This yields a pretty high spam 
rejection with 100% zero false positives after at least 10 years of 
automated operations.
3) If dotted, not squared bracket, do various domain checking which we 
have OFF by default because it is really unreliable for legacy reasons 
and exactly the reason you posted for private dotted names, however
4) If the provided domain matches your own locally owned domains and the 
IP address does not support this networking, then you have here a local 
version of a SPF check.  Its like a lite-weight SPF concept but this 
doesn't use DNS to lookup anything. Its part of a rules table that 
defines the local network of domains and their IPs, etc.
My point is that your client SHOULD use a public domain, but if it can 
not, it SHOULD use a valid square bracketed IP address.   IMO, it 
"SHOULD NOT" use a private dotted domain as this can add pressure to 
receivers. If its constantly incorrect, then this is DNS redundancy 
overhead on receivers.
The alternative is to follow the older Outlook like behavior of getting 
the NETBIOS name of the machine, but one that doesn't use a dot.  I 
believe all internet domains must have at least ONE dot.
--
HLS
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp