Scott Kitterman:
> Thanks. I don't think it's worth a lot of effort. I'd imagine it's a pretty
> niche use case to send multi-gigabyte files via SMTP. People do do it though
> (clearly or there wouldn't be a bug).
>
> I wrestled with a few options for a simple explanation, but didn't come up
On Thursday, December 23, 2021 3:51:57 PM EST Wietse Venema wrote:
> Scott Kitterman:
> > Currently, postconf.5 has this to say about message_size_limit:
> >
> > message_size_limit (default: 1024)
> >
> > The maximal size in bytes of a message, including envelope
> > information.
> >
Scott Kitterman:
> Currently, postconf.5 has this to say about message_size_limit:
>
> message_size_limit (default: 1024)
>
> The maximal size in bytes of a message, including envelope information.
>
> Note: be careful when making changes. Excessively small values will result
> in the l
W. Michael Petullo:
> The OpenWrt patch hard codes fsspace("/overlay", &fsbuf), because
> OpenWrt installations often make use of an overlay filesystems, mounted at
> "/overlay". This makes sense in some cases, but obviously not when the
> mail queue exists on a big, separate disk.
Lesson learned:
>>> If in doubt, RTFM?
>>>
>>> queue_minfree (default: 0)
>>>The minimal amount of free space in bytes in the queue file system
>>> that
>>>is needed to receive mail. This is currently used by the Postfix
>>> SMTP
>>>server to decide if it will accept any mail at all.
>
W. Michael Petullo:
> > If in doubt, RTFM?
> >
> > queue_minfree (default: 0)
> >The minimal amount of free space in bytes in the queue file system
> > that
> >is needed to receive mail. This is currently used by the Postfix
> > SMTP
> >server to decide if it will accep
> On Sep 10, 2019, at 4:46 PM, W. Michael Petullo wrote:
>
> However, it seems that the capacity of my root mount has some bearing
> on the evaluation of Postfix's message_size_limit and queue_minfree. I
> am getting "insufficient system storage" errors despite having enough
> space in /mnt/xvdb.
>> My mail spool is not on my root directory:
>>
>> data_directory = /mnt/xvdb/var/lib/postfix
>> mail_spool_directory = /mnt/xvdb/var/spool/mail
>> queue_directory = /mnt/xvdb/var/spool/postfix
>> virtual_mailbox_base = /mnt/xvdb/var/spool/mail
>>
>> However, it seems that the capacity of my roo
W. Michael Petullo:
> My mail spool is not on my root directory:
>
> data_directory = /mnt/xvdb/var/lib/postfix
> mail_spool_directory = /mnt/xvdb/var/spool/mail
> queue_directory = /mnt/xvdb/var/spool/postfix
> virtual_mailbox_base = /mnt/xvdb/var/spool/mail
>
> However, it seems that the capaci
Bastien Durel:
> Hello, I have 2 questions about message_size_limit :
> - is there a value meaning "unlimited ?"
Since when do computers have unlimited disk space?
> - can it be configured with a table, so it may differ from account to
> account ?
You can enforce sender or recipient-dependent l
thank You all :)
30 mar 2017 21:47 "Viktor Dukhovni" napisał(a):
>
> > On Mar 30, 2017, at 12:35 PM, Zalezny Niezalezny <
> zalezny.niezale...@gmail.com> wrote:
> >
> > # postconf -d | grep message
>
> The "postconf -d" command returns compiled-in defaults.
> For your actual settings, try "p
> On Mar 30, 2017, at 12:35 PM, Zalezny Niezalezny
> wrote:
>
> # postconf -d | grep message
The "postconf -d" command returns compiled-in defaults.
For your actual settings, try "postconf", either with
no options or as "postconf -n" for just non-default
settings. See postconf(1) for details.
postconf -c /path/to/config/dir message_size_limit
ix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org]
On Behalf Of Wietse Venema
Sent: Friday, October 30, 2015 5:04 AM
To: Postfix users
Subject: Re: message_size_limit versus prepended header
martijn.list:
[ Charset windows-1252 converted... ]
> On 10/30/2015 12:56 PM, Jeroen Scheerd
martijn.list:
[ Charset windows-1252 converted... ]
> On 10/30/2015 12:56 PM, Jeroen Scheerder wrote:
> > Quoth Jeroen Scheerder (30 Oct 2015, 12:46):
> >
> >> That would result in a
> >>
> >> 250-SIZE 1024
> >>
> >> helo message, *and* a true size limit of 10239918.
> >
> > I obviously omi
On 10/30/2015 12:56 PM, Jeroen Scheerder wrote:
> Quoth Jeroen Scheerder (30 Oct 2015, 12:46):
>
>> That would result in a
>>
>> 250-SIZE 1024
>>
>> helo message, *and* a true size limit of 10239918.
>
> I obviously omitted the evident edit. I had meant to write:
>
> "That would result in
martijn.list:
> > This got me thinking. Would it be possible to have
> >
> > message_size_limit = 1024
> >
> > but have my smtps/submission services announce slightly less:
> >
> > 250-SIZE 10239918
>
> I think you can override the message size limit for the submission port
> in ma
On 10/30/2015 10:04 AM, Jeroen Scheerder wrote:
> L.S.,
>
> I ran into a little something. I have separated my main smtp service
> (tcp/25) and smtps/submission services (tcp/465, tcp/587).
> The smtps/submission services have a few extra virtual aliases, but they also
> (don't ask) add a heade
>> Is message_size_limit still valid? All of the references I can find
>> to it online are very old. Is there another postfix directive I
>> should use to set the maximum upload size for roundcube?
>
> Postfix configuration parameters don't capriciously disappear. If
> they are obsoleted, they b
On Thu, Feb 13, 2014 at 05:58:20PM -0800, Grant wrote:
> Is message_size_limit still valid? All of the references I can find
> to it online are very old. Is there another postfix directive I
> should use to set the maximum upload size for roundcube?
Postfix configuration parameters don't capric
On 2/13/2014 7:58 PM, Grant wrote:
> Is message_size_limit still valid? All of the references I can find
> to it online are very old. Is there another postfix directive I
> should use to set the maximum upload size for roundcube?
>
> - Grant
>
Yes, it's still valid. That feature hasn't change
On 06 Dec 2013, at 17:21 , Jose Borges Ferreira wrote:
> I've setup a Postfix like this, having on the submission port a bigger
> value than the message_size_limit specified in main.cf
>
> main.cf
> message_size_limit = 1000
>
> master.cf
> smtp inet n - n - -
Jose Borges Ferreira:
> Hi!
>
> I've setup a Postfix like this, having on the submission port a bigger
> value than the message_size_limit specified in main.cf
>
> main.cf
> message_size_limit = 1000
>
> master.cf
> smtp inet n - n - - smtpd
> submission inet n
On 06 Jun 2013, at 06:40 , Raphael Bauduin wrote:
> Hi,
>
> I have message_size_limit set at the default value:
> # postconf | grep message_size_limit
> message_size_limit = 1024
>
> I create a file to attach by:
> # dd if=/dev/urandom of=/tmp/75 bs=1024 count=7500
>
> and then try to sen
On Thu, Jun 6, 2013 at 2:54 PM, Geoff Shang wrote:
> On Thu, 6 Jun 2013, Raphael Bauduin wrote:
>
> Why is there a 2Mb+ difference between the message_size_limit value and
>> the
>> attachment size accepted? (I don't think the envelope can take 2Mb...)
>>
>
> It doesn't. But an encoded attachme
On Thu, 6 Jun 2013, Raphael Bauduin wrote:
Why is there a 2Mb+ difference between the message_size_limit value and the
attachment size accepted? (I don't think the envelope can take 2Mb...)
It doesn't. But an encoded attachment does take up quite a deal more
space than the original file (it
It's true I don't have your experience as you are the postfix coders.
But it's also true you don't know what can be my expericence.
Considering your political answers since the beginning, embarassing for who?
You're right that's enough. I'm going to answer you in private.
Envoyé de mon iPad
Le
> sorry, but after following the thread you are not qualified
> enough to judge design-patterns of a software you do not
> understand enough
I agree totally on that. That's why I write in the users mailing list, not in
the developpers mailing list.
To stop this thread that is borring for everybo
You're right that's enough and I'll answer you in private.
Wietse Venema a écrit :
> Nicolas HAHN:
>> The "archietcture" is not a good excuse for me, I'm sorry. As a
>> coder, allowing a software to start despite the fact there is a
>> FATAL is a total non-sens. And saying finally that is just a
Am 24.04.2013 19:45, schrieb Nicolas HAHN:
> The "archietcture" is not a good excuse for me, I'm sorry. As a coder
well, that's the difference between "coder" and "delevoper"
a "coder" writes something which works for now and every
few years all is thrown away because the architecture
and softw
Nicolas HAHN:
> The "archietcture" is not a good excuse for me, I'm sorry. As a
> coder, allowing a software to start despite the fact there is a
> FATAL is a total non-sens. And saying finally that is just a daemon
> which will not run but the others will, I really don't know how
> to take it...
On Wed, Apr 24, 2013 at 07:45:52PM +0200, Nicolas HAHN wrote:
> The "archietcture" is not a good excuse for me, I'm sorry.
You don't yet known enough about Postfix to appreciate the answer,
this is not your fault, but the design is fine.
--
Viktor.
The "archietcture" is not a good excuse for me, I'm sorry. As a coder, allowing
a software to start despite the fact there is a FATAL is a total non-sens. And
saying finally that is just a daemon which will not run but the others will, I
really don't know how to take it...
And you can daemonize
On Wed, Apr 24, 2013 at 05:23:09PM +0200, Nicolas HAHN wrote:
> > Can you post the fatal error messages you found, especially the
> > messages that log why the queue manager was restarting, as that
> > is the real problem.
>
> Here is what I found:
>
> 2013-04-24T10:04:38.005665+00:00 iccpfxor04
Yea. Thanks, i've seen it the first time you posted it.
But that's not for this reason I'll change my mind about this.
BR.
nicolas
Wietse Venema a écrit :
> Nicolas HAHN:
>> What I consider just abnormal as already written is that for me
>> (so it's my opinion), Postfix should refuse to start
Nicolas HAHN:
> What I consider just abnormal as already written is that for me
> (so it's my opinion), Postfix should refuse to start when it detects
> a fatal about a configuration issue in the config files. But it
> starts any way and display each minute the fatal in the log file.
If you think
> Can you post the fatal error messages you found, especially the
> messages that log why the queue manager was restarting, as that
> is the real problem.
Here is what I found:
2013-04-24T10:04:38.005665+00:00 iccpfxor04 postfix/local[9370]: fatal: main.cf
configuration error: mailbox_size_limit
On Wed, Apr 24, 2013 at 04:47:26PM +0200, Nicolas HAHN wrote:
> This is a reply to myself because I'm reviewing the way it works.
>
> > Yes, but if I'm right, the log message is emitted at the time there
> > is an e-mail processed (by postfix/local for my issue).
>
> In fact, the fatal is writt
This is a reply to myself because I'm reviewing the way it works.
> Yes, but if I'm right, the log message is emitted at the time there
> is an e-mail processed (by postfix/local for my issue).
In fact, the fatal is written in the logs each minute and 1 second for this
issue in my case by the
Nicolas HAHN:
> Yes, but if I'm right, the log message is emitted at the time there
> is an e-mail processed (by postfix/local for my issue).
>
> What I'm speaking about there is that postfix should check the
> configuration for this issue (for example) at the time it is started
> or its configura
This story also makes me think, suddenly, that I should integrate in my Log
Search Tool a feature allowing real time fatal error catching (and not only
fatal) form postfix logs and real time alerting of the users using the tool in
case a fatal comes during e-mail procesing. Will see that for ver
Yes, but if I'm right, the log message is emitted at the time there is an
e-mail processed (by postfix/local for my issue).
What I'm speaking about there is that postfix should check the configuration
for this issue (for example) at the time it is started or its configuration is
reloaded, and R
Nicolas HAHN:
> Postfix feature request: that would be nice that Postfix be able
> to do this kind of basic checks by itself when starting (or when
> configuration is reloaded) between various inter-dependent
> configuration settings, and display in the logs at least some
> warnings when such kind
> 1. Don't send bounces to postmaster, just generate and read log summaries
> that may highlight aggregate problems with your mail stream.
>
> notify_classes =
>
> This applies to any MTA handing mail for a large number of users,
> it is fine to have postmaster notices for a ma
On Wed, Apr 24, 2013 at 03:37:17PM +0200, Nicolas HAHN wrote:
> > More likely you have a mailbox size limit smaller than the message
> > size limit.
>
> Yes, that's the reason. I completely forgot to check the matching
> between both settings.
>
> The mailbox size limit was set to its default va
> More likely you have a mailbox size limit smaller than the message
> size limit.
Yes, that's the reason. I completely forgot to check the matching between both
settings.
The mailbox size limit was set to its default value of 50 Mb. After setting it
to 150 Mb, the issue was fixed.
Note: the b
Nicolas HAHN:
Content-Description: Version texte brut du message
[ Charset ISO-8859-1 unsupported, converting... ]
> OK.
>
> I did some tries and it seems that I cannot go above 40 Mb for
> message_size_limit to avoid the issue.
>
> As you wrote, here below is a set of log lines during the issu
On Wed, Apr 24, 2013 at 03:22:14PM +0200, Nicolas HAHN wrote:
> 2013-04-24T12:32:01.442962+00:00 iccpfxor04 postfix/qmgr[24391]: 6B34360BAA:
> from=, size=8389, nrcpt=1 (queue
> active)
> 2013-04-24T12:36:09.981198+00:00 iccpfxor04 postfix/qmgr[27126]: 6B34360BAA:
> from=, size=8389, nrcpt=1 (q
> Postfix memory usage does not depend on message size. Far more
> likely some filter has message size issues, or perhaps mailbox_size_limit
> has not been raised to match, or the OP failed to reload Postfix, so that
> the message size limit was different in some processes.
Each time I've reloade
Am 24.04.2013 15:22, schrieb Nicolas HAHN:
> As you wrote, here below is a set of log lines during the issue. The emails
> staying in the growing active queue are
> the bounce messages (we intercept them to send a copy to postmaster):
>
> [root@iccpfxor04 postfix]# grep 6B34360BAA /var/log/mail
OK.
I did some tries and it seems that I cannot go above 40 Mb for
message_size_limit to avoid the issue.
As you wrote, here below is a set of log lines during the issue. The emails
staying in the growing active queue are the bounce messages (we intercept them
to send a copy to postmaster):
[
Nicolas HAHN:
> I've modified message_size_limit from 20 Mb to 120 Mb this morning.
> I know that's not something to do and we explained to the customer
> a messaging system wasn't in any case a file transfer service...
> But after, politic came in and blablabla...
>
> And immediately after this ch
On Wed, Apr 24, 2013 at 03:07:05PM +0200, Reindl Harald wrote:
> Am 24.04.2013 14:58, schrieb Nicolas HAHN:
> > Does somebody knows what is happening?
>
> no because you missed to send any log-information
Definitely.
> maybe to less memory to proceed messages with 150 MB
Postfix memory usage
Am 24.04.2013 14:58, schrieb Nicolas HAHN:
> Does somebody knows what is happening?
no because you missed to send any log-information
maybe to less memory to proceed messages with 150 MB
signature.asc
Description: OpenPGP digital signature
On 2/6/2012 2:17 PM, Wietse Venema wrote:
Nick Bright:
The patch should not allow message size limit> mailbox size limit.
Unpatched Postfix forbids this, but they removed that check.
I should have written: virtual_mailbox_limit.
virtual_mailbox_limit isn't defined; but I am using a
virtual
On 2/6/2012 2:19 AM, Ralf Hildebrandt wrote:
Also, the content filter doesn't announce a SIZE:
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):
Oops!
$ telnet localhost 10025
Try
Nick Bright:
> > 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
> reading http://www.postfix.org/postconf.5.html#mailbox_size_limit
> c
On 2/6/2012 6:01 AM, Wietse Venema wrote:
Tomas Macek:
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.
That seems highly plausible.
What should be a proper behaviour in this case?
T
Tomas Macek:
> > 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 mail
> 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.
> Also, the content filter doesn't announce a SIZE:
>
> $ telne
On Sun, 5 Feb 2012, Wietse Venema wrote:
Nick Bright:
On 2/4/2012 12:20 PM, Ralf Hildebrandt wrote:
* Nick Bright:
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?
T
Nick Bright:
> On 2/4/2012 12:20 PM, Ralf Hildebrandt wrote:
> > * Nick Bright:
> >
> >> 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?
> >
>
> There are no
On 2/4/2012 12:20 PM, Ralf Hildebrandt wrote:
* Nick Bright:
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?
There are no log entries other than normal entries reflect
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#m
* Nick Bright :
> 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 effe
On 1/16/11 6:33 PM, James wrote:
I set message_size_limit = 0 in main.conf and postfix started ok but I
wasn't getting mail so I read the docs.
It said mailbox_size_limit must be larger than message_size_limit so I
set it to It said
mailbox_size_limit = 0 and I got mail. :-)
The goal was to be
On Thu, April 1, 2010 1:31 am, Noel Jones wrote:
> On 3/31/2010 6:37 AM, Voytek Eymont wrote:
> "no limit" is usually a bad choice; unexpected things can happen.
> Better choices include
> - set virtual_mailbox_limit to some large value you don't ever
> expect to exceed, maybe 10x ~ 100x the mes
On Wed, Mar 31, 2010 at 09:31:29AM -0500, Noel Jones wrote:
> Better choices include
> - set virtual_mailbox_limit to some large value you don't ever expect to
> exceed, maybe 10x ~ 100x the message_size_limit.
> - set "virtual_mailbox_limit = $message_size_limit" so that changes to
> message_si
On 3/31/2010 6:37 AM, Voytek Eymont wrote:
I currently have in main.cf like:
message_size_limit = 1024
and
virtual_mailbox_limit = 1024
so, if I want to increase it, I need also increase virtual_mailbox_limit
to at least same as message_size_limit
can I just use message_size_limit = va
On Thu, Jun 11, 2009 at 04:08:16PM +0200, Simon Schelkshorn wrote:
> Hi,
>
> thanks for your fast reply.
>
> @Truth Seeker: I added the message_size_limit statement to the
> definition in master.cf as I intended to increase the message size
> only for mail sent from my local users and not for
Hi,
thanks for your fast reply.
@Truth Seeker: I added the message_size_limit statement to the
definition in master.cf as I intended to increase the message size
only for mail sent from my local users and not for all messages.
> > > You can't change the size limit for the SMTP server alone.
>
Magnus B?ck:
> On Tuesday, June 09, 2009 at 19:37 CEST,
> Wietse Venema wrote:
>
> > Simon Schelkshorn:
> >
> > > I added a second listener in my master.cf. For this listener I added
> > > the option message_size_limit=2048 to increase the maximum size
> > > for emails sent via this addi
On Tuesday, June 09, 2009 at 19:37 CEST,
Wietse Venema wrote:
> Simon Schelkshorn:
>
> > I added a second listener in my master.cf. For this listener I added
> > the option message_size_limit=2048 to increase the maximum size
> > for emails sent via this additional listener.
>
> You can
Simon Schelkshorn:
> Hi there,
>
> I added a second listener in my master.cf. For this listener I added
> the option message_size_limit=2048 to increase the maximum size
> for emails sent via this additional listener.
You can't change the size limit for the SMTP server alone.
It must be a m
i feel like you have to add the following in main.cf (not in master.cf)
message_size_limit = 2048
for me this is working fine... and have the same size limit
-
--
---
Always try to find truth!!!
-
--- On Tue, 6/9/09, Simon Schelkshorn wrote:
> From: Simon Schelkshorn
> Subject: mes
On Wed, May 27, 2009 at 12:35:28AM -0700, Trigve Siver wrote:
>
> Hi,
>
> > From: mouss
>
> > what you could do is run a script that
> > - checks the message size. if it's too large, store it somewhere for review
> > - else, run sendmail
> >
> > in any case, don't bounce without some sort of
Hi,
> From: mouss
> what you could do is run a script that
> - checks the message size. if it's too large, store it somewhere for review
> - else, run sendmail
>
> in any case, don't bounce without some sort of verification (some
> anti-spam checks or a manual review).
>
> If you are willing
Trigve Siver a écrit :
> Hi,
> thanks for reply
>
>> This is suspicious. sendmail doesn't return an error to getmail, so
>> getmail should think the message was processed. in short, there should
>> be no "next round".
>
> As you can see in getmail configuration getmail is calling sendmail. AFAIK
On 5/26/2009, Trigve Siver (trig...@yahoo.com) wrote:
> Yes but my ISP will accept also big messages and I don't want to
> process messages bigger than 10 MB for instance. Yes the backscatter
> could be problem
Actually, imho, backscatter should not be that big of a problem here...
I don't think I
Hi,
> I'm pretty sure I've seen qmail do exactly this... :-p Some variation
> of its default "accept, then bounce" methodology...
Yes something like this would be great, accept and bounce if message is too big.
> --
> Corey Chandler / KB1JWQ
> Living Legend / Systems Exorcist
> Today's Ex
Hi,
thanks for reply
> This is suspicious. sendmail doesn't return an error to getmail, so
> getmail should think the message was processed. in short, there should
> be no "next round".
As you can see in getmail configuration getmail is calling sendmail. AFAIK if
postfix reject the mail (becaus
* Corey Chandler :
> Wietse Venema wrote:
>>
>> No MTA, including Postfix, sends bounce messages for mail that it
>> does not accept.
>>
>> Wietse
>>
> I'm pretty sure I've seen qmail do exactly this... :-p Some variation of
> its default "accept, then bounce" methodology...
In that case
Wietse Venema wrote:
No MTA, including Postfix, sends bounce messages for mail that it
does not accept.
Wietse
I'm pretty sure I've seen qmail do exactly this... :-p Some variation
of its default "accept, then bounce" methodology...
--
Corey Chandler / KB1JWQ
Living Legend / Syst
Trigve:
> May 23 00:00:52 mailwork postfix/sendmail[73012]: fatal: [MAIL OMITTED](5003):
> message file too big
No MTA, including Postfix, sends bounce messages for mail that it
does not accept.
Wietse
Trigve a écrit :
> Hi,
> I'm using getmail (using cron) for fetching the mails (from the ISP server)
> and
> then letting postfix to manage them. In postfix I have set
> "message_size_limit"
> to 10 MB. So when getmail retrieve the message (that is bigger than 10 MB)
> and
> send it to postfix
85 matches
Mail list logo
