Howdy, My users are receiving the following:
Your mail address xxx@xxx.com has been removed from the mpls-ops@mplsrc.com mailinglist. It generated an excessive amount of bounced mails.
How do I stop smartlist from automatically removing users since the bounces aren't their own fault? Thanks, Irwin
At 10:10 AM -0500 12/3/01, Irwin Lazar is rumored to have typed:
How do I stop smartlist from automatically removing users since the bounces aren't their own fault?
Slow down a sec...if the address really _is_ bouncing, it doesn't matter who's "fault" it is, it's putting unnecessary load on your server, and wasting bandwidth since the mail _will_ come back to you anyway. If someone changes their email address without unsubscribing to your list (like _that's_ never happened before!), you WANT SmartList to remove the bad address, don't you? What you should be looking at instead of disabling SmartList's bounce handling altogether is setting a reasonable value for minbounce - that's the number SmartList uses to determine how many bounces calls for being unsubscribed. And this requires a little bit of thought. If you have a list that goes out once a day or so, like a digested list, you might think about setting that value to four, figuring the address would have to be consistantly dead for four days before SmartList removed the address. If you have a list that goes out once a week or less frequently (like an advertising newsletter), you'd probably want to set it to two instead. And if you have a really popular discussion list, you might want to set the value to 20, 30, or even more. You need to set this value to "match" your list usage; the idea is that you really _want_ to unsubscribe consistantly dead addresses, without unsubscribing transient fatal errors (a name server is set up wrong and mail bounces for a couple of hours or a even a day, a router goes down 'twix you and it, and a hundred other temporary problems that show up every day on the Net). Each list is going to be different, so you need to adjust it carefully until you find the right value for _your_ list. Charlie
When Irwin asked, L> How do I stop smartlist from automatically removing users since the bounces L> aren't their own fault? Charlie responded, S> Slow down a sec...if the address really _is_ bouncing, it doesn't matter S> who's "fault" it is, it's putting unnecessary load on your server, and S> wasting bandwidth since the mail _will_ come back to you anyway. When I saw Irwin's post, I had the impression that he was discussing this case: member A posts; member B's address is unreachable; B's site sends an NDN to list-request; SmartList sees A's address in the NDN and counts the bounce against A instead of B; after a few posts by A (fewer if more than one member is bouncing with confusing NDN's like B's) SmartList removes A. Mean- while, B remains subscribed and more and more of the active posters are get- ting removed because B's copies of their posts bounce. But A's address is working, A is receiving the list, A and B are different people, and A is not the sysadmin at B's site, so the bounces from B's ad- dress that SmartList is blaming on A are, as Irwin said, not A's fault. Irwin's question, if I understood it right, could be phrased as, "How do I stop SmartList from automatically removing users, since the bounces are not from their addresses?" That's happened a lot and it is arguably SmartList's biggest fault: being too cocky about whose address is bouncing. I've been kicked off the Procmail and SmartList Lists several times (before they were switched to Mailman) be- cause somebody else was bouncing. For a while I had to resub the Procmail List every three or four days and keep backup subscriptions at an address from which I never posted to make sure I didn't miss posts. Charlie qualified, S> ... if the address really _is_ bouncing, ... and that's the thing: it isn't.
On Mon, 3 Dec 2001, David W. Tamkin wrote:
Irwin's question, if I understood it right, could be phrased as, "How do I stop SmartList from automatically removing users, since the bounces are not from their addresses?"
This is a problem with SmartList's bounce handling depending on mail servers to use standard bounce message syntax and unfortunately they don't. Microsoft's Internet Exchange causes this problem alot. I'll try the following example, it has been awhile since I had this problem as I hacked qmail/verps into my SmartList configuration. Hopefully nothing has changed with IE server's bounce message. Here is a bounce message that comes back: "Your message To: somelist@lists.cuenet.com Subject: Monthly Announce Announcement Sent: Mon, 3 Dec 2001 15:27:30 -0500 did not reach the following recipient(s): somebody@someISP.com on Mon, 3 Dec 2001 15:28:17 -0500 The recipient name is not recognized The MTS-ID of the original message is: c=WW;a=CONCERT;p=CONCERT;l=ATAEXCONN010112032028VR6N06QZ MSEXCH:IMS:Exchange:CRTATL:ATAEXCONN01 0 (000C05A6) Unknown Recipient" SmartList can't determine that somebody@someISP.com is the recipient whose email is bouncing. So SmartList trying to be 'smart', looks for the 'next best' address which it finds in the 'From: " address of the attached copy of the email that bounced as follows: ------_=_NextPart_000_01C17C39.0D1D918A Content-Type: message/rfc822 Message-ID: <Pine.LNX.4.21.0112031226120.29639-100000@orbital.cuenet.com> From: Cueman <cueman@cuenet.com> To: somelist@lists.cuenet.com Subject: Monthly Announce Date: Mon, 3 Dec 2001 15:27:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-MS-Embedded-Report: Content-Type: text/plain; charset="iso-8859-1" [body of message snipped] There are no doubt by now many other examples of this stuff. So the solution is to: 1. Have a special bounce recipe for every possible bounce message out there. 2. See if Sendmail has addressed the issue of some sort of verp system with their professional product and massage that into the scheme of SmartList. 3. Build a new SmartList that has some sort of verp system so that SmartList isn't depended on the cooperation of rouge mail server companies. I still have the occasional embarrassment of SmartList accidentally unsubscribing the listadministrator. That's a tough one to explain to ordinary folks without CS degrees that are used to things that work. Cheers, Cueman
participants (4)
-
Charlie Summers -
CueMan -
David W. Tamkin -
Irwin Lazar