[Top] [All Lists]

Re: RFC 5321bis / 2821ter

2009-01-23 12:53:47

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", if SPF were included in an extended registry of (meaningful) Address Literal Tags. Presumably, 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."

<Prev in Thread] Current Thread [Next in Thread>