From: Florin Andrei on
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 flagged as spam by Yahoo users are
reported back to us, so we can silence notifications for those accounts.
That didn't seem to help.

Messages @yahoo.com just accumulate in the deferred queue and stay there
for a long time. When they do get kicked back into the active queue,
it's just a trickle.

Everyone else's emails are delivered very quickly. It might be my
imagination, but it seems some providers do accept messages more quickly
if you use the email feedback loop.

Anyway, after a while, we end up with a bunch of @yahoo.com messages in
the queue, some domain typos, and not much else besides.

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 solutions that are being used *now*
specifically for dealing with Yahoo.

Thanks.

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

From: mouss on
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 Yahoo, so that messages flagged as spam by Yahoo users are
> reported back to us, so we can silence notifications for those accounts.
> That didn't seem to help.
>
> Messages @yahoo.com just accumulate in the deferred queue and stay there
> for a long time. When they do get kicked back into the active queue,
> it's just a trickle.
>
> Everyone else's emails are delivered very quickly. It might be my
> imagination, but it seems some providers do accept messages more quickly
> if you use the email feedback loop.
>
> Anyway, after a while, we end up with a bunch of @yahoo.com messages in
> the queue, some domain typos, and not much else besides.
>
> 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 solutions that are being used *now*
> specifically for dealing with Yahoo.
>

it looks like yahoo throttle you.
- if you send few mail, do nothing. just wait and things will hopefully
get better.

- if on the other hand you send a lot of mail, then you need to get in
touch with yahoo. there's nothing we can do to help you.

one thing you can do is to ask your recipients to explicitely tag your
mail as "not spam" if it was ever tagged as spam. or they can reply (of
course, this doesn't work for silly noreply mail. [sigh, I just got an
internal one with a URL that doesn't work, and I don't know whom to
contact...]).

From: "Mike Hutchinson" on
> > # 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
> > yahoo_destination_rate_delay = 1s
> > yahoo_destination_recipient_limit = 5
> >
> > 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.
> >
> > I hope this helps.
>
> Interesting. Really.

[Michael Hutchinson]
It is. I don't know of any other software that even comes close to
supporting rate limiting for outgoing E-Mail. As I understand it, even
companies that package Postfix in their NetApps are taking advantage of
these features now.

> FYI This should be documented better: Postfix's _rate_delay feature
> forces a per-destination delivery concurrency of 1, so you could
> drop the _destination_concurrency_limit settings. The Postfix
> implementation is utterly simple: schedule one delivery, then
> suspend delivery for N second, then schedule the next delivery.

[Michael 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 ?

Cheers,
Michael Hutchinson
mhutchinson(a)manux.co.nz

From: Simon Waters on
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 solutions that are being used *now*
> specifically for dealing with Yahoo.

We don't treat Yahoo! any differently here, so essentially we delivered using
Postfix defaults.

We have a "fragile" queue for difficult providers but only Microsoft domains
are listed.

Whilst I've seen comment that Yahoo! throttle, I had some logs that suggest
Yahoo! also can be overloaded at times (hardly surprising given some of the
botnets out there).

As such afraid I tend to the view that if Yahoo! email is delayed it is
largely a Yahoo! problem. Although we've not had any complaints of such in
recent months (years?), and BT Internet use Yahoo so we ship them quite a
significant proportion of our outbound email. Most of the feedback we got was
when BT switched to using Yahoo, so I assume teething problems.

From: "M. Fioretti" on
On Fri, Jun 11, 2010 13:48:24 PM +1200, Mike Hutchinson
(packetloss(a)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, all with CC/GPL licenses, at
http://freesoftware.zona-m.net. I'd like to properly reformat all this
discussion in one short tutorial to publish there, so if anybody has
other tips and advice, thanks in advance for sending them here or to
me directly, as you prefer.

HOWEVER, I surely can't work on this in the next two weeks, so if
anybody else feels like doing the same on their own blog, by all means
go ahead and post the link.

Thanks!
Marco F.