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

From: Sabahattin Gucukoglu <[email-masked]>
Date: Tue, 26 Mar 2013 16:17:21 +0000

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.

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?  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.)

Cheers,
Sabahattin

---

From: "John Levine" <[email-masked]>
Date: 26 Mar 2013 23:26:08 -0000

>So, what should I do when sending the HELO/EHLO command again?

If you want people to accept your mail, send the FQDN of the public
address from which the mail is emitted.  In theory, the RFC says not
to reject on a bad HELO string, but in practice it's a rather strong
indication that mail is coming from a spambot or an abandoned and
easily abused old MTA.

Remember, it's not anyone else's problem if you've chosen to use
software that is hard for you to configure.

R's,
John

---

From: hector <[email-masked]>
Date: Tue, 26 Mar 2013 20:50:55 -0400

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 
> "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.

> 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

---

From: Steve Atkins <[email-masked]>
Date: Tue, 26 Mar 2013 17:55:07 -0700

On Mar 26, 2013, at 5:50 PM, hector <[email-masked]> wrote:
> 
> 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.

It'll fail all the time in the case of an MUA behind a NAT - which is going to be pretty common in the case we're discussing of a dumb SMTP client submitting to a smarthost.

Cheers,
  Steve

---

From: SM <[email-masked]>
Date: Tue, 26 Mar 2013 18:12:57 -0700

Hi Sabahattin,
At 09:17 26-03-2013, Sabahattin Gucukoglu wrote:
>the name is locally administered.  I checked RFC 5321 and can't get 
>a *definitive* answer concerning whether or not a name like 
>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.

"Sometimes a host is not known to the domain name system".  "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".

Regards,
-sm

---

From: hector <[email-masked]>
Date: Tue, 26 Mar 2013 21:20:43 -0400

Agree, which is why I got the Thunderbird folks to add a fix for the 
machine name configuration so it can be hard coded to the NAT public 
address.

In the mean time (and for the general others), for a submission server,  
I suggested that the EHLO required check allowed by a submission server 
be relaxed on the basic idea that eventually AUTHentication will take 
place as required by a submit server. So that is what we have - For port 
587 operations, since AUTH is required, the EHLO check is skipped.

For a dumb or any client really , at the very least it (ehlo/helo value) 
needs  to be manually settable or as I stated like Outlook will do, use 
a undotted name like the machine NETBIOS name, if any.  I think most 
clients will not bother (it can't, nothing to solve).

I am just suggesting what might be the least harmful.

- If you use brackets, you must consider IP checking will be done.
- if you use dotted names, you must consider some DNS/IP checking domain 
matching will be done, although enforcement is not practiced at this point.

Either it allows for manual setup for an IP literal or a NAT router 
public domain or use a netbios/undotted name, one that will not add 
overhead for receivers believe it can check it.

On 3/26/2013 8:55 PM, Steve Atkins wrote:
> _______________________________________________
> ietf-smtp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-smtp

---

From: hector <[email-masked]>
Date: Tue, 26 Mar 2013 23:53:52 -0400

As a follow up:

You also have security protocols like SPF which may do HELO/EHLO check 
and IMO, the advanced SPF implementation will skip the overhead if it 
doesn't have a dotted domain (no point if it fails DNS).   So I 
recommend not to use a private dotted domain when there is 100% 
awareness it will 100% fail at 100% remote receivers.   Consider the 
receiver overhead in all this.

BTW, what is meant by "Dumb" smtp client?

- its only allows or does not allow manual setting of helo/ehlo field?
- its does or does not do automated ehlo field setup?

As Steve pointed out, even a smart automated client that detects a 
public domain machine or uses the bracketed IP literal can fail when a 
NAT is involved.  So even the smarter ones are too smart. These clients 
need to be "dumb" down to also offer manual settings. This is exactly 
what happen with Mozilla's TBIRD.

--
HLS

On 3/26/2013 9:20 PM, hector wrote:
> In the mean time (and for the general others), for a submission 
> server,  I suggested that the EHLO required check allowed by a 
> submission server be relaxed on the basic idea that eventually 
> AUTHentication will take place as required by a submit server. So that 
> is what we have - For port 587 operations, since AUTH is required, the 
> EHLO check is skipped.
>
> For a dumb or any client really , at the very least it (ehlo/helo 
> value) needs  to be manually settable or as I stated like Outlook will 
> do, use a undotted name like the machine NETBIOS name, if any.  I 
> think most clients will not bother (it can't, nothing to solve).
>
> - if you use dotted names, you must consider some DNS/IP checking 
> domain matching will be done, although enforcement is not practiced at 
> this point.
>
>>> 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.
>> It'll fail all the time in the case of an MUA behind a NAT - which is 
>> going to be pretty common in the case we're discussing of a dumb SMTP 
>> client submitting to a smarthost.
>>
>> Cheers,
>>    Steve
>>

---

From: Tony Finch <[email-masked]>
Date: Wed, 27 Mar 2013 10:44:33 +0000

Sabahattin Gucukoglu <[email-masked]> wrote:
> 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...

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.

(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.

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).

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

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Wed, 27 Mar 2013 14:01:44 +0000

On 27 Mar 2013, at 10:44, Tony Finch wrote:
>> SMTP

No. :-)

> 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.

> too much about NAT making the client's view of the network appear 

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.

> 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.)

> 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

---

From: Tony Finch <[email-masked]>
Date: Wed, 27 Mar 2013 14:12:48 +0000

Sabahattin Gucukoglu <[email-masked]> wrote:
>
> So in summary:
>
> 1.  Perform the usual reverse-forward-FQDN-search routine to find our "FQDN".

Easier and good enough just to use gethostname() or equivalent.

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

More precisely, use getsockname() on the socket that is connected to the
server, and don't bother checking if it is private.

Tony.

---

From: hector <[email-masked]>
Date: Wed, 27 Mar 2013 11:18:29 -0400

I think using DNS to resolve is more reliable (but not easier) for 
public resolution issues.  Using the socket stack API can provide more 
local information.  We had to eventually single source all applets to 
use a single DNS client API to resolve these related discovery, caching, 
round-robin, etc,  issues.  SPF, DKIM, ADSP, VBR, etc, all depend on 
using a DNS based public discovery/resolution.    The problem with 
socket stack functions is when OSes still use older networking 
protocols, such as NETBIOS, WINS/ARP, HOSTS files, as the higher 
precedence order for searching before going to DNS.

--
HLS