? This very message came to me with the following header:
Errors-To: mailman-developers-admin(a)python.org
All my bounces come to the list admin address, set in
the admin webpage, in the second field of General Options.
Do you have that set to something, and bounces still come to root?
> 2. Bounces are sent to the poor postmaster instead of a -admin address.
> I'm not entirely certain, but I think an Errors-To: header or something
> like that in all Mailman messages might allow one to distribute that load
> somewhat.
Here is my first draft of multiple back end support for Mailman.
There will be a Mailman front end and two back ends, one for the Config,
and another for the Recipient List. The Mailman front end will start
and read the mm_cfg.py file. This file will say which backends are used
for the Config and Recipient List. This is the upper layer. The upper
layer then imports the modules for the backend of the Config and the
relevant Recipient List . For right now I am not messing with the admin
approval que. I think maybe it should be tied into the Recipient List
backend later.
Here are basic things I see Mailman needing to facilitate through
the backend of this API.
Get the default config for lists on this site.
Get the config for an individual list.
Get a config item for an individual list.
Add a recipient
Remove a recipient
Set a property of a recipient
Set a property of a list
Add a list
Remove a list
I believe that everything else can be handled by the frontend
The module for the Config will contain a class named Config with the
following methods:
Config.GetConfig('List',) returns a dictionary of ConfigItem -
ConfigItemValue pairs. List name '_Default_' will get the default
config
Config.GetConfigItem('List','ConfigItem') returns the ConfigItemValue
Config.SetConfigItem('List','ConfigItem',Value) will set the value of an
item for this
The module for the Recipient List will contain a class named List
with the following methods:
List.SetRecepientProperty('RecepientName',Property,Value) will Set a
property for a recipient.
List.RemoveRecepient('RecepientName') will remove a recipient from the
Recipient List.
List.GetRecepient('RecepientName') returns a Dictionary of information
on the recipient or -1 if there is no recipient by that name
List.AddRecepient('RecepientName',Digest=Config.GetConfigItem('_Default_','Digest')
etc. . ) this will add a recipient to the list with the default settings
for the list except superseded by the caller
List._init_() for creating a new list
List._destroy() for removing a list
Here are some issues I am not sure I adderessed or understood.
mixed and lower case mail addr.?
logging?
admin approval list should be in database ?
Each BackEndClass and Mailman version will have to have it's own version
number with a set of methods / functions to upgrade from one to another.
I think it is best for the Config, Recipient list, and Recipient
information objects to be dictionary's. That way if a later version of
Mailman wants to add some feature or variable, it won't cause any
problems with different sized lists etc. . . as long as we don't reuse
key names. In addition each new version of the backend can check the
marshal file, or database table or whatever and if it finds an older
version, use an upgrade method or function to bring the old list up to
date using the defaults for the site.
I apoligize for the crudness of this outline, and I am interested to see
everyones suggestions.
A.
L.
Has there been a change recently that is causing news-to-mail
gated messages to include all of the news headers in the *body*
of the mail message? (I hadn't updated my CVS snapshot for a
couple of weeks... and now seem to be getting this behavior.)
--
Jim Tittsler, Tokyo
Python Starship http://starship.python.net/crew/jwt/
On Fri, Jul 28, 2000 at 02:57:40PM -0500, Roy C. Bixler wrote:
> If, as I suspect, no one has tackled this yet, I don't think it would be
> very hard. What makes WN different from other Web servers is that it
> requires a database (an 'index.cache' file) in each directory enumerating
> which files can be served. This poses a problem for the archive
> directories where 'index.cache' has to be updated each time a posting is
> added to the archive. A quick and dirty way to do this is with a 'wndex
> -a' command (i.e. creates an 'index.cache' file which gives permission for
> all current files in this directory to be served) executed from a 'cron'
> job. Even better, could this be done in Mailman/Archive/HyperArch.py?
> The last line of the HyperArch::Write_TOC() method would be:
>
> os.system("wndex -a -d " + self.basedir)
> ('-d' argument specifies directory to create 'index.cache' file.)
> Comments? (Yes, I know I could take the easy way out and change my Web
> server, but WN support in Mailman would interest others as well.)
Actualy, I would suggest making it a site-configuration option: something in
mm_cfg.py that can be set by the site admin, and is an empty string in
Defaults.py. That means that the site admin can customize it to fit the
needs of the site (webserver or whatever.) You probably need to do something
like this:
if mm_cfg.POST_ARCHIVE:
infodict = {
'basedir': self.basedir,
'listname': ...
'listaddr': ...
<... etc>
}
os.system(mm_cfg.POST_ARCHIVE % infodict)
It should be a site-admin job and not a list admin job, for the obvious
security issues. Exactly what information to include in the infodict is
subject to discussion, but I think starting with some of the information at
hand is fine. More stuff can be added later, and much more complicated stuff
should be handled by an external archiver instead, anyway.
--
Thomas Wouters <thomas(a)xs4all.net>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
This one was missed by Catchall:
sh: /usr/ug/bin/procmail: not found.
554 "|IFS=' '&&exec /usr/ug/bin/procmail -f-||exit 75 #tservo"... unknown mailer
error 126
If we change the "separate_cue_1" match to not choke on the space between 554 and
the 'unknown mailer' stuff, we can catch this bounce too:
***************
*** 112,118 ****
# Patterns for cases where email addr is separate from error cue.
separate_cue_1 = re.compile(
! '^554 [^ ]+\.\.\. unknown mailer error.*$', re.I)
separate_addr_1 = regex.compile('expanded from: %s' % email_regexp)
message_grokked = 0
--- 112,118 ----
# Patterns for cases where email addr is separate from error cue.
separate_cue_1 = re.compile(
! '^554 .+\.\.\. unknown mailer error.*$', re.I)
separate_addr_1 = regex.compile('expanded from: %s' % email_regexp)
This one looks a lot like the Netscape.py bouncer is already set up to handle, but
the bouncing address is not where Netscape expects it (Postmaster(a)mail.hypercon.com
is there instead).
Not quite sure how to handle this sort of bounce; would it be better to look for
"The following recipients..." just in general rather than "Please reply to"?
====
This Message was undeliverable due to the following reason:
The recipient(s) indicated below did not receive this message
because their mailbox size limit would have been exceeded. It has
been returned and it is recommended that you contact the recipient
and request that space be made available within their mailbox.
Note: The Postmaster for this mail server may increase the mailbox
quota on the account referenced below to accommodate the delivery
of additional mail.
No storage space available in mailbox for dj(a)enjoymusic.com
The following recipients haven't received this message:
dj(a)enjoymusic.com
Please reply to Postmaster(a)mail.hypercon.com
if you feel this message to be in error.
(yes, I'm chatting with myself again)
Here's a patch that catches things of this form. If anyone has
any comments, I'd be thrilled to hear them.
*** Netscape.py.orig Fri Jul 28 21:23:23 2000
--- Netscape.py Fri Jul 28 21:46:45 2000
***************
*** 40,46 ****
--- 40,53 ----
r'(?P<reply>please reply to)?.*<(?P<addr>[^>]*)>',
re.IGNORECASE)
+ fatalre = re.compile(
+ r'The following addresses had permanent fatal errors',
+ re.IGNORECASE)
+ addrre = re.compile(
+ r'(?P<addr>.*@.*)',
+ re.IGNORECASE)
+
def process(msg):
# Sigh. Some show NMS 3.6's show
***************
*** 79,85 ****
return None
plainmsg = msg
# Did we find a text/plain part?
! if not plainmsg:
return None
# Total guesswork, based on captured examples...
addrs = []
--- 86,92 ----
return None
plainmsg = msg
# Did we find a text/plain part?
! if plainmsg == None:
return None
# Total guesswork, based on captured examples...
addrs = []
***************
*** 99,102 ****
--- 106,118 ----
mo = acre.search(line)
if mo and not mo.group('reply'):
addrs.append(mo.group('addr'))
+ mo = fatalre.search(line)
+ if mo:
+ while 1:
+ line = plainmsg.fp.readline()
+ if not line:
+ break
+ mo = addrre.search(line)
+ if mo:
+ addrs.append(mo.group('addr'))
return addrs or None
> > For a while there, I had several weeks of "no unhandled bounces". Now I'm
> > getting a lot that aren't being caught, and I'm going to go start diagnosing
> > them.
> >
> > Barry, or anyone, do you have anything other than the code itself to help
> > understand the various sorts of bounces that are caught by the various
> > Bouncer modules? (i.e. samples or other explanatory docs?)
> > I expect the answer to be "no", but it doesn't hurt to ask.
>
> So now I know something about running pdb, and I've identified some
> things about one of the messages that bounces:
>
> It looks like DSN should be catching it, but it has no '*recipient'
> headers in its message/delivery-status section; the only mention
> of the bouncing address occurs in the text/plain section above it.
> It's from mx6.boston.juno.com, and I can't find anything about it
> that gives a clue as to what MTA might be generating it.
>
> It also looks vaguely like Netscape.py might be a better one to hack,
> since it embodies the "no recipient" part. I'll be trying to do that.
>
>
> here's a sample excerpt:
>
> This is a MIME-encapsulated message
>
> --AAA6Z5S39A5QX2T2/mx6.boston.juno.com
> <<< first part: text/plain
> The original message was received at Tue, 25 Jul 2000 12:41:35 -0400 (EST)
> from scr-admin(a)socal-raves.org
>
> ----- The following addresses had permanent fatal errors -----
> god_is_luv(a)juno.com <<< only address
>
> ----- Transcript of session follows -----
> 550 Service unavailable
>
> --AAA6Z5S39A5QX2T2/mx6.boston.juno.com
> Content-Type: message/delivery-status <<< no recipient here
>
> Reporting-MTA: mx6.boston.juno.com
> Arrival-Date: Tue, 25 Jul 2000 12:41:35 -0400 (EST)
>
> Action: failed
> last-Attempt-Date: Tue, 25 Jul 2000 12:41:35 -0400 (EST)
>
> --AAA6Z5S39A5QX2T2/mx6.boston.juno.com
> Content-Type: message/rfc822 <<< bounced msg here
>
> Received: from we-24-30-117-227.we.mediaone.net
(we-24-30-117-227.we.mediaone.ne
> t [24.30.117.227])
>
>
>
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers(a)python.org
> http://www.python.org/mailman/listinfo/mailman-developers
> For a while there, I had several weeks of "no unhandled bounces". Now I'm
> getting a lot that aren't being caught, and I'm going to go start diagnosing
> them.
>
> Barry, or anyone, do you have anything other than the code itself to help
> understand the various sorts of bounces that are caught by the various
> Bouncer modules? (i.e. samples or other explanatory docs?)
> I expect the answer to be "no", but it doesn't hurt to ask.
So now I know something about running pdb, and I've identified some
things about one of the messages that bounces:
It looks like DSN should be catching it, but it has no '*recipient'
headers in its message/delivery-status section; the only mention
of the bouncing address occurs in the text/plain section above it.
It's from mx6.boston.juno.com, and I can't find anything about it
that gives a clue as to what MTA might be generating it.
It also looks vaguely like Netscape.py might be a better one to hack,
since it embodies the "no recipient" part. I'll be trying to do that.
here's a sample excerpt:
This is a MIME-encapsulated message
--AAA6Z5S39A5QX2T2/mx6.boston.juno.com
<<< first part: text/plain
The original message was received at Tue, 25 Jul 2000 12:41:35 -0400 (EST)
from scr-admin(a)socal-raves.org
----- The following addresses had permanent fatal errors -----
god_is_luv(a)juno.com <<< only address
----- Transcript of session follows -----
550 Service unavailable
--AAA6Z5S39A5QX2T2/mx6.boston.juno.com
Content-Type: message/delivery-status <<< no recipient here
Reporting-MTA: mx6.boston.juno.com
Arrival-Date: Tue, 25 Jul 2000 12:41:35 -0400 (EST)
Action: failed
last-Attempt-Date: Tue, 25 Jul 2000 12:41:35 -0400 (EST)
--AAA6Z5S39A5QX2T2/mx6.boston.juno.com
Content-Type: message/rfc822 <<< bounced msg here
Received: from we-24-30-117-227.we.mediaone.net (we-24-30-117-227.we.mediaone.ne
t [24.30.117.227])
For a while there, I had several weeks of "no unhandled bounces". Now I'm
getting a lot that aren't being caught, and I'm going to go start diagnosing
them.
Barry, or anyone, do you have anything other than the code itself to help
understand the various sorts of bounces that are caught by the various
Bouncer modules? (i.e. samples or other explanatory docs?)
I expect the answer to be "no", but it doesn't hurt to ask.
Hi:
I have just successfully installed Mailman 2.0b4 but, from what I can
tell, there is no support for the WN Web server (for those unfamiliar,
more info. on it can be found at "http://hopf.math.nwu.edu" or
"http://www.wnserver.org"). Has anyone done this?
If, as I suspect, no one has tackled this yet, I don't think it would be
very hard. What makes WN different from other Web servers is that it
requires a database (an 'index.cache' file) in each directory enumerating
which files can be served. This poses a problem for the archive
directories where 'index.cache' has to be updated each time a posting is
added to the archive. A quick and dirty way to do this is with a 'wndex
-a' command (i.e. creates an 'index.cache' file which gives permission for
all current files in this directory to be served) executed from a 'cron'
job. Even better, could this be done in Mailman/Archive/HyperArch.py?
The last line of the HyperArch::Write_TOC() method would be:
os.system("wndex -a -d " + self.basedir)
('-d' argument specifies directory to create 'index.cache' file.)
Comments? (Yes, I know I could take the easy way out and change my Web
server, but WN support in Mailman would interest others as well.)
Thanks,
--
Roy Bixler
The University of Chicago Press
rcb(a)press-gopher.uchicago.edu
