[Top] [All Lists]

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

2013-03-26 19:51:06

On 3/26/2013 12:17 PM, Sabahattin Gucukoglu 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 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.

ietf-smtp mailing list