Re: Input on identities

["Alan DeKok" <aland@xxxxxx>]

Markus Stumpf <maex-lists-email-ietf-mxcomp@xxxxxxxxx> 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.