--On Saturday, September 4, 2021 16:25 +0100 Sabahattin
Gucukoglu via Exim-users <exim-users@???> wrote:
>> If postscreen is doing it so wrongly, it is the thing that
>> needs fixing.
>
> I agree, it is, but Exim should be robust, all the same.
> Deferring mail when not needed is obviously undesirable.
Not so obviously. If one believes this might be a
misconfiguration error (i.e., the fault of whomever set up the
destination server and its MX configuration in the DNS) it would
make perfect sense to do the lookup again and retry a different
MX server or even to assume that the configuration problem is
temporary.
But, again, a multiline reply with different codes on the lines
is sufficiently broken but whatever the client does in response
does not violate the spec.
Incidentally, the reference in my prior note to Section 4.2.4.2
in RFC 5321 was incorrect. That section appears only in
rfc5321bis [1].
> Postscreen's entire reason for being is to defend against
> the Internet's SMTP barbarians, so being standards-compliant
> is perhaps understandably not a high priority. I don't
> approve, myself, and haven't used it, but I appreciate why
> it exists. The site should configure it right, but by its
> nature it cannot co-exist with a valid SMTP server process
> while efficiently disposing a new client, and if it rejects a
> site by policy, it's not obliged to accommodate it.
If it is configured to respond on an SMTP port, it still has
some small obligation to avoid violating the spec for no good
reason. See below.
--On Saturday, September 4, 2021 11:23 -0400 Viktor Dukhovni via
Exim-users <exim-users@???> wrote:
>...
> Absent a time-machine, and given that the ultimate decision is
> made after the initial banner and greet pause, and that
> refusing SMTP service (521 banner) is supposed to only happen
> to botnet and similar clients, the postscreen(8) service has
> no choice but to appear to change its mind after the initial
> "220-".
>...
If, by "change its mind", you mean "send a response sequence
with different codes", not true. First, if it cared about the
SMTP spec (and I understand the reasons why it might not), it
should accumulate whatever information it thinks useful before
sending the initial connection response and then reply with
either 220 or 521 (or something else) as it thinks appropriate,
not try to mix them. Second, it could return 220 (normally
considered the correct response if it accepts mail from anyone)
and then return 521 reply codes to any further commands until
either those commands stopped coming or it go fed up and just
closed the connection.
It does occur to me that a "no mail accepted right now" code
might help to clarify the situation. Watch for rfc5321bis-04.
john
[1]
https://datatracker.ietf.org/doc/draft-ietf-emailcore-rfc5321bis/
