Hello all,
I am using Mailman v2.1.9 with some minor local mods on CentOS 5.5. In
looking through the vette log, I noticed some of the log entries for
refused postings and discarded postings do not indicate what message
(via the message id) was acted upon. I would like to the message id to
those entries. I found where the entries are written to in
ListAdmin.py. I made a few changes to the file. Since I am barely
literate with python, I thought I would post my changes to the list and
ask you fine people if I did will work, or am I doomed. There changes
are (in diff -u format):
--- /usr/lib/mailman/Mailman/ListAdmin.py 2008-05-24
13:44:12.000000000 -0700
+++ ListAdmin.py.SCU 2011-01-28 13:26:12.000000000 -0800
@@ -340,13 +340,21 @@
fmsg.send(self)
# Log the rejection
if rejection:
+ try:
+ msg = readMessage(path)
+ except IOError, e:
+ if e.errno <> errno.ENOENT: raise
+ return LOST
+ msg = readMessage(path)
note = '''%(listname)s: %(rejection)s posting:
\tFrom: %(sender)s
-\tSubject: %(subject)s''' % {
+\tSubject: %(subject)s
+\tMessage-id: %(messageid)''' % {
'listname' : self.internal_name(),
'rejection': rejection,
'sender' : str(sender).replace('%', '%%'),
'subject' : str(subject).replace('%', '%%'),
+ 'messageid': msg.get('message-id', 'n/a').replace('%',
'%%'),
}
if comment:
note += '\n\tReason: ' + comment.replace('%', '%%')
Also, are there any other files I may need to change?
Thanks,
Chris
Hello Developer Team,
I am a web developer in php. Currently i have migrated the site but the
admin section was in mailman software at this moment how can i migrate the
admin section on new hosting please suggest me with procedure to installed
with no data lost at all.
Narayan Neupane
(Web Developer)
One of the last major subsystems that I need to get working in Mailman 3 is
bounce processing. This is different than bounce detection, which has been
successfully ported from Mailman 2, but doesn't differ in any significant
way. The question I am thinking about now is what to do with a bounce once we
detect one.
There are a couple of interesting things in MM3 that makes it different from
MM2. In MM3, users and addresses are global to the system, while membership
is specific to a mailing list. This means if we register a bounce on an
address, we can have that score affect the address's subscription to all
relevant mailing list. We can also do things like automatically roll over to
another registered and validated email address for that user, if there is one,
or at least send notifications to the other address.
There's also the question about how all the bounce scores are managed, and the
knobs you as a list administrator can tweak to control how and when things
happen based on the score. Reporting and logging are also part of the plan.
Because MM3 uses a relational database underneath the hood, my plan is to have
a single table that only appends new bounce events. That way, Mailman will
have a permanent record of every bounce that occurred. Exactly what
information we can or should put in that table is up for discussion. I do
plan also to keep all bounce messages in MM3's "message store" so that
postmortem debugging is easier.
Because I'm just starting to think about all this, I wanted to throw this out
to the list to get your feedback on things you'd like to see. What is it
about MM2's bounce processing that you like? What don't you like? What MM2
bounce features can you do without? What would you like to see added?
Any and all feedback is welcome.
-Barry
I'm not a subscriber to this list, so please include me
superticker2{at}iastate.edu on your cc: line.
I have two suggestions I would like to make concerning Mailman bounce
processing:
1) All bounces from either a Mass Subscribe or Mass Invite operation should
be unconditionally and immediately sent to the list owner.
There can be many typos in these Mass Subscribe/Invite lists, and the list
owner needs to correct these typos _immediately_. In addition, some of
these mass subscription lists come from paper sign-up lists by foreign
students where the English alphabet is new to them. Trying to decipher
their email addresses can result in 10% typos and bounces, which need
immediate corrections.
2) All bounces should be immediately directed to the list owner if bounce
processing is switched off.
For small lists, it makes the most sense for the list owner to handle
bounces manually. Often he'll know the recipients personally and their new
email addresses, which he can fix himself when they bounce. As it stand
today, there could be 100s of bad addresses on an email list without
anyone's knowledge if bounce processing is off; this is bad design.
