> On Sep 3, 2018, at 8:41 AM, Ralf Hildebrandt <[email protected]> wrote:
>
> Today a fellow postmaster (using Exim) called me, they were having problems
> sending
> mail to charite.de. In my log I found:
>
> Sep 3 00:31:18 mail-cbf postfix/postscreen[34943]: CONNECT from
> [31.7.179.105]:38256 to [193.175.73.208]:25
> Sep 3 00:31:24 mail-cbf postfix/tlsproxy[39995]: CONNECT from
> [31.7.179.105]:38256
> Sep 3 00:31:24 mail-cbf postfix/tlsproxy[39995]: Anonymous TLS connection
> established from [31.7.179.105]:38256: TLSv1.2 with cipher
> ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
> Sep 3 00:31:24 mail-cbf postfix/postscreen[34943]: NOQUEUE: reject: RCPT
> from [31.7.179.105]:38256: 450 4.3.2 Service currently unavailable;
> from=<[email protected]>, to=<[email protected]>, proto=ESMTP,
> helo=<smtpgw03.nextwerk.de>
> Sep 3 00:31:24 mail-cbf postfix/postscreen[34943]: COMMAND PIPELINING from
> [31.7.179.105]:38256 after BDAT: Received: from [213.182.136.75]
> (helo=NWH-EX13.nwcloud.loc)\r\n\tby smtpgw03.nextwerk.de with esmtpsa (
>
> After I disabled chunking, mail would flow again.
> Is this an Exim issue or a flaw in the newly introduced BDAT feature?
The "postscreen" service intentionally does not support ESMTP PIPELINING:
posttls-finger "[mail-cbf-ext.charite.de]"
posttls-finger: Connected to mail-cbf-ext.charite.de[193.175.73.208]:25
posttls-finger: < 220-mail-cbf.charite.de ESMTP Postfix
posttls-finger: < 220 mail-cbf.charite.de ESMTP Postfix
posttls-finger: > EHLO amnesiac
posttls-finger: < 250-mail-cbf.charite.de
posttls-finger: < 250-SIZE 36700160
posttls-finger: < 250-ETRN
posttls-finger: < 250-STARTTLS
posttls-finger: < 250-ENHANCEDSTATUSCODES
posttls-finger: < 250 8BITMIME
posttls-finger: > STARTTLS
posttls-finger: < 220 2.0.0 Ready to start TLS
[...]
posttls-finger: Untrusted TLS connection established to
mail-cbf-ext.charite.de[193.175.73.208]:25: TLSv1.2 with cipher
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
posttls-finger: > EHLO amnesiac
posttls-finger: < 250-mail-cbf.charite.de
posttls-finger: < 250-SIZE 36700160
posttls-finger: < 250-ETRN
posttls-finger: < 250-ENHANCEDSTATUSCODES
posttls-finger: < 250 8BITMIME
posttls-finger: > QUIT
posttls-finger: < 221 2.0.0 Bye
The postscreen source code reads in part:
static int psc_bdat_cmd(PSC_STATE *state, char *args)
{
const char *myname = "psc_bdat_cmd";
/*
* smtpd(8) incompatibility: postscreen(8) drops the connection, instead
* of reading the entire BDAT chunk and staying in sync with the client.
* Justification: postscreen(8) should never see BDAT from a legitimate
* client, because 1) the server rejects every recipient, and 2) the
* server does not announce PIPELINING.
*/
...
So I would expect that the BDAT command should not have been sent by the
client. Given that it was sent, Postfix should arguably not report the
subsequent message a pipelining violation, but surely the BDAT command
itself is a violation of the same kind...
--
Viktor.
