ietf-smtp
[Top] [All Lists]

Submission identifiers (was: Re: RFC 5321bis / 2821ter)

2009-01-23 17:59:33

Subject line changed because this is really about a new feature,
not an appropriate clarification for a 5321-> 5321bis transition.

--On Friday, January 23, 2009 18:37 +0100 Alessandro Vesely
<vesely(_at_)tana(_dot_)it> wrote:


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.

Free advice: Changing the argument to EHLO from FQDN-or-literal
to trick-identifier is likely to be a non-starter.  A very large
fraction of the deployed base would treat SPF:example.com (or
anything vaguely like that) as a syntax error and reject the
message.   If you are trying to reject every message that
doesn't contain SPF (or whatever) information, there are easier
ways.

Consider instead an ESMTP extension command, say IAGG (I'm A
Good Guy), that was required to be issued immediately after EHLO
if one intended to use it.  It would give you complete freedom
to specify its arguments (without being limited by EHLO's
syntax) and to decide how they would be interpreted, what should
occur if the command was not present, and what should occur if
you didn't like the arguments.  If you didn't like the extra
turnaround, do it as an extension parameter to MAIL (and
possibly to HELP, VRFY, and EXPN if you meaningfully support
those at all).

It would avoid getting the new ideas about what the field might
be used for tangled up with an installed based that believes
that it knows what is there and what syntax it obeys.


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."

Keep in mind that there are things that send SMTP that don't
know their own names, may know there own addresses only in
private address space behind a NAT, and have no way to anchor
SPF information even if they wanted to.

     john

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