Re: Correct value for EHLO when submitting mail

On 1/29/2014 3:08 PM, � wrote:
> Hi,
> when a MUA submits e-mail over SMTP, what value shall be used in the
> HELO/EHLO greetings? Shall I just stick with "localhost", or trust the
> OS-reported hostname, if any, or shall I use the IP address of my
> local endpoint?
>
> I see problems with all of these, and apparently Thunderbird went
> through a nice discussion on this matter [1]. I didn't find any answer
> about that in RFC 6409, unfortunately, and RFC 5321's discussion [2]
> about this topic leaves me without a definitive answer, either -- the
> MUA will have zero idea about the "primary host name" and its relation
> to what OS returns, so I'm inclinded to interpret this as a suggestion
> to use address literals, but then I've heard about spam filters
> penalizing such messages [1]...
>
> What is the current best practice?
>
> With kind regards,
> Jan
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=279525
> [2] http://tools.ietf.org/html/rfc5321#section-4.1.4


Hi,

The optimal RFC compliant MUA/MTA design is the automated and dynamic 
one which is:

   1) Get the client IP address from the current socket connection,
   2) Perform a rDNS (reverse DNS) lookup to get a host name,
   3) Fall back to one of two options depending on SMTP vs ESMTP session.

      1. For ESMTP, use the *square bracket* IP address of connected 
client,
      2. For SMTP, use non-dotted host name (netbios, computername).

However, since this is not 100% reliable for reproducing a verifiable 
check by the receiver, be prepare to have a manual configuration to 
set a fix value that should still be 100% correct all the time as 
well. The manual method will be needed where it is not possible for 
the dynamic and automated method to work reliably.   Of course, its 
desirable to avoid a manual setup because it adds documentation and 
tech support and cost -- its not "out of the box."

For our server, using LocalHost is ok, IFF the connection IP is a 
local loop back address.

Use the undotted in worst case scenarios.  A dotted field can trigger 
a DNS IP::HostName check and even though 2821/5321 says do not reject 
on this basis of a mismatch, there could be tighter strict systems out 
there.  I don't know where yet, but you don't know.  Main point: if 
you going to use a dotted field, make sure it is correct.

About Windows based machines ...

Due to the nature of the Windows network, its history, the machine can 
be using NETBIOS and this may not be dotted. This is one big reason 
NOT to do any check when its not dotted to avoid big time support 
issues with Microsoft based MUAs like the once dominant Outlook 
Express (OE).

About TBIRD....

With the advent of the wireless home NAT market and SOHO (Small 
Office/Home Office) market, TBIRD had a compliancy problem where it 
followed the automated logic above but it resulted with the private IP 
address of the client machine, for  example:

      EHLO [192.168.1.2]

Since it did not know about the NAT's public IP address, any receiver 
MSA or even MDA performing a strong check for a valid IP literal field 
by comparing it to the connected IP address, could issue a 55x response:

So at least since TBIRD 2.01, it allowed you use the Config Editor 
(TOOLS | OPTIONS | ADVANCED) and add set new value:

  mail.smtpserver.smtp1.hello_argument     [fixed NAT ip address]
  mail.smtpserver.smtp2.hello_argument     [fixed NAT ip address]
  mail.smtpserver.smtp3.hello_argument     [fixed NAT ip address]
  ....
  mail.smtpserver.smtpX.hello_argument     [fixed NAT ip address]

If set, the TBIRD MTA will use this over the local machine IP on a per 
outbound server basis.

But of course, receivers can not wait for TBIRD updates or any other 
MUA to be updated, so we added a SUBMIT protocol option that will skip 
this strong IP literal check for PORT 587 connections only.

I did give the 4409Bis (4409) authors a note and suggestion for a 
design point/note about this. Overall, since the protocol requires a 
strong authenticated (ESMTP AUTH) session, a MSA implementation can 
afford to skip or relax the EHLO check to better support their users 
with updated MUAs using the wrong EHLO IP literals.


-- 
HLS


_______________________________________________
ietf-822 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-822