On Tue, Jan 26, 2016 at 12:07 PM, btb <b...@bitrate.net> wrote: > On 2016.01.26 10.54, Matt Bayliss wrote: > >> I'm trying to find the correct/best practice method for setting up a >> black hole email address for such items as "noreply" addresses when >> sending alerts from monitoring devices etc. >> > > if you intend no mail to be sent to this address anyway, and will just > throw away any mail that arrives, then why bother accepting mail for the > address at all? pick an address you like, configure your various devices > to use it when sending mail, and don't worry about postfix. if someone > tries to send mail to that address, postfix will reject it.
Yep. It all boils down to what you want to occur if someone replies to the "noreply" address. 1) Want the reply to disappear and not bounce back to the sender? Point the noreply alias to /dev/null (that's different than setting up a "noreply" user -- an alias is not a user account). 2) Want the reply to bounce back to the sender? Make sure you don't have a noreply alias or catchall, and Postfix will send the appropriate "no such recipient" error to the sender. 3) Want to send a custom "Sorry, we don't check this email account so please don't expect a reply" message to the sender? Set up an auto-reply (and send the incoming message at /dev/null), but do so prudently so as to avoid any backscatter concerns (seriously... backscatter and auto-reply wars are no bueno). Option has the most potential pitfalls, so I'm a fan of Options 1 and 2. Both are completely acceptable as "best practices" for "black hole" email addresses for alerts from monitoring devices. A fourth option (which I do for certain alerts such as smart UPS battemy systems) might also be having the messages come from root, so that if deliverability TO the desired alert addresses fails, the bounce has somewhere to go that you might eventually see (I quickly browse through and delete messages to root on my servers once every 2-3 days). SteveJ
