[BlueOnyx:22492] Re: Backscatter problem
barry at oldradio.com
Tue Nov 13 17:40:44 -05 2018
At 02:54 PM 11/13/2018, Michael Stauber wrote:
>Even that would not eliminate the problem that their email database
>contains a ton of dead-wood that will result in bounces.
>And that is the point where a proper mailing software comes in. One that
>manages bounces. Like Mailman does. If it sees repeated bounces from
>certain addresses, then it will put further email delivery to that
>address on hold.
This may or may not be useful to you, but
apparently Mailman does NOT always prevent
delivery to bad addresses. There MAY
be a setting/config/option, that can "fail."
Two weeks ago, after getting dozens of
duplicate emails on several lists, the ISP
was unable to identify the problem. Several
reboots and restarts of Mailman were
ineffective in solving the problem. I finally
found out that some emails waiting in
mqueue were over three months old, and
it seemed that one result was some
mail servers were timing out on a few
At this point, I do not know whether
it was these timeouts or the sheer
number of items in the mqueue, but
when I deleted everything up to the
previous week, the system partially
cleared. When I deleted items with the
bad addresses, it cleared completely.
I am still watching daily for buildup
in the mqueue ... and so far there has
been no repeat. But there must have
been something that allowed Mailman
to keep those old emails in the mqueue
(August emails in November).
>And it's not just Mailman which does it, but pretty
>much most promotional, email-marketing or CRM tools that use email.
>On top of that your client gets something they can manage in a browser,
>can use HTML-Emails, ability to manage email recipient databases and
>organize them by campaigns as well as statistics about how effective
>their emails are.
>I once used to use OpenEMM and something like that would be ideal for
>the purposes you described:
>Back to the server side of things for a moment:
>Here the problem is twofold:
>Bounces by default to back to the sender or to postmaster. You could set
>up a procmail-rule that moves them to /dev/null for instant deletion
>when they come in.
>Undeliverables in the queue:
>So your queue fills up with emails to long dead email accounts or
>accounts which block email from you due to you being on RBLs or being
>blocked due to past email activity?
>By default the Sendmail on BlueOnyx queues these emails for five days
>(on 5209R) or seven days on older BlueOnyx before it gives up. When it
>gives up sender and/or postmaster get the NDA-notice. Again this could
>be redirected to /dev/null via a custom procmail-rule.
>This can be adjusted in sendmail.mc:
>[root at 5209r mail]# cat /etc/mail/sendmail.mc|grep QUEUE
>dnl define(`confTO_QUEUEWARN', `4h')dnl
>dnl define(`confTO_QUEUERETURN', `5d')dnl
>As you can see: It warns after 4 hours of undeliverability and returns
>to sender after 5 days.
>You can simply adjust these two to your liking and then rebuild the
>sendmail.cf this way:
>With best regards
>Blueonyx mailing list
>Blueonyx at mail.blueonyx.it
Barry Mishkind - Tucson, AZ - 520-296-3797
More information about the Blueonyx