![](https://secure.gravatar.com/avatar/107dbd4c05818a538bce7193e5647c7a.jpg?s=120&d=mm&r=g)
I'm sorry to bomb this list with user issues. I've sent a couple notes to mailman-users about this and received no responses, not even "i don't know" or "what have you been smokin'?" mails.
After upgrading from MM 2.0 to 2.1 several months ago, admin messages (pending subscriptions, mail from non-members) stopped going to the three of us who administer the cedu mailing list. We don't learn about this stuff until the daily summary of administrative requests comes out. Furthermore, mail sent to the cedu-admin address generates an uncaught bounce notification. We used to use that address to communicate amongst ourselves. The alias definitions for the list are
cedu: "|/etc/smrsh/mailman post cedu"
cedu-admin: "|/etc/smrsh/mailman admin cedu"
cedu-bounces: "|/etc/smrsh/mailman bounces cedu"
cedu-confirm: "|/etc/smrsh/mailman confirm cedu"
cedu-join: "|/etc/smrsh/mailman join cedu"
cedu-leave: "|/etc/smrsh/mailman leave cedu"
cedu-owner: "|/etc/smrsh/mailman owner cedu"
cedu-request: "|/etc/smrsh/mailman request cedu"
cedu-subscribe: "|/etc/smrsh/mailman subscribe cedu"
cedu-unsubscribe: "|/etc/smrsh/mailman unsubscribe cedu"
/etc/smrsh/mailman is a symlink to /home/mailman21/mail/mailman.
Mail sent to the cedu-owner address seems to go to all three of us. What I don't understand is what the cedu-admin address is for and where the admin messages are going.
It seems clear that I missed something during the 2.0->2.1 upgrade, but I'm at a loss to see what. Any guidance would be much appreciated.
Thanks,
-- Skip Montanaro Got gigs? http://www.musi-cal.com/submit.html Got spam? http://spambayes.sf.net/ skip@pobox.com
![](https://secure.gravatar.com/avatar/01aa7d6d4db83982a2f6dd363d0ee0f3.jpg?s=120&d=mm&r=g)
On Tue, 2004-02-03 at 08:49, Skip Montanaro wrote:
After upgrading from MM 2.0 to 2.1 several months ago, admin messages (pending subscriptions, mail from non-members) stopped going to the three of us who administer the cedu mailing list. We don't learn about this stuff until the daily summary of administrative requests comes out. Furthermore, mail sent to the cedu-admin address generates an uncaught bounce notification. We used to use that address to communicate amongst ourselves. The alias definitions for the list are
cedu: "|/etc/smrsh/mailman post cedu" cedu-admin: "|/etc/smrsh/mailman admin cedu" cedu-bounces: "|/etc/smrsh/mailman bounces cedu" cedu-confirm: "|/etc/smrsh/mailman confirm cedu" cedu-join: "|/etc/smrsh/mailman join cedu" cedu-leave: "|/etc/smrsh/mailman leave cedu" cedu-owner: "|/etc/smrsh/mailman owner cedu" cedu-request: "|/etc/smrsh/mailman request cedu" cedu-subscribe: "|/etc/smrsh/mailman subscribe cedu" cedu-unsubscribe: "|/etc/smrsh/mailman unsubscribe cedu"
/etc/smrsh/mailman is a symlink to /home/mailman21/mail/mailman.
Mail sent to the cedu-owner address seems to go to all three of us. What I don't understand is what the cedu-admin address is for and where the admin messages are going.
It seems clear that I missed something during the 2.0->2.1 upgrade, but I'm at a loss to see what. Any guidance would be much appreciated.
In MM2.1, the -admin address is an alias for -bounces not -owner. This is primarily for backwards compatibility reasons. Note however that immediate admin notifications should go to the -owner address, not -admin. In fact, you should treat -admin as deprecated; eventually it will go away.
In the General admin page, check the value for admin_immed_notify. That controls whether you get those pending subscription notifications and such.
-Barry
![](https://secure.gravatar.com/avatar/107dbd4c05818a538bce7193e5647c7a.jpg?s=120&d=mm&r=g)
Barry> In MM2.1, the -admin address is an alias for -bounces not -owner.
Thanks for this clarification.
Barry> In the General admin page, check the value for
Barry> admin_immed_notify. That controls whether you get those pending
Barry> subscription notifications and such.
That's already set to Yes... :-/
Skip
![](https://secure.gravatar.com/avatar/107dbd4c05818a538bce7193e5647c7a.jpg?s=120&d=mm&r=g)
Barry> In the General admin page, check the value for
Barry> admin_immed_notify.
>> That's already set to Yes... :-/
Barry> Hmm.
My sentiments exactly.
I'm not at all familiar with the Mailman source code, but it appears that the decision to send out an admin message is made in Mailman.Handlers.Hold. hold_for_approval(). That code suggests that the MessageHeld exception is always raised, even if mlist.admin_immed_notify is 1. Am I missing something?
It appears I'm looking at 2.1.0 sources:
MAJOR_REV = 2
MINOR_REV = 1
MICRO_REV = 0
(I thought I was running 2.1.2, but apparently not.)
Maybe I just need to upgrade. Let me try this first before you spend anymore time thinking about it.
Skip
participants (2)
-
Barry Warsaw
-
Skip Montanaro