Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: message_size_limit causes postfix to stop delivering messages
33 views
Skip to first unread message
Ralf Hildebrandt
Feb 4, 2012, 1:20:52 PM2/4/12
to
* Nick Bright <nick....@valnet.net>:
> Upon restarting postfix with message_size_limit in place it simply
> wouldn't deliver any mail. It accepts the mail in to SMTP just fine,
> but it never gets delivered.
Logs?
> No mail appears to be lost, and no errors appear in the maillog while
> message_size_limit is in effect, but the message doesn't pass to my
> anti-spam daemon via content_filter.
It could be that theanti-spam daemon announces a LOWER size limit in
the EHLO greeting:
$ telnet postamt 25
Trying 141.42.206.36...
Connected to postamt.charite.de.
Escape character is '^]'.
220 postamt.charite.de ESMTP Postfix
EHLO foo
250-postamt.charite.de
250-PIPELINING
250-SIZE 262144000
^^^^^^^^^
and thus Postfix won't even try to send
> When I remove the message_size_limit parameter from main.cf and
> reload postfix, all mail that was not delivered does get delivered -
> including messages with attachments larger than 10MB.
That makes no sense, since the limit is
$ postconf -d message_size_limit
message_size_limit = 10240000
Show postconf -n output and your master.cf
--
Ralf Hildebrandt
Geschäftsbereich IT | Abteilung Netzwerk
Charité - Universitätsmedizin Berlin
Campus Benjamin Franklin
Hindenburgdamm 30 | D-12203 Berlin
Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
ralf.hil...@charite.de | http://www.charite.de
> Upon restarting postfix with message_size_limit in place it simply
> wouldn't deliver any mail. It accepts the mail in to SMTP just fine,
> but it never gets delivered.
Logs?
> No mail appears to be lost, and no errors appear in the maillog while
> message_size_limit is in effect, but the message doesn't pass to my
> anti-spam daemon via content_filter.
It could be that theanti-spam daemon announces a LOWER size limit in
the EHLO greeting:
$ telnet postamt 25
Trying 141.42.206.36...
Connected to postamt.charite.de.
Escape character is '^]'.
220 postamt.charite.de ESMTP Postfix
EHLO foo
250-postamt.charite.de
250-PIPELINING
250-SIZE 262144000
^^^^^^^^^
and thus Postfix won't even try to send
> When I remove the message_size_limit parameter from main.cf and
> reload postfix, all mail that was not delivered does get delivered -
> including messages with attachments larger than 10MB.
That makes no sense, since the limit is
$ postconf -d message_size_limit
message_size_limit = 10240000
Show postconf -n output and your master.cf
--
Ralf Hildebrandt
Geschäftsbereich IT | Abteilung Netzwerk
Charité - Universitätsmedizin Berlin
Campus Benjamin Franklin
Hindenburgdamm 30 | D-12203 Berlin
Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
ralf.hil...@charite.de | http://www.charite.de
Wietse Venema
Feb 4, 2012, 2:03:46 PM2/4/12
to
Nick Bright:
> Greetings,
>
> I'm having some trouble with my Postfix configuration, the default limit
> of 10MB for messages is causing many of my end users to complain that
> the limit is far too small. To increase this value per the documentation
> at http://www.postfix.org/postconf.5.html#message_size_limit I added
> "message_size_limit = 209715200" (200MB) to my main.cf file, as this
> should be large enough to functionally not be a limit (I did try much
> smaller values as well, such as 20MB - all with the same results).
> Greetings,
>
> I'm having some trouble with my Postfix configuration, the default limit
> of 10MB for messages is causing many of my end users to complain that
> the limit is far too small. To increase this value per the documentation
> at http://www.postfix.org/postconf.5.html#message_size_limit I added
> "message_size_limit = 209715200" (200MB) to my main.cf file, as this
> should be large enough to functionally not be a limit (I did try much
> smaller values as well, such as 20MB - all with the same results).
>
> Upon restarting postfix with message_size_limit in place it simply
> wouldn't deliver any mail. It accepts the mail in to SMTP just fine, but
> it never gets delivered.
http://www.postfix.org/DEBUG_README.html#logging
> Upon restarting postfix with message_size_limit in place it simply
> wouldn't deliver any mail. It accepts the mail in to SMTP just fine, but
> it never gets delivered.
Wietse Venema
Feb 5, 2012, 8:31:52 PM2/5/12
to
Nick Bright:
> On 2/4/2012 12:20 PM, Ralf Hildebrandt wrote:
> > * Nick Bright<nick....@valnet.net>:
> >
>
> There are no log entries other than normal entries reflecting that the
> messages have been accepted for delivery, though per another posters'
> recommendation; I will enable debug logging and give it another look. I
> also installed postfix-perl-utils and will examine which queue the
> messages are piling up in with pfHandle during my next test.
Postfix logs all attempts to deliver mail, whether
or not successful.
Please do not turn on debug logging, it will just make
the problem harder to diagnose.
You probably have a bug in the VDA patch that breaks
when the message size limit exceeds the mailbox size
limit. Their code does not handle that correctly.
Wietse
> On 2/4/2012 12:20 PM, Ralf Hildebrandt wrote:
> > * Nick Bright<nick....@valnet.net>:
> >
> >> Upon restarting postfix with message_size_limit in place it simply
> >> wouldn't deliver any mail. It accepts the mail in to SMTP just fine,
> >> but it never gets delivered.
> >
> > Logs?
> >> Upon restarting postfix with message_size_limit in place it simply
> >> wouldn't deliver any mail. It accepts the mail in to SMTP just fine,
> >> but it never gets delivered.
> >
> >
>
> There are no log entries other than normal entries reflecting that the
> messages have been accepted for delivery, though per another posters'
> recommendation; I will enable debug logging and give it another look. I
> also installed postfix-perl-utils and will examine which queue the
> messages are piling up in with pfHandle during my next test.
Postfix logs all attempts to deliver mail, whether
or not successful.
Please do not turn on debug logging, it will just make
the problem harder to diagnose.
You probably have a bug in the VDA patch that breaks
when the message size limit exceeds the mailbox size
limit. Their code does not handle that correctly.
Wietse
Tomas Macek
Feb 6, 2012, 2:44:31 AM2/6/12
to
If the patched virtual
agent gets from the queue the message, that exceeds the mailbox size
limit, it can only bounce or drop the message. It does something else? Or
what's bad?
Tomas
Ralf Hildebrandt
Feb 6, 2012, 3:19:00 AM2/6/12
to
> There are no log entries other than normal entries reflecting that
> the messages have been accepted for delivery, though per another
> posters' recommendation; I will enable debug logging and give it
> another look.
Please don't.
> the messages have been accepted for delivery, though per another
> posters' recommendation; I will enable debug logging and give it
> another look.
> Also, the content filter doesn't announce a SIZE:
>
> $ telnet localhost 10025
> Trying ::1...
> Connected to localhost.
> Escape character is '^]'.
> 220 mppd
You forgot to issue the EHLO command - only after this command the
filter might announce the SIZE extension.
Or rather LHLO (since mppscan seems to speak lmtp):
> mppscan unix - - n - 50 lmtp
> -o lmtp_send_xforward_command=yes
> -o lmtp_cache_connection=no
> content_filter = mppscan:[127.0.0.1]:10025
It's a very odd setup, since only locally submitted mail (sendmail
command) gets filtered. Mail coming in via smtp is explicitly not sent
to the filter:
smtp inet n - n - 200 smtpd
-o content_filter=
submission inet n - n - 200 smtpd
-o content_filter=
smtps inet n - n - 200 smtpd
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
-o milter_macro_daemon_name=ORIGINATING
-o content_filter=
in all three cases we see "content_filter=" - disabled.
Some of these are down:
> smtpd_client_restrictions = permit_mynetworks, reject_rbl_client
> bl.spamcop.net, reject_rbl_client sbl-xbl.spamhaus.org,
> reject_rbl_client cbl.abuseat.org, reject_rbl_client
> zombie.dnsbl.sorbs.net, reject_rbl_client http.dnsbl.sorbs.net,
> reject_rbl_client misc.dnsbl.sorbs.net, reject_rbl_client
> socks.dnsbl.sorbs.net, reject_rbl_client web.dnsbl.sorbs.net,
> reject_rbl_client ddnsbl.internetdefensesystems.com, reject_rbl_client
> multi.surbl.org, reject_rbl_client noptr.spamrats.com,
> permit_sasl_authenticated, reject_rbl_client dyna.spamrats.com,
> reject_rbl_client pbl.spamhaus.org, reject_rbl_client
> dul.dnsbl.sorbs.net, check_policy_service inet:127.0.0.1:9998
> message_size_limit = 209715200
That's 200MB.
Wietse Venema
Feb 6, 2012, 7:01:11 AM2/6/12
to
Tomas Macek:
Unpatched Postfix forbids this, but they removed that check.
This breaks, among others, mail submitted with "sendmail -t", and
mail that has recipients added with the Milter protocol. Postfix
can't mark the recipient as "done".
I have added a safety check for that that will abort the program
when this sanity check fails. But it does not help when people
can't read logfiles.
Wietse
> > Postfix logs all attempts to deliver mail, whether
> > or not successful.
> >
> > Please do not turn on debug logging, it will just make
> > the problem harder to diagnose.
> >
> > You probably have a bug in the VDA patch that breaks
> > when the message size limit exceeds the mailbox size
> > limit. Their code does not handle that correctly.
>
> > or not successful.
> >
> > Please do not turn on debug logging, it will just make
> > the problem harder to diagnose.
> >
> > You probably have a bug in the VDA patch that breaks
> > when the message size limit exceeds the mailbox size
> > limit. Their code does not handle that correctly.
>
> What should be a proper behaviour in this case?
The patch should not allow message size limit > mailbox size limit.
Unpatched Postfix forbids this, but they removed that check.
This breaks, among others, mail submitted with "sendmail -t", and
mail that has recipients added with the Milter protocol. Postfix
can't mark the recipient as "done".
I have added a safety check for that that will abort the program
when this sanity check fails. But it does not help when people
can't read logfiles.
Wietse
Wietse Venema
Feb 6, 2012, 3:17:04 PM2/6/12
to
Nick Bright:
> reading http://www.postfix.org/postconf.5.html#mailbox_size_limit
> correctly, that parameter only effects local delivery; not virtual.
I should have written: virtual_mailbox_limit.
I suggest that you look for Postfix panic, fatal, error or warning
messages as per these instructions:
http://www.postfix.org/DEBUG_README.html#logging
LOOK FOR OBVIOUS SIGNS OF TROUBLE
=================================
Postfix logs all failed and successful deliveries to a logfile. The
file is usually called /var/log/maillog or /var/log/mail; the exact
pathname is defined in the /etc/syslog.conf file.
When Postfix does not receive or deliver mail, the first order of
business is to look for errors that prevent Postfix from working
properly:
% egrep '(warning|error|fatal|panic):' /some/log/file | more
Note: the most important message is near the BEGINNING of the output.
Error messages that come later are less useful.
The nature of each problem is indicated as follows:
* "panic" indicates a problem in the software itself that only
a programmer can fix. Postfix cannot proceed until this is
fixed.
* "fatal" is the result of missing files, incorrect permissions,
incorrect configuration file settings that you can fix. Postfix
cannot proceed until this is fixed.
* "error" reports an error condition. For safety reasons, a
Postfix process will terminate when more than 13 of these
happen.
* "warning" indicates a non-fatal error. These are problems
that you may not be able to fix (such as a broken DNS server
elsewhere on the network) but may also indicate local
configuration errors that could become a problem later.
When no mail is delivered, the logfile will tell you why.
Wietse
> > The patch should not allow message size limit> mailbox size limit.
> > Unpatched Postfix forbids this, but they removed that check.
> >
>
> In this case, mailbox_size_limit shouldn't come in to play. If I'm
> > Unpatched Postfix forbids this, but they removed that check.
> >
>
> reading http://www.postfix.org/postconf.5.html#mailbox_size_limit
> correctly, that parameter only effects local delivery; not virtual.
I should have written: virtual_mailbox_limit.
I suggest that you look for Postfix panic, fatal, error or warning
messages as per these instructions:
http://www.postfix.org/DEBUG_README.html#logging
LOOK FOR OBVIOUS SIGNS OF TROUBLE
=================================
Postfix logs all failed and successful deliveries to a logfile. The
file is usually called /var/log/maillog or /var/log/mail; the exact
pathname is defined in the /etc/syslog.conf file.
When Postfix does not receive or deliver mail, the first order of
business is to look for errors that prevent Postfix from working
properly:
% egrep '(warning|error|fatal|panic):' /some/log/file | more
Note: the most important message is near the BEGINNING of the output.
Error messages that come later are less useful.
The nature of each problem is indicated as follows:
* "panic" indicates a problem in the software itself that only
a programmer can fix. Postfix cannot proceed until this is
fixed.
* "fatal" is the result of missing files, incorrect permissions,
incorrect configuration file settings that you can fix. Postfix
cannot proceed until this is fixed.
* "error" reports an error condition. For safety reasons, a
Postfix process will terminate when more than 13 of these
happen.
* "warning" indicates a non-fatal error. These are problems
that you may not be able to fix (such as a broken DNS server
elsewhere on the network) but may also indicate local
configuration errors that could become a problem later.
When no mail is delivered, the logfile will tell you why.
Wietse
0 new messages