Paul Smith wrote:
Alex van den Bogaerdt wrote:
I would argue that 'EHLO
mailserver.domain.com' is more useful than 'EHLO [192.168.1.1]' even
though the former is incorrect, and the latter correct (according to RFC
5321) with dynamic IP/NAT.
IMHO 192.168.1.1 is not an internet IP address. And that is a
I'm sorry, but that can't be the case.
Otherwise, how does Thunderbird send mail to a local mail server on a
private network? It can't, because it hasn't got an Internet host name,
or an Internet IP address, so can't issue a valid EHLO command.
TBIRD fixed this problem in 2.01 I believe. I submitted the Bug
request to add a user defined method to hard code the machine name or
address where the NAT is located the a private LAN.
TOOLS | OPTIONS | GENERAL TAB | CONFIG EDITOR
I forget, either its there or you have to add it for each outgoing account
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.
Similarly, how does ANY SMTP client behind a NAT router with dynamic IP
(ie pretty much any home user) send a message anywhere? If what you say
is the case, then that is cutting off half the world from the SMTP network!
Another way to solve this is where EHLO checking should be delay until
other authentication methods may have been established, e.g.; ESMTP
AUTH, POP B4 SMTP, etc.
This was something I proposed to John and Randy for 4409 (Submit)
where since AUTH is requirement, the strong EHLO checking can be relaxed.
As far as I am aware, RFC 4409 doesn't relax the requirements of RFC
2821/5321 for the EHLO parameter, so 'use message submission' is not the
Right, I brought this up to John, I think it was early last year or 2
when I was helping the Mozilla team address the "Private address
across a NAT" TBIRD issue.
Hector Santos, CTO