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
<arnt(_at_)oryx(_dot_)com> 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).