--On Sunday, December 1, 2019 15:21 -0500 Keith Moore
<moore(_at_)network-heretics(_dot_)com> wrote:
On 12/1/19 2:56 PM, John C Klensin wrote:
Two things are not clear from that text: (i) while the
language describing a domain name requires that the domain be
resolvable with the target RRSet containing an address RR,
there does not seem to be a requirement that whatever is at
those address(es) support an SMTP client or server.
My take on this is that the SMTP server has an implementation
bug, likely a failure to really upgrade to RFC2821 from
RFC821. (I'm tempted to cite laziness but I must also admit
that the RFCs are hard to read and the protocols have lots of
corner cases that are rarely exercised - so I'm not surprised
if implementors are impatient and cut corners. I've done
that myself.)
Actually, that explanation doesn't quite work either. I just
went back and looked at 821, and it rather clearly says
HELO <SP> <domain> <CRLF>
and then
<domain> ::= <element> | <element> "." <domain>
<element> ::= <name> | "#" <number> | "[" <dotnum> "]"
So
HELO [1.2.3.4]
Would be perfectly valid syntax under 821. So, of course, would
some combinations we'd find abhorrent today and that 2821/5321
prevent, like
HELO [1.2.3.4.5.6]
or
HELO [1.2.3.4].example.com
(I haven't checked closely enough to see whether there are
prohibitions in the text for either of those, but they aren't in
the syntax.)
So, if all someone did in "upgrading" to RFC 2821 from 821 was
to treat "EHLO" as a synonym for "HELO", the example Hector gave
would still be invalid. More important, it appears that they
actually made a serious effort to support EHLO because the
response is a multi-line one with options that an 821
implementation could not produce (and they are supporting
extended reply codes too). So, unless what was actually sent in
the example was a clearly invalid IPv4 address, with something
like
EHLO [500.600.700.800]
as an example candidate, I don't see any good basis for
rejecting on the basis of a 2821 (or 821 or 5321) restriction
about EHLO arguments. Nor do I see any justification for an
IETF system reporting anything in terms of 2821 rather than
5321. Unless we want to encourage others to disregard out
standards, the "eat one's own dogfood" principle should apply
here.
best,
john
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp