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

Reply via email to