--On Saturday, September 4, 2021 16:25 +0100 Sabahattin Gucukoglu via Exim-users <[email protected]> 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 <[email protected]> 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/ -- ## 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/
