Thanks Wietse, I'm still a little confused here. Based on the logs (and what I expect) the server 202.137.240.16 which is the destination server for this mail has rejected the recipient with a permanent error.
*host 202.137.240.16[202.137.240.16] said: 550 5.1.1 <nosuchem...@randominsanity.net.nz <nosuchem...@randominsanity.net.nz>>: Recipient address rejected: User unknown in local recipient table (in reply to RCPT TO command)* To me this seems like the downstream server has sent a permanent rejection of the recipient however my server is still returning a tempfail to the source. This is why I expected it to trigger the unverified_recipient_reject_code. Are you able to explain a little more what the tempfail in that probe is so I can better interpret the logs as my reading of it would be a successful probe returning a reject result? Cheers, Daniel On Wed, Feb 18, 2015 at 3:07 AM, Wietse Venema <wie...@porcupine.org> wrote: > Daniel Hopkirk - RandomInsanity: > > Hi Guys, > > > > Thanks Wietse for your comments, you confirmed what I assumed but > couldn't > > afford to assume! > > > > And thanks for your thoughts Bennett. I'm happy to say that the key > points > > you mentioned are ones we have already given thought as part of our > general > > planning. > > > > I've been progressing following your comments and have made good progress > > but have hit a road block that I'm hoping someone can spot what I'm > missing. > > > > The short issue is that although we're using > 'reject_unverified_recipients' > > and have set 'unverified_recipient_reject_code = 550', mail is still > > continuing and going through greylisting (returning 450 to client) and > not > > until greylisting is over is it rejecting the email back to the client. > The > > Your 550 reply code applies IF AND ONLY IF the downstream server > rejects the recipient. > > In your case, the answer is determined by the setting of > unverified_recipient_tempfail_action. > > reject_unverified_recipient > Reject the request when mail to the RCPT TO address is known to > bounce, or when the recipient address destination is not reach- > able. Address verification information is managed by the ver- > ify(8) server; see the ADDRESS_VERIFICATION_README file for > details. > The unverified_recipient_reject_code parameter specifies the > numerical response code when an address is known to bounce > (default: 450, change into 550 when you are confident that it is > safe to do so). > The unverified_recipient_defer_code parameter specifies the > numerical response code when an address probe failed due to a > temporary problem (default: 450). > >>> The unverified_recipient_tempfail_action parameter specifies the > >>> action after address probe failure due to a temporary problem > >>> (default: defer_if_permit). > This feature is available in Postfix 2.1 and later. > > Ignoring the confusing text (and corresponding implementation) the > up-shot is that either your address probe is still in flight, the > down-stream server is unavailable, or the down-stream server replied > with 4XX. > > In all those cases you don't want to 5XX reject the recipient > because the address may still be good. With defer_if_permit, Postfix > looks for other reasons to hard reject the recipient, hence the > greylist and other checks. > > Wietse >
