On Fri, Oct 06, 2017 at 04:22:38PM +0200, Florian Coulmier wrote:
> > That looks wrong. Where is the first EHLO response line? The above
> > starts in the middle of the response.
There's the smoking gun. Wietse correctly observes the crucial
detail that the first line of the EHLO response (after which follow
the ESMTP options), which ought to lookup like:
250-<server-hostname> <decorative vanity text>
is missing.
> 7 0.096519 Y.Y.Y.Y -> X.X.X.X SMTP 156 S: 250 SIZE 12582912 | 250 DSN |
> 250 ENHANCEDSTATUSCODES | 250 AUTH NTLM | 250 8BITMIME | 250 OK
>
> 0000 00 50 56 9b 64 b4 00 50 56 9b 30 58 08 00 45 00 .PV.d..PV.0X..E.
> 0010 00 8e 1e da 40 00 37 06 fb ca d5 29 8e 67 ac 11 ....@.7....).g..
> 0020 19 23 00 19 fc 26 f3 55 0e 57 8b 00 b0 b3 80 18 .#...&.U.W......
The hex dump reveals the actual IPs: 213.41.142.103 -> 172.17.25.35
$ getent hosts 213.41.142.103
213.41.142.103 mail.provenceplats.fr
Which suggests that your end (on an RFC1918 IP address of 172.17.25.35)
is behind a NAT firewall, which could part of the problem. The
SMTP server however does not seem to be reachable from Internet at
large, so the networking topology here is unclear.
> 0030 04 02 25 56 00 00 01 01 08 0a 8b eb 30 0d 51 41 ..%V........0.QA
> 0040 c6 84 32 35 30 2d 53 49 5a 45 20 31 32 35 38 32 ..250-SIZE 12582
> 0050 39 31 32 0d 0a 32 35 30 2d 44 53 4e 0d 0a 32 35 912..250-DSN..25
> 0060 30 2d 45 4e 48 41 4e 43 45 44 53 54 41 54 55 53 0-ENHANCEDSTATUS
> 0070 43 4f 44 45 53 0d 0a 32 35 30 2d 41 55 54 48 20 CODES..250-AUTH
> 0080 4e 54 4c 4d 0d 0a 32 35 30 2d 38 42 49 54 4d 49 NTLM..250-8BITMI
> 0090 4d 45 0d 0a 32 35 30 20 4f 4b 0d 0a ME..250 OK..
There we have it, the EHLO response omits the first vanity line,
and so SIZE becomes the vanity line, and is ignored.
> 8 0.096737 X.X.X.X -> Y.Y.Y.Y SMTP 103 C: MAIL
> FROM:<isabelle.a...@gmail.com>
This is a correct response when the server does not announce
"SIZE", which is the case here.
> 10642 15.362688 X.X.X.X -> Y.Y.Y.Y SMTP 2642 C: DATA fragment, 2576 bytes
> 10643 15.363923 Y.Y.Y.Y -> X.X.X.X SMTP 90 S: 552 Data size exceeded
This response must follow ".", and the server must not switch back
to command-mode until that happens. Just hanging up can cause
problems. Mind you, when the connection is lost mid-transfer,
Postfix will attempt to read any pending premature response
from the server (since Postfix 2.4, 11 years ago):
https://github.com/vdukhovni/postfix/blame/master/postfix/src/smtp/smtp_proto.c#L2176
if (!LOST_CONNECTION_INSIDE_DATA)
RETURN(smtp_stream_except(state, except,
"sending message body"));
/*
* We will clear the stream error flag to try and read a
* premature 5XX response, so it is important to flush any
* unwritten data. Otherwise, we will try to flush it again
* before reading, which may incur an unnecessary delay and
* will prevent the reading of any response that is not
* already buffered (bundled with the DATA 354 response).
*
* Not much point in sending QUIT at this point, skip right to
* SMTP_STATE_LAST. The read engine above will likewise avoid
* looking for a QUIT response.
*/
(void) vstream_fpurge(session->stream, VSTREAM_PURGE_WRITE);
next_state = SMTP_STATE_LAST;
perhaps your kernel fails deliver that final packe to the Postfix
smtp(8) client due do the preceding connection reset on write, in
which case there's not much Postfix can do. We don't currently
peek inbound data from the server while writing the message data,
the SMTP protocol is half-duplex...
--
Viktor.
