This is a very interesting list (policyd) I wasn't really expecting replies so well given and explained, its just *super*.
Simon, that's a perfect answer. I'll need now to se if the newsletter software is able to coupe with Defered email otherwise I'm just going to have a central smtp in a separated server for simplicity sake (I have the servers virtualized so its actually better). What can I say... Thank you very much. I hope someone ask something I can add a valued answer for retribution. :) Best regards Nuno Abrantes On Sat, Jun 29, 2013 at 10:04 AM, Simon Hobson <[email protected]>wrote: > Nuno Abrantes wrote: > > I'm working with an online newspaper that triggers about 500k to 1M > emails at the > > time normaly once a week, obviously some email servers and DNSLB > services disagree > > with this and start to bounce back the sent emails. > I have something similar, but not to that scale. > > > So I'm going to use: "newsletter software (with smtp client)" -> > "policyd" -> "smarthost" -> "recipients" > > > > My problem is that once I change the "verdict" to defer I start getting > fail codes. > > root@policyd:~# for f in 1 2 3 4 5 6 7 8 9 10 ;do ./smtp-cli > --server=localhost [email protected] --to > [email protected] --subject "testes via smtp";done > > > RCPT TO <[email protected]> failed: '450 4.7.1 < > [email protected]>: Recipient address rejected: 5' > > > RCPT TO <[email protected]> failed: '450 4.7.1 < > [email protected]>: Recipient address rejected: 5' > > ... > > > "Applying a defer/greylisting policy on the incoming queue is fine while > the client on the remote > > side is another SMTP server that can happily store the deferred email on > its queue and retry > > some minutes/hours later. What happens though if the SMTP client is a > PHP application that > > connects through themail() function? There you have no queue and if you > defer a message at > > the SMTP server it will get forever lost, PHP can’t resend it." > > Yes, that is correct. You need a sender that is capable of queuing and > retrying the messages - otherwise deferring (or any other failure to > accept) will result in the message being lost. > I've had discussions with one or two of my customer's where they are > sending mail out through my mail server (from a remote web site) and their > software isn't complete as a client (can't authenticate) and isn't a server > (can't queue and retry). Therefore, they were losing all the messages due > to greylisting. > The option given in that article is one way - let one Postfix instance > accept and queue all the mail, then let a second rate limit it with > Policyd. Alternatively, you could put all the mail in the hold queue and > write some scripts to release it at a controlled rate. > If you go down the second Postfix instance route, there are a couple of > things you need to be aware of. My bulk customer has their own SMTP server > so I don't need a second Postfix instance, but I do use rate limited (per > sender quotas). > When the quota kicks in, PolicyD starts rejecting recipient addresses - so > you get a situation where a message with (say) 50 recipients gets one or > two accepted, then the rest are rejected. If (as I had) you have Postfix > set to reject messages with more than a small number (in my case 3) errors, > then the few recipients accepted increment the quota (so keep it fully > used) but then are rejected when Postfix rejects the entire message. Thus > nothing gets through at all ! > You have to set the error count higher than the max number of > recipients/message. That way, the first few recipients that get accepted > will go through, and then the rest will get queued for a retry later. The > result is that the messages will go through, but only a few recipients at a > time - and a side effect is that there are more messages to handle as > you'll process (say) maybe 10-20 messages with a handful of recipients each > instead of 1 message with 50 recipients. > I have put in a feature request for the recipient count quota to be > updated at the smtp_end_of_data point (as is done for message size quotas) > instead of at the smtp_recipient stage for each recipient, so that either > the whole message goes to all recipients or it doesn't go to anyone. It > would mean that the sender could go over quota by the number of recipients > in one message, but then further messages would be blocked until the quota > count came down to below the limit. > > _______________________________________________ > Users mailing list > [email protected] > http://lists.policyd.org/mailman/listinfo/users_lists.policyd.org > -- Cptos / Regards Nuno Abrantes skype: n <[email protected]>[email protected] / nmabrantes http://www.linkedin.com/in/nabrantes
_______________________________________________ Users mailing list [email protected] http://lists.policyd.org/mailman/listinfo/users_lists.policyd.org
