[Mailman-Users] sorting out bounces

[Brad Knowles]

At 4:20 PM -0500 2006-01-01, Eric S. Johansson wrote:

>  Brad Knowles wrote:
>>  	Mailman manages the bounces internally, so as to automatically
>>  handle unsubscriptions due to excessive bounces, nonexistent
>>  accounts, etc....
>>
>>  	That's the way it is supposed to work.
>
>  correct behavior but totally useless.

	No, it's not totally useless.  If it was, then the feature would 
never have been implemented that way.

	Now, maybe it doesn't work the way you want, but it is absolutely 
*NOT* "totally useless".

>  if you have three or four people, each managing a group of lists on a
>  machine, is there no way for them to find out which addresses are
>  bouncing for their list sets without receiving all of the bounces for
>  every other lists?

	List admins don't receive the bounces.  The system does.  There 
are many examples of groups of multiple list admins all managing the 
same mailing lists, and having absolutely no problems whatsoever with 
this method.

	Now, one thing you can do is to have the admin get notified when 
a user gets unsubscribed, and a copy of the bounce that resulted in 
that unsubscription.  Alternatively, you can effectively disable the 
bounce management process altogether, but then all list admins would 
receive copies of all bounces.

>    I don't dispute it may be the best you can do but at this point, the
>  best solution is to throw all of those bounce messages into /dev/null
>  and ignore the problem of admin directed bounce messages entirely.

	Then let bounce management work properly within the Mailman 
context, and let the system do what it was designed to do.

	Mailman is an open-source project.  You're perfectly welcome to 
write code to implement a feature the way you want, and contribute 
that code back to the project so that you don't have to keep 
maintaining your patch and re-applying it every time a new version 
comes out.

>  and on the subject of bounce messages, more often than not a bounce
>  message has insufficient information to tell me what user on what list
>  should be removed.

	Which is why you use VERP and personalization.  Try searching the 
FAQ Wizard.

>                      Again, this is the fault of the bounce return data
>  but some mechanism for searching the entire subscriber list for all
>  lists would be helpful when eliminating no longer valid addresses.

	That wouldn't help anyway.  VERP and personalization does.

>  and third, when searching user list visually, it would be helpful to
>  have all the subscribers displayed at once.  It's often easier for this
>  human to operate on larger data sets than arbitrarily fragmented ones.

	Doesn't work when you've got 500,000 subscribers.  If you don't 
like the point at which subscribers are broken into separate groups, 
you can always change that through a setting in mm_cfg.py -- again, 
try searching the FAQ Wizard and the archives of the list.

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

  LOPSA member since December 2005.  See <http://www.lopsa.org/>.