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

Top Page
Delete this message
Reply to this message
Author: John C Klensin
Date:  
To: Viktor Dukhovni, Andrew C Aitchison
CC: exim-users
Subject: Re: [exim] exim can't handle 521 response from remote MX
(Note two responses combined below)

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

>...
> The status code on the last line of a multi-line response is
> and will be taken as authoritative, regardless of any other
> status codes on prior lines of the response. This has worked
> well enough for 22+ years.


Viktor,

As I assume you may have guessed given that you follow
EMAILCORE, my main interest in this right now is to think about
what changes, if any, are needed in 5431bis.  Watch for a note
on that list and some changes in -04 that reflect this
conversation, for which thanks to everyone.    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.


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. 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.
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...

--and--

--On Saturday, September 4, 2021 20:00 +0100 Andrew C Aitchison
via Exim-users <exim-users@???> wrote:

>> The greet pause test is *specifically* designed to detect
>> botnet spam engines that don't wait for the complete
>> multi-line response, and start talking as soon as they detect
>> the first line of the response. That's why the pause is
>> after, and not before, "220-". This is also why the final
>> response code is unavoidably different from the initial.
>
> Are you saying that applies in this case ?
> If so, then exim is replying during the greet pause, which is
> a real bug ?


Yes, if exim, or anything else, were responding before the last
line of a valid multiliine response was received, that would be,
as I understand the standard, a bug. However, if an SMTP client
saw one or more lines of a multiline response that started with
a particular code and then a line with some other code (whether
it carried a continuation indicator or not), well that is
outside the spec and nothing that client did, including closing
the connection or sending an immediate command (especially if it
were QUIT), would violate the spec clearly enough to be an
unambiguous bug.

    john