Markus Stumpf <maex-lists-email-ietf-mxcomp(_at_)Space(_dot_)Net> wrote:
So you're not supposed to validate the EHLO field.
And the standard answer to this is:
7.7 Scope of Operation of SMTP Servers
It is a well-established principle that an SMTP server may refuse to
accept mail for any operational or technical reason that makes sense
to the site providing the server.
Of course. But I still question the utility of a field which:
a) is supposed to be a fully qualified domain name
b) is not supposed to be verified to be a FQDN
If it was called "opaque identifier, suggested to be a FQDN", that
would be a little more self consistent.
and it would also be in full conformance with the RFC if for operational
reasons we would choose to not accept messages from hosts that use HELO
arguments that do not resolve.
Section 4.1.4 would appear to forbid this.
A an idea which would be fully RFC compliant, and backwards
compatible, would be to have a global registry of MTA's, and to use
the argument of EHLO as an entry in that registry. e.g. "EHLO
mta-xyx.registry.example.com". If the SMTP client used STARTTLS with
a certificate signed by the registry, you could at least have some
kind of global identity tracking, accountability, and accreditation.
Insert standard arguments here opposing this idea due to imposition
of a global dictatorship. It's only meant to be a toy model...
Alan DeKok.