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
