On 15-07-01 09:12 AM, Alarig Le Lay wrote:
Hi,
According tohttps://tools.ietf.org/html/rfc5321#section-2.3.5 it’s said
that the EHLO must be resolvable and resolve to the A or the AAAA of the
MX but it’s not necessary to be the PTR of the MX.
(It’s what I understand, I could be wrong)
In principal, this sounds fine, but there are many reasons for company's
to have EHLO using internal addressing schemes, which may not be
publicly resolvable, and in practice limiting connections based on that
criteria affects too many legitimate email servers to make it a 'policy'
rejection IMHO.
We do require that it is a properly formed 'FQDN', and not just a host
name, (and not localhost.localdomain ;) but to actually require
resolvable EHLO is still problematic, and should only be used as a
'scoring' factor, but not an absolute policy.
Often admin's would like to identify 'nodes' in a cluster, if there is a
problem, and often this is represented in the EHLO (eg
intident-1-3.ourpublicdomain.com), rather than
'mail.ourpublicdomain.com' for all nodes. (rDNS of course is easier to
have it match the A of the MX, but again in practice many use different
naming conventions for egress vs ingress, eg mail.ourdomain.com vs
mx.ourdomain.com)
Differing EHLO/HELO makes debugging and support easier, and we can
understand the motivation, even though not specifically correct per RFC,
of sysadmin's to do so, since the EHLO is presented on all connections,
while additional headers may not be available at the receiving end to
clearly identify which 'internal node' generated the email. And often
EHLO is tied into internal naming conventions (eg hostname of the
server) (and desired by the sysadmin) by default in most MTA
implementations, unless specific overridden.
There are a couple of places where following the RFC's to the letter
simply won't work in the real world (as receivers), but we should be
trying where ever possible as 'senders'.
But in the end, you have to understand when a receiver chooses to not
accept NON-RFC compliant communications.
And of course, spammers very often have access to be able to present
their own 'EHLO', but may not have access to rDNS, so many spam
protection systems will highly weight senders where the EHLO/HELO
appears to be 'strange'.
IMHO, if the domain portion of the rDNS matches the EHLO domain portion,
and they are both FQDN's, the 'host' portion of the EHLO is less important.
--
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
------------------------------------------------------------------------
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada
This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.
_______________________________________________
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop
