Paul Smith wrote:
To get around [meaningless address literals], you use SMTP
submission with SASL (OK, that requires EHLO anyway, but the EHLO
name is irrelevant in that case).
IMV, if it is expected by the base standard that the EHLO data is
to be used for anything other than logging/tracing, then these
considerations and more need to be looked at carefully.
That's apparently the split that Message Submission envisions. Either
the client validates a name using a password, or it uses a globally
registered, hence meaningful, name.
How "meaningful" can a name be? It shouldn't be overwhelmingly
difficult for an MTA to put after EHLO a FQDN that can be resolved to
its IP address. Probably the standard cannot be so rigid, but
including careful considerations of what circumstances may or may not
allow what names, seems a good idea.
David went so far as to ask for a reputation-ID after EHLO. I'm not
sure whether that would ease or complicate setting up an MTA. For
example, rather than a FQDN that resolves to an A record matching its
address, an MTA could say "EHLO SPF:example.com", if SPF were included
in an extended registry of (meaningful) Address Literal Tags.
Presumably, example.com would then resolve to an SPF record that
permits the same address. That could cope with not being able to know,
say, which address from a NAT pool will be used for an outgoing
connection.
What real cases are there that cannot be handled in similar ways? A
careful analysis could help to eventually eliminate the phrase (in
4.1.4) "if the verification fails, the server MUST NOT refuse to
accept a message on that basis."