On Wed, Jun 30, 2010 at 10:15:10AM -0700, Florin Andrei wrote:
More info. This is how the queues always look, it's a very typical batch:
http://i.imgur.com/7MPIx.png
This graph has no scale, and would not be very interesting in any case.
Have you made attempt to sign-up for Yahoo's feedback
On 06/28/2010 03:20 PM, Mike Hutchinson wrote:
Once we'd performed the upgrade, and applied the rate limiting configuration
everything went smoothly - perhaps try the same values from the original
post and work from there.
More info. This is how the queues always look, it's a very typical
-Original Message-
From: owner-postfix-us...@postfix.org [mailto:owner-postfix-
us...@postfix.org] On Behalf Of Florin Andrei
Sent: Tuesday, 15 June 2010 6:00 a.m.
To: postfix-users@postfix.org
Subject: Re: dealing with Yahoo slowness
On 06/10/2010 05:09 PM, Mike Hutchinson wrote
On Mon, Jun 21, 2010 at 11:08:04AM -0700, Florin Andrei wrote:
To compensate for this unwanted side effect of reduced concurrency
INCREASE the fragile_destination_concurrency_failed_cohort_limit
to 10-20 or so (or REDUCE
fragile_destination_concurrency_negative_feedback
to 1/10 or 1/20).
On 06/21/2010 11:31 AM, Victor Duchovni wrote:
On Mon, Jun 21, 2010 at 11:08:04AM -0700, Florin Andrei wrote:
yahoo_destination_concurrency_limit = 4
yahoo_destination_concurrency_failed_cohort_limit = 5
yahoo_destination_rate_delay = 1s
yahoo_destination_concurrency_positive_feedback = 1/3
On Mon, Jun 21, 2010 at 12:21:45PM -0700, Florin Andrei wrote:
My email is very bursty - event updates and changes sent to many / most /
all subscribers. So then I should do this, I guess:
yahoo_destination_concurrency_failed_cohort_limit = 20
yahoo_destination_rate_delay = 1s
I think
Florin Andrei:
I can't say I understand *why* the 1s rate delay makes the feedback and
the concurrency limit parameters irrelevant, so I guess it's time for me
to dig deeper into the documentation. :)
This takes some courage:
http://www.postfix.org/SCHEDULER_README.html
The concurrency of 1
On 06/21/2010 12:42 PM, Victor Duchovni wrote:
On Mon, Jun 21, 2010 at 12:21:45PM -0700, Florin Andrei wrote:
yahoo_destination_concurrency_failed_cohort_limit = 20
yahoo_destination_rate_delay = 1s
I can't say I understand *why* the 1s rate delay makes the feedback and the
concurrency limit
Florin Andrei:
On 06/21/2010 12:42 PM, Victor Duchovni wrote:
On Mon, Jun 21, 2010 at 12:21:45PM -0700, Florin Andrei wrote:
yahoo_destination_concurrency_failed_cohort_limit = 20
yahoo_destination_rate_delay = 1s
I can't say I understand *why* the 1s rate delay makes the feedback and
* Florin Andrei flo...@andrei.myip.org:
Looking at the Postfix queue graphs in Munin, one thing I noticed is
that when the scheduled emails go out (it's not a continuous
trickle, it's in batches, that's just how the software works), a
fraction, maybe 25%, go into the active queue right away,
Stefan Foerster:
I don't send any large volumes to Yahoo, but I had to use a dedicated
transport which ignored much more errors for a popular German freemail
provider. Since you are using rate delays, your concurrency limit will
basically be one, and this might very well be related to what you
Wietse Venema:
Stefan Foerster:
I don't send any large volumes to Yahoo, but I had to use a dedicated
transport which ignored much more errors for a popular German freemail
provider. Since you are using rate delays, your concurrency limit will
basically be one, and this might very well be
On 06/14/2010 11:54 AM, Florin Andrei wrote:
Well, that does it. I got RPM packages with 2.7 from two different
sources. Time for testing, then upgrade, and I'll keep y'all posted with
the results.
And here it is, the status update.
I got the 2.7.0 src.rpm packages made by Simon J Mudd
On Fri, Jun 18, 2010 at 02:05:36PM -0700, Florin Andrei wrote:
main.cf:
transport_maps = hash:/etc/postfix/transport
fragile_destination_concurrency_limit = 2
fragile_destination_concurrency_failed_cohort_limit = 1
fragile_destination_rate_delay = 2s
Try:
# Change from 1 above
On 06/10/2010 05:09 PM, Mike Hutchinson wrote:
yahoo_destination_concurrency_limit = 4
yahoo_destination_rate_delay = 1s
Well, we do that already (concurrency = 2, rate_delay = 2s). It's still
slow. Do you use multiple outbound email gateways?
Maybe I should try to increase our existing
Florin Andrei:
P.S.: We're using postfix-2.3.3-2.1.el5_2 that comes with Red Hat 5. I'm
That is two Postfix versions before _rate_delay was introduced.
You may want to upgrade to Postfix 2.5 or later.
If you can throttle down Postfix so it never hits Yahoo's limits,
then it will always be
On 06/14/2010 11:13 AM, Wietse Venema wrote:
Florin Andrei:
P.S.: We're using postfix-2.3.3-2.1.el5_2 that comes with Red Hat 5. I'm
That is two Postfix versions before _rate_delay was introduced.
You may want to upgrade to Postfix 2.5 or later.
Aw great. :( Sometimes Red Hat's conservative
On Thursday 10 June 2010 19:51:51 Florin Andrei wrote:
One of the tricks some people seem to use is creating a dedicated
transport for the slow destination. I'm reading the tuning and qshape
README documents, and there are a lot of good suggestions there, but I
was wondering what are the
On Fri, Jun 11, 2010 13:48:24 PM +1200, Mike Hutchinson
(packetl...@ping.net.nz) wrote:
I had thought, whilst I was writing the E-Mail, that this could
deserve a howto or manual section...
I would be quite interested to read such a howto. I also happen to
publish FOSS related tips and tricks,
Mike Hutchinson:
I had thought, whilst I was writing the E-Mail, that this could deserve a
howto or manual section, perhaps briefly describing a general situation that
would reflect the real world problem of delivery of E-Mail to servers like
Yahoo/Google, and how postfix can be configured to
There seems to be a massive difference between the speed of various
providers, in terms of accepting messages for delivery. Yahoo stands out
as, by far, the slowest of the big ones.
Because the messages are legitimate, we signed up for the email feedback
loop with Yahoo, so that messages
Florin Andrei a écrit :
There seems to be a massive difference between the speed of various
providers, in terms of accepting messages for delivery. Yahoo stands out
as, by far, the slowest of the big ones.
Because the messages are legitimate, we signed up for the email feedback
loop with
-Original Message-
Florin Andrei a écrit :
There seems to be a massive difference between the speed of various
providers, in terms of accepting messages for delivery. Yahoo stands out
as, by far, the slowest of the big ones.
Because the messages are legitimate, we signed up for
Mike Hutchinson:
We have had this exact problem, delivering Retail newsletters to people who
have opted in for it. A lot of them are on Gmail and Yahoo, and this can be
difficult with Bulk E-Mail. Despite contact with Google themselves and
signing up for all of their reporting services
# Slow these destinations to avoid blacklisting, see
/etc/postfix/transport
for domains configured
hotmail_destination_concurrency_limit = 2
hotmail_destination_rate_delay = 2s
hotmail_destination_recipient_limit = 5
yahoo_destination_concurrency_limit = 4
25 matches
Mail list logo
