Hector,
There are, IMO, two rather separate issues here. One is whether
that specific IP address should have been rejected and how that
gets fixed. That is a question you would need to take up with
the Secretariat. The other is whether the error report is
correct and sensible. It clearly is not.
Even if this was an SPF check or something equivalent, it would
justify neither the claim that the problem is with the EHLO
command nor the allegation that some 2821 restriction was not
met. So, while we can speculate endlessly on what,
specifically, the bug is and how it came be be, the answer to
your original question is that this is fairly clearly a bug (or
two) and should be reported appropriately and fixed... and that
there is little or nothing that can be done with 5321 (much
less 2821) or on this list that would contribute to getting that
done (unless, and this would surprise me, the Secretariat claims
the behavior is correct, in which case we could all try singing
"no, it isn't", in unison :-( ).
best,
john
--On Sunday, December 1, 2019 19:09 -0500 Hector Santos
<hsantos=40isdg(_dot_)net(_at_)dmarc(_dot_)ietf(_dot_)org> wrote:
On 12/1/2019 3:41 PM, John C Klensin wrote:
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.
In the trace provided, the [A.B.C.D] was my winserver.com IP
address. I should of just shown the actual I. It was legit.
821 did support ip literals and it was used. Since 2003, my
server did an client connection IP check against the bracketed
ip-literal provided. The brackets is the trigger for a valid
dotted IP address check rule.
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.
Right, it was legit. I tried to just state the case
generalizing the IP.
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.
The trace shows the server delayed the response until RCPT TO
was provided. This is most likely to collect all four
envelope process parameters for logging and I will presume it
was part of a SPF processor. So what is this implementation
at ietf.org doing?
Given:
response := MY_SPF_CHECK_HOST(CIP, CDN, RP, FP)
where the SMTP process (envelope) parameters are:
CIP Client IP
CDN Client Domain Name (HELO/EHLO host name)
RP Return Path (MAIL FROM)
FP Forwarding Path (RCPT TO)
The following is all possible:
Was it trying to do a SPF check on the CDN? This is not
always enabled since it considered unreliable and not always
defined. As an exception, did it do a CDN check because the RP
was NULL? If so, before calling DNS to query the CDN SPF
record, a syntax check is done. It didn't like the bracketed
IP address and the rule was enforced because PTR Records do
exist for the CIP?
Who knows, but it could of read the 1st paragraph MUST use a
host name, since one existed for the CIP, as the justification
to ignore the 2nd paragraph "MUST NOT refuse" requirement.
Since 2003, there has been much in the area of trying to
justify and legitimize the machine name and IP association in
some protocol or filter, but the false positives are just
still too high to enforce it.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp