Re: [exim] exim can't handle 521 response from remote MX

[John C Klensin via Exim-users]

--On Saturday, September 4, 2021 17:14 -0400 Viktor Dukhovni via
Exim-users <exim-users@exim.org> wrote:

>...
>> From that particular perspective and purpose, as soon as
>> someone says "for my specific application or bright idea, it
>> does not matter what the standard says", I sort of lose
>> interest.
> 
> FWIW, the "does not matter" in question is very narrowly
> scoped to the fine-grained detail in the second and third
> digits of 3-digit SMTP responses.

I was actually thinking more about the comments that postscreen
was going to do what it did for good reasons and was not going
to change.  But, as to the codes...
 
> You might recall the "what dogs hear" analogy from an earlier
> thread on emailcore.  Many an SMTP client doesn't look beyond
> the first digit of the SMTP server's response.  Postfix is
> among them, perhaps Exim is not?

IIR (running out of time and cycles today), 5321 already says
that the first digit is the important one and that it is
necessary to pay attention to other digits only if they are
important to the client or elsewhere in the mail handling
system.    I've seen multiple situations in which making the
distinctions implied by those additional digits in cases you
didn't list are important, but most involve systems receiving
and processing NDNs, not SMTP clients themselves.   My sense is
that, if Postfix or some other SMTP client does not find it
useful to process past the first digit, it is just fine,
provides useful future-proofing, and is completely consistent
with the spec.  I do hope, however, that when Postfix is acting
as a server, it is careful about the codes that it generates,
supplying as much information as possible in the primary codes
and, ideally, adding Enhanced Status codes where they would
provide additional information.  
 
> We do strive to emit the expected 2XY/4XY/5XY codes, but
> expect others to use them consistently in return.

See above.

>> However, while (apparently unlike many of the rest of you) I
>> have not spent any significant time in more than a decade
>> pouring over logs looking for mail transaction behavior
>> anomalies, I don't believe "worked well enough for 22+ years"
>> actually conveys much information.
> 
> What's worked well in this context is using the response from
> the last line.  Actually emitting a different response code on
> the last last is a much more recent "innovation", and is used
> very narrowly to turn away abusive botnet nodes without the
> cost of tying up a heavy-weight SMTP server process to handle
 the connection.

I think this is what I said.  I was just pointing out that, if
the codes on all of the response lines are the same, picking the
first one, the last one, or the one in the middle would all have
worked equally well.

> The postscreen(8) service is an optional feature, that is off
> by default, and greet pauses are also off by default, even when
> postscreen(8) is enabled.

Good.

> Legitimate MTAs are typically not turned away by
> postscreen(8), so seeing the "220-" followed by a "521" is by
> far the exception rather than the rule, and if a legitimate
> MTA ends up retrying the message, that could be argued to be a
> feature, the undeserved IP reputation might have been resolved
> by then.

ON the other hand, if you actually wanted that retry, you might
reasonably return something in the 4yz range, which would
encourage it.  In any case, if a legitimate MTA does not
understand postscreen's private conventions - whether about
switching codes in a multiline response, a delay between the
first line and subsequent ones, the particular choice of codes
or something else, I don't think there is any grounds for
complain about what it does or does not do. next.

> Indeed Postfix (as a client) defaults to retrying (another MX
> or defer to later) after a 5XX greeting.  So Exim is not doing
> anything unexpected.
> 
>> When I was last looking at those logs, the number of times I
>> saw a server returning a multiline reply with mixed codes was
>> zero or very close to it.
> 
> This both recent and unusual when the client is not a botnet,
> ...
> 
>> If all of the codes are the same, as SMTP requires, then
>> things will work well no matter which one is picked.   Now,
>> if you were to say "there haven't been any problems since
>> this behavior first became common N years ago", that would be
>> useful information.  But...
> 
> The variable multi-line response code server-side behaviour is
> new with postscreen(8), which was first released in Feb 2011.
> 
> As mentioned above, it should be rather rare for a legitimate
> MTA as a client to see such responses.  Users of postscreen(8)
> should be cautious to not make it too aggressive in its
> policies.  The intent is to reduce the number of bad
> connections that make it through to the real SMTP servers, not
> eliminate all possibility of unwanted clients getting through.
> Light-weight first stage of defense in depth.

Good.  And good whether I would choose to run such a filtering
system or not.

   john


-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/