[Top] [All Lists]

Re: [ietf-smtp] SMTP server "RFC2821 Violation" for EHLO ip-literal.

2019-12-01 18:09:59
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> "]"

    HELO []

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 []
    HELO []
(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 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

    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

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 doing?



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