On Jun 24, 2014, at 19.35, Wietse Venema <wie...@porcupine.org> wrote:
> btb: >> Jun 24 11:20:21 mta postfix/postscreen[5758]: CONNECT from >> [173.201.193.182]:45771 to [10.3.70.5]:25 >> Jun 24 11:20:21 mta postfix/postscreen[5758]: PASS OLD >> [173.201.193.182]:45771 >> Jun 24 11:20:21 mta postfix/smtpd[7066]: connect from >> p3plsmtp18-01-2.prod.phx3.secureserver.net[173.201.193.182] >> Jun 24 11:20:21 mta postfix/smtpd[7066]: NOQUEUE: reject: MAIL from >> p3plsmtp18-01-2.prod.phx3.secureserver.net[173.201.193.182]: 552 5.3.4 >> Message size exceeds fixed limit; proto=ESMTP >> helo=<p3plwbeout18-01.prod.phx3.secureserver.net> >> Jun 24 11:21:21 mta postfix/smtpd[7066]: disconnect from >> p3plsmtp18-01-2.prod.phx3.secureserver.net[173.201.193.182] >> >> can this event be correlated with the envelope sender and recipient[s]? >> it would be a helpful detail in the process of associating reports >> from end users with this event. > > There is no sender and there is no recipient. Postfix rejects the > MAIL FROM command. thanks for this. i wrongly assumed this event occurred after message_size_limit bytes had been transmitted. i’ve read rfc 1870 and i think i better understand this now. iiuc, given that the client supplies SIZE=N as a parameter to MAIL FROM, while rejected, is the attempted sender at least potentially known, and could perhaps be logged? in that same vein, thinking about the spirit of smtpd_delay_reject - while i understand rejecting mail based on size is not an smtpd_*_restriction, could the same logic/rationale be applied - to allow postfix to log those additional details? > In fact, a smart client would have hung up before even sending the > MAIL FROM command. Postfix announces the SIZE limit in the EHLO > response. All you'd see in the logfile are a connect and disconnect. yes, it sadly seems uninterested in the announced SIZE limit. it seems ironic now too, given that it’s using the MAIL FROM SIZE parameter. i noticed the 60 second delay before disconnecting, after it’s rejected, and wondered if the not so smart client is left confused when the rejection occurs prior to RCPT TO, and if honoring smtpd_delay_reject might be helpful in encouraging it to not sit idle, as the documentation alludes to. of course, it could just be connection caching? i can test some more and see if that client’s behavior differs when rejected after RCPT TO, which i guess would answer that question. making some assumptions about the validity of my above comments, could i propose a setting to allow size rejections to wait until after RCPT TO? i think the documentation might look like this: smtpd_delay_size_reject (default: no) Wait until the RCPT TO command before enforcing $message_size_limit. This feature is turned off by default for backwards compatibility. Like $smtpd_delay_reject turning on this setting has one major benefit: it allows Postfix to log recipient address information when rejecting a client name/address or sender address, so that it is possible to find out whose mail is being rejected. -ben
