Re: Postfix doesn't respect 250-SIZE value

[Florian Coulmier]

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

Indeed, only our servers are able to reach this MX. This is the normal 
behavior. 

> There we have it, the EHLO response omits the first vanity line,
> and so SIZE becomes the vanity line, and is ignored.

This is it! Thanks for the information, I was not aware of this RFC subtlety. 
We’ll reach out to the owner of the MX to see if he can change this behavior.

> 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):

Another RFC breach that we will notify to the postmaster.


Many thanks for the time you all spent on this issue. Your help was precious on 
this one.

Florian

Re: Postfix doesn't respect 250-SIZE value

[Florian Coulmier]

> That looks wrong. Where is the first EHLO response line? The above 
> starts in the middle of the response.
>
> Can you share a packed dump OFF-LIST so I can see what happens between
> SENDING ehlo and receiving the reply? The entire TCP connection would 
> be best.

Yes, I extracted only the interesting part. The full dump is here (server with 
IP X.X.X.X is mine. Server with IP Y.Y.Y.Y is remote MX):

1   0.00 X.X.X.X -> Y.Y.Y.Y TCP 74 64550 → 25 [SYN] Seq=0 Win=29200 Len=0 
MSS=1460 SACK_PERM=1 TSval=1363265141 TSecr=0 WS=128

  00 50 56 9b 30 58 00 50 56 9b 64 b4 08 00 45 00   .PV.0X.PV.d...E.
0010  00 3c 76 fb 40 00 40 06 9a fb ac 11 19 23 d5 29   . X.X.X.X TCP 74 25 → 64550 [SYN, ACK] Seq=0 Ack=1 
Win=65535 Len=0 MSS=1300 WS=64 SACK_PERM=1 TSval=2347446220 TSecr=1363265141

  00 50 56 9b 64 b4 00 50 56 9b 30 58 08 00 45 00   .PV.d..PV.0X..E.
0010  00 3c 1e d3 40 00 37 06 fc 23 d5 29 8e 67 ac 11   .<..@.7..#.).g..
0020  19 23 00 19 fc 26 f3 55 0e 44 8b 00 b0 8f a0 12   .#...&.U.D..
0030  ff ff 12 f3 00 00 02 04 05 14 01 03 03 06 04 02   
0040  08 0a 8b eb 2f cc 51 41 c6 75 /.QA.u

  3   0.030695 X.X.X.X -> Y.Y.Y.Y TCP 66 64550 → 25 [ACK] Seq=1 Ack=1 Win=29312 
Len=0 TSval=1363265148 TSecr=2347446220

  00 50 56 9b 30 58 00 50 56 9b 64 b4 08 00 45 00   .PV.0X.PV.d...E.
0010  00 34 76 fc 40 00 40 06 9b 02 ac 11 19 23 d5 29   .4v.@.@..#.)
0020  8e 67 fc 26 00 19 8b 00 b0 8f f3 55 0e 45 80 10   .g.&...U.E..
0030  00 e5 28 ec 00 00 01 01 08 0a 51 41 c6 7c 8b eb   ..(...QA.|..
0040  2f cc /.

  4   0.063290 Y.Y.Y.Y -> X.X.X.X SMTP 84 S: 220 SMTP Welcome

  00 50 56 9b 64 b4 00 50 56 9b 30 58 08 00 45 00   .PV.d..PV.0X..E.
0010  00 46 1e d7 40 00 37 06 fc 15 d5 29 8e 67 ac 11   .F..@.7).g..
0020  19 23 00 19 fc 26 f3 55 0e 45 8b 00 b0 8f 80 18   .#...&.U.E..
0030  04 02 cf 47 00 00 01 01 08 0a 8b eb 2f ed 51 41   ...G/.QA
0040  c6 7c 32 32 30 20 53 4d 54 50 20 57 65 6c 63 6f   .|220 SMTP Welco
0050  6d 65 0d 0a   me..

  5   0.063310 X.X.X.X -> Y.Y.Y.Y TCP 66 64550 → 25 [ACK] Seq=1 Ack=19 
Win=29312 Len=0 TSval=1363265156 TSecr=2347446253

  00 50 56 9b 30 58 00 50 56 9b 64 b4 08 00 45 00   .PV.0X.PV.d...E.
0010  00 34 76 fd 40 00 40 06 9b 01 ac 11 19 23 d5 29   .4v.@.@..#.)
0020  8e 67 fc 26 00 19 8b 00 b0 8f f3 55 0e 57 80 10   .g.&...U.W..
0030  00 e5 28 ec 00 00 01 01 08 0a 51 41 c6 84 8b eb   ..(...QA
0040  2f ed /.

  6   0.063357 X.X.X.X -> Y.Y.Y.Y SMTP 102 C: EHLO mx02-out.cloud.vadesecure.com

  00 50 56 9b 30 58 00 50 56 9b 64 b4 08 00 45 00   .PV.0X.PV.d...E.
0010  00 58 76 fe 40 00 40 06 9a dc ac 11 19 23 d5 29   .Xv.@.@..#.)
0020  8e 67 fc 26 00 19 8b 00 b0 8f f3 55 0e 57 80 18   .g.&...U.W..
0030  00 e5 29 10 00 00 01 01 08 0a 51 41 c6 84 8b eb   ..)...QA
0040  2f ed XX XX XX XX 20 XX XX XX XX 2d XX XX XX 2e   /.EHLO -xxx.
0050  XX XX XX XX XX 2e XX XX XX XX XX XX XX XX XX XX   x.xx
0060  2e 63 6f 6d 0d 0a .com..

  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

  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..
0030  04 02 25 56 00 00 01 01 08 0a 8b eb 30 0d 51 41   ..%V0.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..

  8   0.096737 X.X.X.X -> Y.Y.Y.Y SMTP 103 C: MAIL 
FROM:

  00 50 56 9b 30 58 00 50 56 9b 64 b4 08 00 45 00   .PV.0X.PV.d...E.
0010  00 59 76 ff 40 00 40 06 9a da ac 11 19 23 d5 29   .Yv.@.@..#.)
0020  8e 67 fc 26 00 19 8b 00 b0 b3 f3 55 0e b1 80 18   .g.&...U
0030  00 e5 29 11 00 00 01 01 08 0a 51 41 c6 8d 8b eb   ..)...QA
0040  30 0d 4d 41 49 4c 20 46 52 4f 4d 3a 3c XX XX XX   0.MAIL FROM:..

  9   0.128714 Y.Y.Y.Y -> X.X.X.X SMTP 87 S: 250 2.1.0 Sender OK

  00 50 56 9b 64 b4 00 50 56 9b 30 58 08 00 45 00   .PV.d..PV.0X..E.
0010  00 49 1e df 40 00 37 06 fc 0a d5 29 8e 67 ac 11   .I..@.7).g..

Re: Postfix doesn't respect 250-SIZE value

[Florian Coulmier]

>> Here is my configuration: https://pastebin.com/EKHvEveC

> postconf -n
> would be more appropriate, I think

 Here it is : https://pastebin.com/efFJb2Sq

Re: Postfix doesn't respect 250-SIZE value

[Florian Coulmier]

> You really should not make up facts out of thin air, however popular that
> might be these days.  Support for sending "SIZE=" in Postfix is at least
> 19 years old, with the MIME downgrade suppressing dating back 11 years.

> 
https://github.com/vdukhovni/postfix/blame/master/postfix/src/smtp/smtp_proto.c#L1466

Ok, my bad. I mixed up with UTF8 support. So, 8BITMIME should be supported with 
my postfix version.

>> Too bad… I’ll see if I can upgrade.

> Waste of time, why don't you post your config as requested.  Also, make 
sure
> that any network captures you are looking at or post are taken directly
> from your Postfix machine, and not on the other side of some too-clever
> firewall.

I’ve performed my network capture on the server running postfix itself.
Here is my configuration: https://pastebin.com/EKHvEveC

Regards

Re: Postfix doesn't respect 250-SIZE value

[Florian Coulmier]

>Postfix sends "SIZE=" in "MAIL FROM" unless it is going to do 8bit to 7bit
>downgrade:
>(source code removed)

>So it would appear (if your reported transcript is accurate) that
>Postfix did not believe the peer to be 8BITMIME-capable.  Since
>the SMTP server's EHLO reply does in fact include 8BITMIME, I can
>only conclude that you have some sort of filter in place on the
>EHLO keywords or server reply.

As said to Matus Uhlar, I think this is because I’m using postfix 2.11 and the 
8BITMIME support has been introduced in version 3.0.
Too bad… I’ll see if I can upgrade.

Re: Postfix doesn't respect 250-SIZE value

[Florian Coulmier]

>are you sure postfix sees exactly this conversation?
>I don't see the SIZE= parameter in MAIL FROM: 

Correct me if I’m wrong, but I think this is because I use version 2.11 of 
postfix and this feature has been introduced in version 3.0.

Re: Postfix doesn't respect 250-SIZE value

[Florian Coulmier]

>Postfix stores size information in the queue file.  What size does the
>queue manager log fot this specific message?

Here are the information in queue file, as shown by a “postcat –q” on the 
message queue ID :

*** ENVELOPE RECORDS deferred/3/2/A/32A559F491 ***
message_size:13870598 816   1   0   
 13870598
message_arrival_time: Fri Oct  6 10:12:35 2017
create_time: Fri Oct  6 10:12:35 2017

(note this is a deferent message than from my last email, but the problem is 
the same).


>Right. This suggests that either the size information in the queue file is
>wrong, or that the SIZE announcement was malformed (i.e. buggy SMTP 
> server).
>This requires a packet-level dump to see if there are stray 
> carriage-returns
>or other unexpected content in thhe EHLO response.

I have done such network capture. Here is the hex-dump of the server response 
after EHLO command (as displayed by tshark):

  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..
0030  04 02 25 56 00 00 01 01 08 0a 8b eb 30 0d 51 41   ..%V0.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..


>The server is buggy. SMTP does not allow servers to respond until
>the client sends end-of-data.

That’s what I thought too. I don’t know what they are using, but it’s not 
postfix for sure ;-)