Again, without arguing for one position or the other and using Arnt's note as a framework for responding to several others...
--On Friday, January 23, 2009 13:36 +0100 Arnt Gulbrandsen <[email protected]> wrote: > Paul Smith writes: >> Doesn't HELO name the client as well? > > Standards documents have to be pedantic, and there is a > pedantic difference: 821 says HELO names the client's host > name, 2821 says EHLO names the fully-qualified domain name. The tighter definition of the argument in 2821/5321 is, indeed, the key difference between the two for clients that don't want _any_ advanced/ extended capabilities. There are other differences, but they have to do not with the difference in the HELO/EHLO dialogue. When a client sends EHLO and a server responds positively to it, they have signed up to the much tighter and more specific conformance language of 2821/5321 rather than the looser language (and strong expectations about good intentions and the robustness principle) of 821. That signup permits both parties to make stronger assumptions about the behavior of the other, again if one can assume good intentions (or is willing to treat misbehavior as a sign of bad intentions). I probably should have been more clear, but, while the conversation I mentioned included some discussion about spam/ anti-spam implications and inspired my question, I didn't mean to imply that I personally thought the change would have any useful effect on spam-fighting or that the conversation was about perceived bad spammer behavior rather than bad anti-spammer behavior. There is another, associated, possible ambiguity in the text that we should decide whether to fix (it is less important if we explicitly deprecate 821). The material in 2.2.1 about the relationship between HELO and EHLO can be read as saying that, unless the document says something explicitly different, the clarifications apply to HELO as well. I think that reading was the DRUMS intention. Certainly the syntax given for HELO in 4.1.1.1 is consistent with that reading: it says "Domain" (which is narrowly defined in the document) and does not invoke the more relaxed language of 821 that has been widely interpreted as permitted "HELO localhost". The 1123-imposed requirement (carried forward into Section 4.1.4 Paragraph 6 of 5321) that messages not be rejected on the basis of a validation failure with the EHLO argument would presumably remain even if we deprecated 821 and client use of HELO. We could discuss changing that, but it would be a sufficient change in requirements to require evaluation of whether a reset to Proposed would be needed. So, if this is worth doing at all, the major motivation would presumably be more clarity and better interoperability among parties with good intentions and good information. It is not clear to me that it would provide much pushback on those whose intent is to sneak around the rules. Of course, someone who cared less about getting every possible legitimate message through than about eliminating every possible unwanted one would probably take advantage of the "you are not required to accept messages" principle to return a "5yz HELO has been obsolete for years and I see no need to talk with old servers" message... but that would be an operational decision outside the standard and one that could be made today. Of course, Alessandro's suggestion of an address-range restriction for use of HELO could be generalized and written to take the protocol one step further in that "operational decision" direction (without encouraging treating IP addresses as authenticators as a side effect) by saying that HELO SHOULD be used only by prior arrangement between consenting adults. That approach would also weaken the "go use SUBMIT" position for situations in which it was inappropriate. best, john p.s. to clarify something that may be a misunderstanding in some of the messages on this thread, SUBMIT (RFC 4409) does not require SMTP-AUTH (or Start-TLS). What it does is to specify that SMTP-AUTH is required "unless it has already independently established authentication or authorization" (Section 4.3). Presumably Start-TLS falls under the "unless" part, but so would any other acceptable-quality mechanism. And, while it would clearly be non-conforming and violate MUST provisions of RFC 4409, nothing we've done or specified would really prevent an MUA from make prior private arrangements to communicate with a submission server (on port 587, 25, or a non-standard/user one) using a HELO handshake (or a FOOBAR handshake, for that matter).
