From: Florin Andrei on 10 Jun 2010 14:51 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 10 Jun 2010 18:51 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 10 Jun 2010 21:48 > > # 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 11 Jun 2010 04:09 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 11 Jun 2010 04:28 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.
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: Mail Delivery Using FILTER in access table Next: Detecting "telnet"? |