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 <[email protected]> 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
