Prev: Mail Delivery Using FILTER in access table
Next: Detecting "telnet"?
From: Wietse Venema on 11 Jun 2010 07:14
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 react in a more
> Yahoo/Google restricted manner. What assistance can I provide ?

I'll encourage you and will link to, but won't publish or update
myself. The reason is that I am not in the email sending business
and therefore I cannot judge whether a given strategy needs to be
updated or whether it can be generalized.

Wietse

From: Florin Andrei on 14 Jun 2010 14:00
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 parameters, it looks like
we're using half your values.

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, the rest seem to be dropped
into deferred either immediately or very quickly. Then they stay in
deferred a long time. Then they move to active for a short while, being
delivered at a slow rate, then they fall back into deferred.

So not only is delivery slow, but the messages spend a very long time in
deferred, therefore amplifying the issue. They seem to spend more time
in deferred than in active.

Again, these are 95% @yahoo.com messages which are legitimate, go to
valid addresses, but are just being throttled by Yahoo. By my lights,
these should spend no time in deferred.

> yahoo_destination_recipient_limit = 5

We send exactly one message per destination email address, so that
setting would be redundant for us.

> These settings can be tweaked depending on what server you're talking to.
> However, these values work for us, after having dealt with not getting
> 10,000 mails out per week.

That's pretty much our order of magnitude.

So, roughly, what's the delivery rate you managed to obtain? How many
messages / second delivered to Yahoo? It seems like our rate is much
lower, for some reason.

P.S.: We're using postfix-2.3.3-2.1.el5_2 that comes with Red Hat 5. I'm
playing with 2.7 packages and I'm contemplating an upgrade. Would there
be any inherent benefits in my case by simply doing the upgrade? I
noticed there are new control parameters such as
destination_concurrency_failed_cohort_limit but I'm not sure how big of
a difference they would make.

--
Florin Andrei
http://florin.myip.org/

From: Wietse Venema on 14 Jun 2010 14:13
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 better than having Yahoo throttle your mail
and having mail end up in the deferred queue repeatedly.

Wietse

From: Florin Andrei on 14 Jun 2010 14:54
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 approach is just too much.
It's good in other areas, but obviously they jumped the gun with Postfix
in this case.

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.

Thanks for pointing it out.

--
Florin Andrei
http://florin.myip.org/

From: ha4h-grnt on 15 Jun 2010 01:13
florin(a)andrei.myip.org (Florin Andrei) writes:

> 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 approach is just too
> much. It's good in other areas, but obviously they jumped the gun with
> Postfix in this case.
>
> 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.

Hi, I've been following this thread. Had the same issue (CentOS5). The
latest RPM package I could find was 2.5.1 and the _rate_delay parameter
was introduced in 2.5.7 it seems. So I compiled from 2.7.0 (and the next
day 2.7.1 came out so did it again!). The good news is that the compile
was completely pain-free.

Our company needed a slow transport (similar to smtp transport in
master.cf, but concurrency set to 1) for one of the mobile phone
providers in Japan: KDDI/au with the ezweb.ne.jp domain. We may do the
same with Yahoo but have no need on this current server. And as I am the
first one to use the newer postfix _rate_delay function I find myself at
the forefront of what our company (a small ISP) can do :-)

I ended up using the concurrency = 1, a recipient_limit of 2, and
_rate_delay = 3s. (In the master.cf file the concurrency for the slow
transport is set to 1 also.)

In practice this means we either send out mails with one or two
recipients to the ezweb.ne.jp domain at 3s intervals, which is working
well for us. If there are more than 2 recipients, the mail gets split
up (and luckily sending two recipients with a mail does not upset
things, although we would have liked to be able to separate into 1
recipient per sender this way also).

Hope that helps,
Gernot Hassenpflug
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Mail Delivery Using FILTER in access table
Next: Detecting "telnet"?