Private Domain Names and the EHLO/HELO Command

[Sabahattin Gucukoglu]

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

[John Levine]

Post by Sabahattin Gucukoglu
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

[hector]

Post by Sabahattin Gucukoglu
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.

Post by Sabahattin Gucukoglu
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.

Post by Sabahattin Gucukoglu
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

[Steve Atkins]

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

[hector]

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.

Post by Steve Atkins

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
_______________________________________________
ietf-smtp mailing list
https://www.ietf.org/mailman/listinfo/ietf-smtp

[hector]

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

Post by hector
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.

Post by Steve Atkins

Post by hector
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
_______________________________________________
ietf-smtp mailing list
https://www.ietf.org/mailman/listinfo/ietf-smtp

[SM]

Hi Sabahattin,

Post by Sabahattin Gucukoglu
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.

"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

[Tony Finch]

Post by Sabahattin Gucukoglu
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...

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.

[Sabahattin Gucukoglu]

Post by Tony Finch

Post by Sabahattin Gucukoglu
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. :-)

Post by Tony Finch
(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.

Post by Tony Finch
(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.

Post by Tony Finch
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.)

Post by Tony Finch
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

[Tony Finch]

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

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

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.

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

Tony.

[hector]

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

Post by Tony Finch

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

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

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.

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