Wouldn't it make sense to have the -admin address NOT set the envelope sender to -admin, but to pass the original envelope sender through?
If this change was made, any person who mailed a -admin address that was down would receive the error message (rather than the defunct -admin address receiving its own error messages ).
If a subscriber address were to become defunct and bounce, then the error message directed to the -admin address would have <> or mailer daemon or some such as the envelope sender. If the -admin address is defunct and preserved the original envelope sender, then the doubly bounced message would bounced back to the mailer daemon of the original error reporting MTA, which again wouldn't cause a loop or present any unusual problems.
The question then is how would it effect messages automatically sent to the -admin address by mailman itself? Messages to approve or deny questionable post requests, and/or sending the passwords to the -admin address (if the option is set) would have to have an envelope sender set to something other than the -admin address. here we have a few options:
set the envelope sender to mailman-owner: this is intuitive, since it is mailman itself generating these messages. It is also a much safer bet that the mailman-owner address is functional than that all the -admin addresses are functional.
set the envelope sender to <listname>-request. This is also sortof intuitive since this class of messages are requests regarding the list. However, when messages to a -admin address bounce, the error message would be directed back to the -request address, which I believe would in turn respond to the mailer daemon of the MTA reporting the error with the -admin address. Confusing, but still no nasty mail loops like some of us have experienced.
set the envelope sender to a (new) system-wide -admin delivery error collecting address. something like mailman-owner-admin-errors. This would gracefully collect all the error messages in one place for examining. I don't like the look of "mailman-owner-admin-delivery-error-collector" or anything else I can think of with this functionality as an alias though.
If we settle on a solution, I'll volunteer to do the coding. IMO the best of the above 3 options is #1.
scott
On Fri, Sep 18, 1998 at 04:29:01PM -0400, Scott wrote: | | Should this be happening? | | Sep 16 11:29:19 1998 Forpigssake: pigtrnr@aol.com - 0 more allowed over 91470 secs | Sep 16 11:50:15 1998 Forpigssake: pigtrnr@aol.com - 0 more allowed over 90214 secs | Sep 16 12:39:31 1998 Forpigssake: pigtrnr@aol.com - 0 more allowed over 87259 secs | Sep 16 12:39:31 1998 Forpigssake: pigtrnr@aol.com - 0 more allowed over 87259 secs | Sep 16 13:10:57 1998 Forpigssake: pigtrnr@aol.com - 0 more allowed over 85372 secs | Sep 16 13:23:55 1998 Forpigssake: pigtrnr@aol.com - 0 more allowed over 84594 secs | Sep 16 13:29:52 1998 Forpigssake: pigtrnr@aol.com - 0 more allowed over 84237 secs | Sep 16 13:30:31 1998 Forpigssake: pigtrnr@aol.com - 0 more allowed over 84198 secs | Sep 16 13:59:00 1998 Forpigssake: pigtrnr@aol.com - 0 more allowed over 82489 secs | . | [many more entries] | . | . | Sep 17 13:22:38 1998 Forpigssake: pigtrnr@aol.com - exceeded limits | Sep 17 13:22:39 1998 Forpigssake: disabled pigtrnr@aol.com | | | scott | | On Fri, Sep 18, 1998 at 03:35:56PM -0400, Scott wrote: | | | | I set up mailman recently (v.1.0b5) with python v1.5.1 and administor | | the site. There is a list run on the site with 3 list | | administrtors. One administrators mailbox filled up, and error | | messages went back to the -admin address, causing a mailloop. | | | | What's the status on -admin address bounce control? Anything I can do | | to help further it along? | | | | scott | | | | _______________________________________________ | | Mailman-Developers maillist - Mailman-Developers@python.org | | http://www.python.org/mailman/listinfo/mailman-developers | | | | _______________________________________________ | Mailman-Developers maillist - Mailman-Developers@python.org | http://www.python.org/mailman/listinfo/mailman-developers |