Hi Bill,
Shameful admission : I didn't realise that a sending machine using EHLO
could declare the message size in the 'Mail from:'.
I have been able to replicate the log behaviour using Telnet using an
example in RFC1870.
After issuing a EHLO command;
>> mail from: <t...@domain.uk> SIZE=234567895
<< 452 4.3.4 Message size exceeds fixed limit
Log ;
...
Jun 21 11:23:17 skin P25/smtpd[28880]: connect from
localhost.localdomain[127.0.0.1]
Jun 21 11:24:10 skin P25/smtpd[28880]: NOQUEUE: reject: MAIL from
localhost.localdomain[127.0.0.1]: 452 4.3.4 Message size exceeds fixed
limit; proto=ESMTP helo=<esec.uk>
Jun 21 11:24:19 skin P25/smtpd[28880]: disconnect from
localhost.localdomain[127.0.0.1] ehlo=1 mail=0/1 quit=1 commands=2/3
...
It is a shame Postfix doesn't log the mail from: or data size offered,
but seeing as that is this field the message fails on I understand why.
The log entry makes sense now I understand what's going on. Thank you
very much for your explanation and also for pointing me to RCF1870.
Best wishes,
Mick.
On 21/06/2016 03:52, Bill Cole wrote:
On 20 Jun 2016, at 20:54, Mick wrote:
I take it from your response (and noting the log 'reject: MAIL from')
that the sender just piled in over 10MB of data at the 'mail from:'
stage.
Unlikely, since it was a Google machine and that's not how size
restriction works. In this case the session summary implies that the
sender was pipelining commands: not waiting for or parsing replies all
the way through, just stopping after DATA to figure out whether it
could send message data and finding that it could not. It was the MAIL
command that Postfix rejected first and after that point there's no
reason for Postfix to pay attention to the specifics of later
pipelined commands.
See RFC1870 for the specifics but the simple explanation of how size
limits work before DATA is that the server announces its maximum size
in a EHLO reply along with other extensions like PIPELINING and the
client announces the size it intends to send as an extra argument to
the MAIL command. In this case it looks like the sender ignored what
your server said was its limit, announced it would send more, and
Postfix said no to MAIL while the sender kept on going all the way to
DATA. Most clients respect the size limit in the EHLO reply and don't
try MAIL with a larger size but it looks like Google's software takes
RFC2920 (the pipelining extension) quite literally, immediately starts
pipelining commands when it reads the PIPELINING line in the EHLO
reply and not waiting for the "SIZE=[$message_size_limit]"
advertisement of your size limit a few lines later. I don't believe
I've seen any other SMTP sender behave quite that way but I suppose
Google probably has data supporting that behavior as more efficient
than waiting for the whole EHLO reply and parsing it. That yields a
strange set of log entries, but the more common approach would log
nearly nothing when a legitimate sender has an oversize message for
you: just a connect line and a disconnect line with just "ehlo=1
quit=1 commands=2" describing what the client did.
