[quote user="bryroller"]As a courtesy to our users (in a K-12 educational environment) I have had postmaster errors enabled. This, in turn, automatically generates delivery failure notifications to senders... all is good - right?
Wrong in today's environment. You should be using the reject at MercuryS to ensure that only the sending server gets the ejections. If you receive and then bounce you are bouncing to what could very easily be a forged address contained in the RFC 2822 message body.
Well... all was good - I occasionally check things here using mxtoolbox.com (most helpful, BTW) and today I find that I am listed with backscatter.org :-(...
Not that big a deal since this blacklist has a huge false positive rate that there are very few users.
From what I gather, having the delivery failure errors enabled is probably what has me listed. I like having the failures give the end user some idea as to the error(s) of their way(s) but don't know how I can keep these failure notifications from being delivered off campus.
Correct, the mail was probably accepted by some SMTP server supporting your domain and then bounced as being a non-local user creating what is called backscatter. If you are receiving via MercuryD you should never bounce the message but simply send it to the default user for handling manually.
I use Mercury/32 as a relay to a back-end server and don't really want to keep up a manual list of 300+ users (synonyms) and wonder if there is a better (or any) way of keeping the delivery failures enabled and not continue to be listed on backscatter.org?
The back-end server should never bounce mail received from Mercury/32 but send it to a postmaster account for manual processing.
TIA
[/quote]
<blockquote>[quote user="bryroller"]<p>As a courtesy to our users (in a K-12 educational environment) I have had postmaster errors enabled. This, in turn, automatically generates delivery failure notifications to senders... all is good - right? </p></blockquote><p>Wrong in today's environment.&nbsp; You should be using the reject at MercuryS to ensure that only the sending server gets the ejections.&nbsp; If you receive and then bounce you are bouncing to what could very easily be a forged address contained in the RFC 2822 message body.
</p><blockquote><p>Well... all <i>was</i> good - I occasionally check things here using mxtoolbox.com (most helpful, BTW) and today I find that I am listed with backscatter.org :-(...</p></blockquote><p>Not that big a deal since this blacklist has a huge false positive rate that there are very few users. &nbsp;
</p><blockquote><p>&nbsp;
From what I gather, having the delivery failure errors enabled is probably what has me listed. I like having the failures give the end user some idea as to the error(s) of their way(s) but don't know how I can keep these failure notifications from being delivered off campus.</p></blockquote><p>Correct, the mail was probably accepted by some SMTP server supporting your domain and then bounced as being a non-local user creating what is called backscatter.&nbsp; If you are receiving via MercuryD you should never bounce the message but simply send it to the default user for handling manually.
</p><blockquote><p>&nbsp;
I use Mercury/32 as a relay to a back-end server and don't really want to keep up a manual list of 300+ users (synonyms) and wonder if there is a better (or any) way of keeping the delivery failures enabled and not continue to be listed on backscatter.org?</p></blockquote><p>The back-end server should never bounce mail received from Mercury/32 but send it to a postmaster account for manual processing.
</p><blockquote><p>TIA&nbsp;</p></blockquote><blockquote>[/quote]</blockquote>&nbsp;
