Subject: [ietf-822] Correct value for EHLO when submitting mail

From: Jan Kundrát <[email-masked]>
Date: Wed, 29 Jan 2014 21:08:22 +0100

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

-- 
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

---

From: Brandon Long <[email-masked]>
Date: Wed, 29 Jan 2014 12:58:52 -0800

It seems really silly to penalize an MSA connection based on its EHLO
greeting.

Our top 20 helo arguments:
localhost
ipcamera
[127.0.0.1]
WebCAM
smtp.gmail.com
gmail.com
[192.168.1.2]
[192.168.1.3]
[192.168.1.4]
[192.168.1.5]
localhost.localdomain
[192.168.1.100]
[192.168.1.6]
[192.168.1.101]
[192.168.0.2]
UserPC
[192.168.0.3]
[192.168.1.102]
[192.168.1.7]
[192.168.0.4]

which is to say, lots of clients seem to be using the IP, on the order of
45% of the MSA traffic we see.

Given the rise in mobile clients, I have to assume the usage of MSA is much
higher now than it was in 2005, so I would hope that spamassassin would be
smarter now.

Brandon

---

From: Patrick Ben Koetter <[email-masked]>
Date: Wed, 29 Jan 2014 22:23:47 +0100

* Jan Kundrát <[email-masked]>:
> 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]...
> 

Dunno if this is common best practice, but here's my rationale:

In MTA to MTA communication on port 25 it makes sense to check for reasonable
HELO hostnames:

- not your own
- not from a private network you can't connect back (bounce)

In MUA to MTA communication on port 587 it doesn't make sense to check for or
enforce HELO hostnames:

- the underlying OS often does not return a valid HELO hostname (not a FQDN)
- the identity sent during AUTH creates the trust required to accept and
  transport the message

p@rick

-- 
[*] sys4 AG
 
http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

---

From: Tony Finch <[email-masked]>
Date: Wed, 29 Jan 2014 22:29:30 +0000

> It seems really silly to penalize an MSA connection based on its EHLO

Right. It is amazing what insane crap mainstream MUAs will shove at
submission servers. Since I can't fix the world the best I can do is make
my servers work for my legitimate users, but my job would be easier if
MUAs would refrain from blatant syntax errors.

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: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 29 Jan 2014 14:51:10 -0800

I think as long as you stick to the RFCs, you'll be fine.  There are some
particularly strict MTAs or filters out there that demand the HELO/EHLO
parameter is RFC compliant.  "localhost" or a bare IP address would be
rejected.

SPF would also possibly fail on "localhost", though it would be weird to
check internal IP addresses for SPF compliance.

On Wed, Jan 29, 2014 at 12:08 PM, Jan Kundrát <[email-masked]> wrote:

> 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
> _______________________________________________
> ietf-822 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-822
>

---

From: Jan Kundrát <[email-masked]>
Date: Thu, 30 Jan 2014 01:59:48 +0100

On Wednesday, 29 January 2014 23:51:10 CEST, Murray S. Kucherawy wrote:
> There are some

To make sure I understand you correctly -- when using submission, you 
advocate against using "EHLO 203.0.113.66", but are OK with "EHLO 
[203.0.113.66]", right?

Given that HELO is only specified with Domain, not Domain / 
address-literal, what is the recommended way of greeting the older servers 
which don't support EHLO?

With kind regards,
Jan

---

From: "Carl S. Gutekunst" <[email-masked]>
Date: Wed, 29 Jan 2014 17:14:32 -0800

> advocate against using "EHLO 203.0.113.66", but are OK with "EHLO 

As long as you are crossing your t's and dotting your i's, don't forget 
about IPv6. Exchange Server seems to accept malformed domain literals 
for IPv4, but for IPv6 it insists on correct syntax, e.g.,:

EHLO [IPv6:2620:9f:0a:320e::28]

<csg>

---

From: Hector Santos <[email-masked]>
Date: Wed, 29 Jan 2014 23:38:06 -0500

On 1/29/2014 3:08 PM, � wrote:
> OS-reported hostname, if any, or shall I use the IP address of my
> local endpoint?
>
> 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]...
>

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

---

From: Hector Santos <[email-masked]>
Date: Wed, 29 Jan 2014 23:46:09 -0500

> - the identity sent during AUTH creates the trust required to accept and

I agree with the relaxation. Its what our MSA does.

Port 587 does raise the (authentication/authorization) bar. It does 
make sense, just not reliable in practice to enforce as it always was 
the case with port 25.   Port 587 assumes updated compliant ESMTP AUTH 
clients and even if it follows RFC 5821 with using a square bracketed 
IP literal, it could still be wrong (private machine IP vs public NAT 
ip address).

-- 
HLS