Robert A. Rosenberg wrote:
I agree that it is mainly a Submit issue BUT since 2821bis says
that HELO is a valid way of initiating a SMTP Session
Obviously not for ESMTP, ESMTPA, ESMTPS, ESMTPSA, or the future
(experimental) UTF8SMTP set.
we have a conflict with Submit's requirement for authentication
authorization
No, there's no conflict. If the MSA offers (only) SMTP AUTH for
auth* it can't accept MAIL after HELO, that would violate a MUST in
RFC 4409.
But maybe the MSA supports SMTP-after-POP with enforced submission
rights (4409 6.1), or it uses RADIUS, or it's in a LAN with trusted
users <shudder />.
at least a note of this is IMO useful in the HELO section
A note stating that HELO can't negotiate any SMTP extensions (not
limited to 2554bis) ? There's already a "MUST support EHLO" for
all servers in 2.2.1, with a corresponding SHOULD for all clients.
Is what you're looking for a pointer to chapter 2.2 in 3.2 ? Or
in 4.1.1.1 ? (I'm not sure what you consider as "HELO section")
I think there's an xml2rfc trick forcing header level 4 sections
like 4.1.1.1 into the table of contents.
maybe just noting that HELO is not compatible with Submit
That's not the case...
pointing at the Submit RFC for details
...but an informative reference to 2554bis somewhere in chapter 7
is an idea if you think that the 4409 reference isn't good enough.
The references might need more work: Maybe s/[13]/[14]/ and get
rid of [13]. Chapter 7.1 is a mess. I think adding 2554bis is a
job for chapter 7 (security considerations), not for one of the
EHLO sections. DKIM, EAI, SPF, and Alexey's I18N I-D could also
get informative references somewhere. Now while I didn't see a
slippery slope in John's IPv6 reply, this "more references" idea
should trigger all "rathole" alerts.
IMO 2821bis really needs a reference to RFC 3848 somewhere. As
"downref" if necessary (why on earth is 3848 a PS and no BCP ?)
Frank