On 8/27/23 20:50, Viktor Dukhovni via Postfix-users wrote:
I am told that Comcast have raised the limits somewhat, and it should no
longer be necessary to set the recipient limit to 1. I expect you
should now be able to get away with something more reasonable, like 10
or worst-case 5, unless you
On Sun, Aug 27, 2023 at 02:33:49PM -0400, Viktor Dukhovni via Postfix-users
wrote:
> I hope that Comcast will relax their limits to allow at least 2 (ideally
> closer to 5 or 10) recipients per message so long as the sending system
> does not have a "known bad" reputation.
I am told that Comcast
On Sun, Aug 27, 2023 at 11:12:03AM -0700, Bill Sommerfeld via Postfix-users
wrote:
> On 8/27/23 00:13, Wietse Venema via Postfix-users wrote:
> > Would it be sufficient to never send more than 1 recipient per
> > mesage, thus never trigger their temporary "block all mail" strategy,
> > and avoid
Thanks for your prompt responses.
On 8/27/23 00:13, Wietse Venema via Postfix-users wrote:
Would it be sufficient to never send more than 1 recipient per
mesage, thus never trigger their temporary "block all mail" strategy,
and avoid the need for the kludges described here?
That's unclear. I'
On Sun, Aug 27, 2023 at 03:13:43AM -0400, Wietse Venema via Postfix-users wrote:
> Bill Sommerfeld via Postfix-users:
> > About three years ago there was a thread on postfix-users ("Comcast 421
> > throttling multiple recipients") discussing a low-traffic site having
&g
Wietse Venema via Postfix-users:
> Bill Sommerfeld via Postfix-users:
> > About three years ago there was a thread on postfix-users ("Comcast 421
> > throttling multiple recipients") discussing a low-traffic site having
> > difficulties sending to multiple recipie
Bill Sommerfeld via Postfix-users:
> About three years ago there was a thread on postfix-users ("Comcast 421
> throttling multiple recipients") discussing a low-traffic site having
> difficulties sending to multiple recipients at comcast in a single smtp
> session.
About three years ago there was a thread on postfix-users ("Comcast 421
throttling multiple recipients") discussing a low-traffic site having
difficulties sending to multiple recipients at comcast in a single smtp
session. The thread starts here:
https://www.mail-archive.com/pos
Great ideas guys -- Thanks! Greg
www.RayStedman.org
On Mon, Mar 29, 2021 at 7:26 AM Richard James Salts
wrote:
> On Monday, 29 March 2021 9:34:13 AM AEDT Wietse Venema wrote:
> ...
> > Third, look with mtr at the latency pattern. If part of your traffic
> > goes over a satellite, of if it is tu
On Monday, 29 March 2021 9:34:13 AM AEDT Wietse Venema wrote:
...
> Third, look with mtr at the latency pattern. If part of your traffic
> goes over a satellite, of if it is tunneled to some far-away country,
> then you will see a big jump. Unfortunately, mtr does not support
> tcp so you can't do
On Sun, Mar 28, 2021 at 01:30:49PM -0700, Greg Sims wrote:
> The second group started at 01:00. The send rate changed from 500
> emails sent per minute to 15 emails per minute. We are still
> delivering this email as I type this.
Have you looked at the distribution of the "c/d" values in the
"d
Greg Sims:
> Hi There,
>
> We have been running Postfix successfully for months now. We sent an
> email to two subscriber groups last night. We monitor the number of
> emails we send per minute with the following report:
>
>00:30541564601655633498376342
>
Hi There,
We have been running Postfix successfully for months now. We sent an
email to two subscriber groups last night. We monitor the number of
emails we send per minute with the following report:
00:30541564601655633498376342
615498
00:40
; combro2k combro2k:
> >> Hi there,
> >>
> >> I've been looking for some days for a solution I need to create for a
> >> customer.
> >> What we want to achieve is throttling the delivery of mails in the
> queue.
> >> Right now we are using
>
>> I've been looking for some days for a solution I need to create for a
>> customer.
>> What we want to achieve is throttling the delivery of mails in the queue.
>> Right now we are using 'default_destination_rate_delay = 1s' which allows
>> us to sen
combro2k combro2k:
> Hi there,
>
> I've been looking for some days for a solution I need to create for a
> customer.
> What we want to achieve is throttling the delivery of mails in the queue.
> Right now we are using 'default_destination_rate_delay = 1s' which al
On 1/27/2021 8:02 AM, combro2k combro2k wrote:
Hi there,
I've been looking for some days for a solution I need to create for
a customer.
What we want to achieve is throttling the delivery of mails in the
queue.
Right now we are using 'default_destination_rate_delay = 1s' whic
Hi there,
I've been looking for some days for a solution I need to create for a
customer.
What we want to achieve is throttling the delivery of mails in the queue.
Right now we are using 'default_destination_rate_delay = 1s' which allows
us to send approx. 3600 to each destinati
Viktor Dukhovni wrote:
> Bob Proulx wrote:
> > > > ... http://postmaster.comcast.net/smtp-error-codes.php#RL01 (in
> > > > reply to MAIL FROM command))
> > >
> > > Look carefully at the log entry. The "421" is send in response to "MAIL
> > > FROM", not "RCPT TO". So the recipient limit does
On Thu, Sep 24, 2020 at 02:06:05PM -0600, Bob Proulx wrote:
> > > ... http://postmaster.comcast.net/smtp-error-codes.php#RL01 (in reply
> > > to MAIL FROM command))
> >
> > Look carefully at the log entry. The "421" is send in response to "MAIL
> > FROM", not "RCPT TO". So the recipient li
>But then how do we configure Postfix to do this automatically so that
>we can gain enough reputation to send more than one recipient at a
>time? Because Comcast is not rejecting all mail. Comcast is only
>rejecting mail with multiple recipients. Comcast is accepting mail
>with single recipients
Viktor Dukhovni wrote:
> Bob Proulx wrote:
> > ... http://postmaster.comcast.net/smtp-error-codes.php#RL01 (in reply
> > to MAIL FROM command))
>
> Look carefully at the log entry. The "421" is send in response to "MAIL
> FROM", not "RCPT TO". So the recipient limit does not look entirely
>
On Thu, Sep 24, 2020 at 12:59:44AM -0600, Bob Proulx wrote:
> Question about a different system. Pretty much every question of mine
> is related to a different oddball case. Here I am helping a friend
> out and they encountered this problem. I'll change the 3rd party
> addresses so as not to an
Question about a different system. Pretty much every question of mine
is related to a different oddball case. Here I am helping a friend
out and they encountered this problem. I'll change the 3rd party
addresses so as not to annoy them but the data is otherwise
verbatim.
Sep 23 14:38:23 yuk
On 17 Jun 2020, at 11:07, Roberto Ragusa wrote:
> but when I start contacting them they easily complain with "too many
> concurrent connections" because all the mx hosts have been resolved to the
> same IP (well, IP pool, actually). These domains (not under my control) are
> hosted on a provide
Roberto Ragusa:
> Hi,
>
> is there a way to throttle outgoing SMTP by destination IP?
No. The Postfix scheduler does not know about IP addresses. That
is a very fundamental property of the design. It schedules deliveries
in parallel, based on domain names.
Otherwise, if DNS lookups for one domai
Hi,
is there a way to throttle outgoing SMTP by destination IP?
My problem is that I send mails to
- domain1.com
- domain2.com
- domain3.com
which handle mails through
- mx.domain1.com
- mx.domain2.com
- mx.domain3.com
but when I start contacting them they easily complain with
"too many concurre
wing message:
>>
>> Apr 15 20:51:57 mail postfix/master[67497]: warning: process
>> /usr/local/libexec/postfix/smtp pid 67505 killed by signal 11
>> Apr 15 20:51:57 mail postfix/master[67497]: warning:
>> /usr/local/libexec/postfix/smtp: bad command startup -- throt
> /usr/local/libexec/postfix/smtp pid 67505 killed by signal 11
> Apr 15 20:51:57 mail postfix/master[67497]: warning:
> /usr/local/libexec/postfix/smtp: bad command startup -- throttling
One of the various debugging options gives you an interactive debugger
session in a "screen&quo
/master[67497]: warning:
/usr/local/libexec/postfix/smtp: bad command startup -- throttling
Is there a process to debug this? Searching online for this error it looks like
it’s mostly for SMTPD, not SMTP. My incoming Postfix SMTPD works fine for
receiving mail, using Dovecot SASL. For the SMTP
On Fri, Aug 31, 2018 at 06:16:01PM +, Fazzina, Angelo wrote:
> Hi, I was able to run a packet capture with tcpdump on the 3 load balanced
> servers that handle massmail.uconn.edu during the users mail merge today.
> It was looking like one email every 12 seconds
The main thing you're looking
ass Mailing
G Suite/Gmail
ang...@uconn.edu
University of Connecticut, ITS, SSG, Server Systems
860-486-9075
-Original Message-
From: owner-postfix-us...@postfix.org On
Behalf Of Viktor Dukhovni
Sent: Wednesday, August 29, 2018 2:09 PM
To: Postfix users
Subject: Re: Want to be sure i a
> On Aug 30, 2018, at 6:46 AM, Matus UHLAR - fantomas wrote:
>
> what's in /etc/postfix/header_checks?
Nothing relevant.
--
Viktor.
On 28.08.18 17:47, Fazzina, Angelo wrote:
Aug 28 10:22:27 mail5 postfix/smtpd[7534]: EE46E2FB:
client=unknown[137.99.149.148], sasl_method=LOGIN, sasl_username=wellness
Some user feedback :
On Friday I sent a batch of 436 and it took 11
minutes to send
> On Aug 29, 2018, at 1:53 PM, Fazzina, Angelo wrote:
>
> [root@mail4 log]# cat maillog-20180829 |grep 137.99.149.148 |grep -v
> disconnect |grep -v submission|grep connect
You forgot to aggregate:
$ ... | awk '{print $3}' | sed -e 's/.:..$/0/' | uniq -c
15 09:20
28 09:30
30 09:40
nd Virus Prevention
Mass Mailing
G Suite/Gmail
ang...@uconn.edu
University of Connecticut, ITS, SSG, Server Systems
860-486-9075
-Original Message-
From: owner-postfix-us...@postfix.org On
Behalf Of Viktor Dukhovni
Sent: Wednesday, August 29, 2018 1:00 PM
To: Postfix users
Subject: Re:
> On Aug 29, 2018, at 12:19 PM, Fazzina, Angelo
> wrote:
>
> In answer to: "I get a quick NXDOMAIN. Is that also true for your mail
> server?"
> Yes i get the same results when i do a "dig -x 137.99.149.148" or
> "nslookup 137.99.149.148"
Are you doing the test on the MTA, or a near
-ANGELO FAZZINA
ITS Service Manager:
Spam and Virus Prevention
Mass Mailing
G Suite/Gmail
ang...@uconn.edu
University of Connecticut, ITS, SSG, Server Systems
860-486-9075
-Original Message-
From: owner-postfix-us...@postfix.org On
Behalf Of Wietse Venema
Sent: Wednesday, August 29, 20
Viktor Dukhovni:
> > 09:22:43 mail4 postfix/smtpd[16278]: connect from unknown[137.99.149.148]
> > 09:22:45 mail4 postfix/smtpd[16278]: disconnect from unknown[137.99.149.148]
> >
> > 09:23:06 mail4 postfix/smtpd[16278]: connect from unknown[137.99.149.148]
> > 09:23:08 mail4 postfix/smtpd[16278]:
> On Aug 29, 2018, at 10:55 AM, Fazzina, Angelo
> wrote:
>
> Hi, Thank you for the bread crumbs. After looking at my logs I do see
> differences in the "delay"
> from 0.72 to 2.2 seconds to send an email.
The time that it takes your server to deliver each message to its destination
nexthop
-us...@postfix.org On
Behalf Of Viktor Dukhovni
Sent: Tuesday, August 28, 2018 2:39 PM
To: Postfix users
Subject: Re: Want to be sure i am not throttling user.
> On Aug 28, 2018, at 1:47 PM, Fazzina, Angelo wrote:
>
> Hi, i am troubleshooting a client complaint.
> This user “w
> On Aug 28, 2018, at 1:47 PM, Fazzina, Angelo wrote:
>
> Hi, i am troubleshooting a client complaint.
> This user “wellness”
>
> Aug 28 10:22:27 mail5 postfix/smtpd[7534]: EE46E2FB:
> client=unknown[137.99.149.148], sasl_method=LOGIN, sasl_username=wellness
>
> Some user feedback :
>
Hi, i am troubleshooting a client complaint.
This user "wellness"
Aug 28 10:22:27 mail5 postfix/smtpd[7534]: EE46E2FB:
client=unknown[137.99.149.148], sasl_method=LOGIN, sasl_username=wellness
Some user feedback :
On Friday I sent a batch of 436 and it took 11
mi
On 11 Sep 2017, at 10:24, /dev/rob0 wrote:
>
Surely ?
(runs)
--
Apple broke AppleScripting signatures in Mail.app, so no random signatures.
> > > Is there anything more you could do? Not really. If you really
> > > want the log lines to go away you could put in a DENY in your
> > > hosts table, but if you do that you're going to be doing it A
> > > LOT.
I wanted to know if these were overloading Postfix. Sounds like a no.
Also so
On Mon, Sep 11, 2017 at 10:50:56AM -0400, Kris Deugau wrote:
> @lbutlr wrote:
> > Is there anything more you could do? Not really. If you really
> > want the log lines to go away you could put in a DENY in your
> > hosts table, but if you do that you're going to be doing it A
> > LOT.
Note that
@lbutlr wrote:
Is there anything more you could do? Not really. If you really want the log
lines to go away you could put in a DENY in your hosts table, but if you do
that you're going to be doing it A LOT.
*nod* If there's only one persistent host, it may be worth blocking at
some higher l
On 09 Sep 2017, at 11:19, yodel...@yepmail.net wrote:
> I'm just wondering if there's any throttling or something else to here?
This is only a "problem" because you are looking at it.
Yes, there are lots of log lines, but all they show is that this person is
being kept
oing its "best" job here at reducing load? It's clearly not
> passing the attempts through.
So, postscreen is doing its job.
> I'm just wondering if there's any throttling or something else to here?
Why bother? It's doing exactly what it was meant to do
x27;s clearly not
passing the attempts through.
I'm just wondering if there's any throttling or something else to here?
Sep 6 03:22:20 cont03 postfix/postscreen[35432]: CONNECT from
[62.210.140.7]:53039 to [192.0.2.1]:25
Sep 6 03:22:20 cont03 postfix/dnsblog[354
On 01.09.2017 14:09, Matus UHLAR - fantomas wrote:
On 01.09.17 10:37, Admin Beckspaced wrote:
but let's say I do a fail2ban restart on one of the servers lots of
fail2ban notify emails will get send via the relayhost
resulting in the relayhost throttling down the other server
whi
On 01.09.17 10:37, Admin Beckspaced wrote:
but let's say I do a fail2ban restart on one of the servers lots of
fail2ban notify emails will get send via the relayhost
resulting in the relayhost throttling down the other server
which is actually not a big thing as the mails stay in the queu
f the servers lots of
fail2ban notify emails will get send via the relayhost
resulting in the relayhost throttling down the other server
which is actually not a big thing as the mails stay in the queue for a
bit and get send later.
But is there an option in postfix to say: no worries! trust
ood idea to put some limits or throttling 'just in case' ?
Yes, it is always a good idea to have message send limits 'just in case'.
I use policyd2 and give users the ability to send 200 messages per hour
and 500 messages per 24 hours. 99.9% of my users are okay with those
lim
I have a small server with several domains, always worry some dumb users'
account will get hacked and start spamming (including this dumb user,
like, my own forgotten test account got hacked)
is it a good idea to put some limits or throttling 'just in case' ?
Postfix 2.11,
Neil Tiffin:
> Feb 4 15:17:03 fairwindsoft2 postfix/smtp[6671]: auto_clnt_create:
> transport=local endpoint=private/scache
There is no need for verbose logging, the noise drowns out the
useful information.
> Feb 4 15:17:03 fairwindsoft2 postfix/smtp[6671]: fatal: event_enable_read:
> epoll_c
postfix/master[1693]: warning: process
/usr/libexec/postfix/smtp pid 6671 exit status 1
Feb 4 15:17:04 fairwindsoft2 postfix/master[1693]: warning:
/usr/libexec/postfix/smtp: bad command startup — throttling
Configuration:
[root@fairwindsoft2 ~]# postconf -n
alias_database = hash:/etc/aliases
Hi,
You might want to 'replace' the postfix sendmail command with
mini_sendmail or something alike, and have that actually forward to
localhost:25 using SMTP. Then you can apply throttling on the localhost
ip, but lose the ability to see which local user was the source.
Tom
On 11-1
On 2015-11-10 23:42, Donald Bindner wrote:
smtpd_recipient_restrictions = check_policy_service
inet:127.0.0.1:10040
You may want to use a different restriction than recipient.
The recipient restrictions are executed for every recipient.
It gets executed multiple times if the mail has more than
On Tue, Nov 10, 2015 at 04:42:32PM -0600, Donald Bindner wrote:
> smtpd_recipient_restrictions = check_policy_service inet:127.0.0.1:10040
>
> However, this kind of rule seems to run only for mail "passing
> through" my Postfix server and not for mail originating locally. In
> any event, the ser
On 11/11/2015 11:42 AM, Donald Bindner wrote:
> smtpd_recipient_restrictions = check_policy_service inet:127.0.0.1:10040
>
> However, this kind of rule seems to run only for mail "passing
> through" my Postfix server and not for mail originating locally. In
> any event, the service running on por
ov 10, 2015 at 6:04 PM, Ken Simpson wrote:
> Hi Donald,
>
> Chances are, the problem you're trying to solve (throttling users) is
> actually a symptom of the larger problem of runaway spamming accounts. Am I
> right? In this case, throttling users with policyd and a relatively
Hi Donald,
Chances are, the problem you're trying to solve (throttling users) is
actually a symptom of the larger problem of runaway spamming accounts. Am I
right? In this case, throttling users with policyd and a relatively
straightforward policyd script is a good option to stem the ble
Yes, the point of my email is that I researched and tried to apply
exactly this configuration, but it did not work. The
smtpd_recipient_restrictions rule they suggest does not appear to
apply to messages that originate on the server. Or at least making
that single configuration does not have that
And this.
http://serverfault.com/questions/290684/postfix-limiting-the-rate-at-which-a-particular-user-can-send-email
--Curtis
On 11/10/2015 5:42 PM, Donald Bindner wrote:
I've been searching for some time, and what I want seems to be fairly
obscure, because I haven't found clear examples of i
Hello,
I found this link that might be helpful.
http://steam.io/2013/04/01/postfix-rate-limiting/
Cheers,
Curtis
On 11/10/2015 5:42 PM, Donald Bindner wrote:
I've been searching for some time, and what I want seems to be fairly
obscure, because I haven't found clear examples of it (at least I
I've been searching for some time, and what I want seems to be fairly
obscure, because I haven't found clear examples of it (at least I
don't think I have).
I run an Ubuntu server with user accounts, and we use a limited amount
of email on it, which we process with Postfix. On occasion, a user
wi
Adam Roses Wight:
> I've started writing this feature to determine whether it's feasible
> with the current architecture, but no success yet, this doesn't seem
> to limit the number of jobs which are popped from the queue:
I just had to find out why it did not work (While it is possible
to impleme
On 06/21/2015 05:31 PM, Adam Roses Wight wrote:
Thanks for the feedback! Slowing down the SMTP delivery agent sure was easy...
there are a few things to clean up, but the patch below seems to be giving the
behavior I need.
Have a look at the following,
http://wiki.policyd.org/features#quotas
On Sat, Jun 20, 2015 at 07:18:34PM +, Viktor Dukhovni wrote:
> If there is to be a global rate delay, the transport process limit
> might as well be equal to 1. At which point to implement a rate
> delay, it suffices for each delivery to take a minimum amount of
> time, so an option along the
Adam Roses Wight:
> Attaching my WIP patch here...
>
> On Sat, Jun 20, 2015 at 04:37:11PM +, Adam Roses Wight wrote:
> > Many hosting providers limit the number of outbound SMTP connections over
> > time, and exceeding their threshold results in harsh consequences like
> > dropped connections
On Sat, Jun 20, 2015 at 04:48:24PM +, Adam Roses Wight wrote:
> Attaching my WIP patch here...
>
> On Sat, Jun 20, 2015 at 04:37:11PM +, Adam Roses Wight wrote:
> > Many hosting providers limit the number of outbound SMTP connections over
> > time, and exceeding their threshold results in
it the number of jobs which are popped from the queue:
>
> https://github.com/vdukhovni/postfix/compare/master...adamwight:rate_delay
>
> Thanks,
> Adam
commit 78f288daaf74a721c21b3a8e0846469843164be9
Author: Adam Roses Wight
Date: Tue Jun 16 09:31:17 2015 -0700
WIP Implemen
Marco,
> Is there a way to share this kind of information between Postfix instances?
> I would really if you could share your personal experience on how to deal in
> general with a scenario like this.
I've been using policyd for this, with a single MySQL backend. You can create a
policy to matc
Hi Wietse,
On Wed, Feb 18, 2015 at 1:23 PM, Wietse Venema wrote:
> Marco Pizzoli:
>
> > Is there a way to share this kind of information between Postfix
> instances?
>
> This is not implemented. Postfix by design can recover from a crash
> in any program except the master daemon. I don't know h
Marco Pizzoli:
> Hi all,
> I have a battery of postfix servers used for sending bulk emails to the
> Internet.
> All of them are seen from the outside as they were one:
> - same hostname
> - same public IP address
>
> Considered that I have implemented the sending
Hi all,
I have a battery of postfix servers used for sending bulk emails to the
Internet.
All of them are seen from the outside as they were one:
- same hostname
- same public IP address
Considered that I have implemented the sending throttling for specific
destinations in order to avoid "s
Erik Gr?tnes:
> If I understand correct, I need to let all servers that should be
> able to send mail out be part of mynetworks. Is that correct? The
> problem is that when the servers are part of mynetworks, all the
> throttling and antispam check stops - it is just trusted...
>
Hi.
I work together with Rune, and will try to describe what we want to achieve:
We want the throttling and spamhaus lookup to be forced for all email except a
few servers.
Our environment consists of several mailservers.
We have a postfix server that is used for relaying email and doing an
istered in mynetworks, all the security
> features, like throttling, are bypassed. I would like Postfix to do
> all the same checks and the same throttling on email from mynetwork.
> Is that possible?
http://www.postfix.org/postconf.5.html#smtpd_client_event_limit_exceptions
http://www.postfix.
discovered
that only inbound emails are forwarded when the domain is registered in
relay-domains, and that the sender must be in mynetworks to send
outbound email.
However… When a sender is registered in mynetworks, all the security
features, like throttling, are bypassed. I would like Postfix to
On 08/08/2013 05:10 PM, v.dimit...@synergetic.ag wrote:
Hi List.
Is there a way to ensure that submission listener will not accept
connections when dovecot is not running?
Dovecot is pretty much as stable as postfix itself.
The real question, therefore, is: why is dovecot not running ?
For
v.dimit...@synergetic.ag:
> Hi List.
>
> Is there a way to ensure that submission listener will not accept
> connections when dovecot is not running?
No. There are alomst a bazilln possible errors that Postfix may run into,
and there is no feature to detect them before handling an SMTP connectio
SASL authentication mechanisms
postfix/master[18533]: warning: process /usr/lib/postfix/smtpd pid 18998 exit
status 1
postfix/master[18533]: warning: /usr/lib/postfix/smtpd: bad command startup -
throttling
client # telnet 10.10.10.10 25
Trying 10.10.10.10...
Connected to 10.10.10.10.
Escape
Roman Gelfand:
> Would any have or could point me to a postfix outbound mail trottling
> configuration based on email provider. For instance, to Yahoo I would
> like to send out only 10 emails per hour and to gmail 100 emails per
> hour, etc...
This would involve a delivery agent in master.cf fo
Would any have or could point me to a postfix outbound mail trottling
configuration based on email provider. For instance, to Yahoo I would
like to send out only 10 emails per hour and to gmail 100 emails per
hour, etc...
Thanks in advance
On 25 May 2013, at 21:24, The Doctor wrote:
hash_queue_names = " " defer deferred
Do you have a Postfix queue named " "? Why does your Postfix config
think that you do, and that it needs hashing?
I'm not 100% sure that's your problem, but it seems worth fixing *AND*
figuring out how such a
ctor wrote:
> > > > > On Sun, May 26, 2013 at 08:04:47AM -0400, Wietse Venema wrote:
> > > > > > The Doctor:
> > > > > > > All right, I have been getting a lot of irregular throttling
> > > > > > > since Saturday midnight.
&
On Sun, May 26, 2013 at 09:58:31AM -0400, Wietse Venema wrote:
> The Doctor:
> > > You may also play with berkeley_db_read_buffer_size. The Berkeley
> > > DB documentation promises that they accept buffer sizes of 20kB or
> > > more, and their default is 256kB. If someone has screwed up Berkeley
>
ma wrote:
> > > > > The Doctor:
> > > > > > All right, I have been getting a lot of irregular throttling
> > > > > > since Saturday midnight.
> > > > > >
> > > > > > May 25 08:05:53 doctor postfix/postscreen[29
The Doctor:
> > You may also play with berkeley_db_read_buffer_size. The Berkeley
> > DB documentation promises that they accept buffer sizes of 20kB or
> > more, and their default is 256kB. If someone has screwed up Berkeley
> > DB, then perhaps it helps to specify berkeley_db_read_buffer_size
>
right, I have been getting a lot of irregular throttling
> > > > > since Saturday midnight.
> > > > >
> > > > > May 25 08:05:53 doctor postfix/postscreen[29851]: fatal: set DB cache
> > > > > size 131072: Invalid argument
> > > >
>
The Doctor:
> On Sun, May 26, 2013 at 06:37:17AM -0600, The Doctor wrote:
> > On Sun, May 26, 2013 at 08:04:47AM -0400, Wietse Venema wrote:
> > > The Doctor:
> > > > All right, I have been getting a lot of irregular throttling
> > > > since Saturday
On Sun, May 26, 2013 at 07:29:03AM -0600, The Doctor wrote:
> On Sun, May 26, 2013 at 06:37:17AM -0600, The Doctor wrote:
> > On Sun, May 26, 2013 at 08:04:47AM -0400, Wietse Venema wrote:
> > > The Doctor:
> > > > All right, I have been getting a lot of irregular thr
On Sun, May 26, 2013 at 06:37:17AM -0600, The Doctor wrote:
> On Sun, May 26, 2013 at 08:04:47AM -0400, Wietse Venema wrote:
> > The Doctor:
> > > All right, I have been getting a lot of irregular throttling
> > > since Saturday midnight.
> > >
> > &
On Sun, May 26, 2013 at 06:37:17AM -0600, The Doctor wrote:
> On Sun, May 26, 2013 at 08:04:47AM -0400, Wietse Venema wrote:
> > The Doctor:
> > > All right, I have been getting a lot of irregular throttling
> > > since Saturday midnight.
> > >
> > &
On Sun, May 26, 2013 at 08:04:47AM -0400, Wietse Venema wrote:
> The Doctor:
> > All right, I have been getting a lot of irregular throttling
> > since Saturday midnight.
> >
> > May 25 08:05:53 doctor postfix/postscreen[29851]: fatal: set DB cache size
> > 13107
The Doctor:
> All right, I have been getting a lot of irregular throttling
> since Saturday midnight.
>
> May 25 08:05:53 doctor postfix/postscreen[29851]: fatal: set DB cache size
> 131072: Invalid argument
Has your Berkeley DB library been updated? Perhaps you can re
All right, I have been getting a lot of irregular throttling=20
since Saturday midnight.
Script started on Sat May 25 17:54:34 2013
doctor.nl2k.ab.ca/~$egrep '(warning|error|fatal|panic)' :' /var/log/maillog
May 25 08:05:53 doctor postfix/postscreen[29851]: fatal: set DB cac
Am 13.02.2013 22:14, schrieb LDB:
> Syslog is seemingly configured properly, as well:
>
> server:/var/log # grep mail /etc/rsyslog.conf
> # email-messages
> mail.* -/var/log/mail
> mail.info -/var/log/mail.info
> mail.warning
1 - 100 of 211 matches
Mail list logo