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@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@mail.blueonyx.it >http://mail.blueonyx.it/mailman/listinfo/blueonyx - - Barry Mishkind - Tucson, AZ - 520-296-3797 _______________________________________________ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx