[BlueOnyx:22492] Re: Backscatter problem

[Barry Mishkind]

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
        addresses.

        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.
>
>https://www.google.com/search?q=email+marketing+software
>
>I once used to use OpenEMM and something like that would be ideal for
>the purposes you described:
>
>https://www.agnitas.de/en/e-marketing_manager/email-marketing-software-variants/openemm/
>
>Back to the server side of things for a moment:
>================================================
>
>Here the problem is twofold:
>
>Bounces:
>=========
>
>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:
>
>cd /etc/mail
>make all
>
>-- 
>With best regards
>
>Michael Stauber
>_______________________________________________
>Blueonyx mailing list
>Blueonyx at mail.blueonyx.it
>http://mail.blueonyx.it/mailman/listinfo/blueonyx

 - - 

Barry Mishkind - Tucson, AZ - 520-296-3797