? This very message came to me with the following header:
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
In 2.1 when used with external subscriber storage (eg SQL), will the
new equivalent of qrunner request and load the entire subscriber DB
onto the heap prior to broadcast?
<<Yeah, I'm cheating and being lazy on not checking the source
Reason: This poses scaling problems for lists with very large
numbers of subscribers. I'd suggest paging thru the set in blocks.
ObExcuse: Chap on -users asking about millions of subscribers.
J C Lawrence
---------(*) Satan, oscillate my metallic sonatas.
claw(a)kanga.nu He lived as a devil, eh?
http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
Add a --with-fqdn and --with-url or equivalent. The current cvs snapshot
can't guess my fqdn on my production box, and it's used now to build a web of
interconnected addresses, as well as populate the VIRTUAL_HOSTS table,
so I had to do a bunch of deleting and repairing in mm_cfg. I can, if I *remember*,
which I've already forgotten once, fix it when I build by setting FQDN and URL
environment variables, so that configure picks those up by default, but I have a habit
of just looking at config.status to see how I ran configure the last time. Having an
explicit configure switch would be nice.
Interesting article on slashdot:
Basically, DSLreports did a test, and found that e-mail addresses posted on
a web site could start seeing spam in as little as 8 hours.
I mention it for two reasons. One, since mail lists manage e-mail addresses
(and archives of e-mail addresses), it is yet antother indication of just
why we have to be careful about presenting and disclosing that stuff. And
second, since one of the addresses presented and disclosed is that of the
admin, we really need to come up with ways that allow newbies to contact an
admin without easily disclosing addresses to spammers. And, unfortunately,
the security problems with formmail.pl have shown THAT isn't really the
Chuq Von Rospach (chuqui(a)plaidworks.com -- http://www.chuqui.com/)
Will Geek for hardware.
Very funny, Scotty. Now beam my clothes down here, will you?
It took all of my sunday, but I just finished porting Ben Gertzfield's
excellent dupe removal patch to mailman cvs
(I also had to learn some python in the process. I'm starting to believe
that Mailman is a conspiracy to get people to learn python :-p)
In a nutshell, the patch does two things:
1) it does not send you your list copy if
- your subscribed Email address is already in the headers
- you already received the message through another list (Cc accross two
lists or more on the same site)
2) The new "nodupes" setting is really something you probably want as a
default on all lists. I also had lists were people wanted notmetoo as a
Ben's fix for that is to have a bitfield per list that you can set and
that states which options newly added users get.
As Ben said, this breaks the one patch one functionality rule, but when I
ported his work to mailman-cvs, I realized that it didn't make sense to take
However, Barry, if that would stop you from merging #1 in CVS, I could
remove it, but I'm not sure why one would want to.
I've done reasonable tests to make sure I didn't break all of mailman in the
process, and the core logic hasn't changed, so the basic functionality is
the same that Ben had written and that has been used for 6-9mo? on the
debian lists now.
In other words, it should work (it does for me, and I'm already running it
on my production mailman-cvs list server), but there is always the chance
that there might be a corner case buglet left somewhere.
Considering this was a pain to port, and how this puts to rest many of the
reply-to munging discussions (the only real argument for reply-to munging is
that it "solves" the duplicate mails you other receive when people use reply
to all), I'm hoping that this could make it in (wink, wink :-D)
Microsoft is to operating systems & security ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | Finger marc_f(a)merlins.org for PGP key
I have a small problem with a moderated list as part of my upgrades from
2.0.8 to 2.1b1.
This is a "joke of the day" style list. I'm supposed to be the only one
who can submit messages to the list; all of the members are moderated
(except me). Outgoing messages are stored in a queue, and one is sent
automatically by cron once per day.
With 2.0.8, I was processing a message by adding a Sender: tag with my
address; my address was listed in the 'posters' variable. With
"USE_ENVELOPE_SENDER = 1" in my mm_cfg.py, this worked.
The list upgrade process handled the 'posters' variable correctly; my
list address was marked *unmoderated*, and the other addresses were
copied into the new 'accept_these_nonmembers' field. (Good attention to
detail, there, btw; kudos!)
However, my 'trick' of adding a Sender: field doesn't work anymore, and
I get a confusing log/hold message that says "humour post from
chk(a)cfrq.net held: Post by a moderated member". 'chk(a)cfrq.net' is not
It turns out that, in order to find the moderation flag of the user that
send a message, Handlers/Moderate.py calls msg.get_senders, which
returns a *list* of senders with the Sender: last; Moderate.py only
looks at the first return value, which is the From: header. The address
in the From: field *is* moderated, and so the message is rejected.
Later, however, Handlers/Hold.py routine hold_for_approval calls the old
msg.get_sender (singular vs. plural), which returns the Sender: field
if "USE_ENVELOPE_SENDER = 1" is set, which is why I get the confusing
So, two things:
1) The message rejection is confusing.
2) What's the right way to do this under 2.1?
Harald Koch <chk(a)pobox.com>
"It takes a child to raze a village."
-Michael T. Fry
Mar 26 21:56:41 2002 (558) Uncaught runner exception: Continuation line seen before first header
Mar 26 21:56:41 2002 (558) Traceback (most recent call last):
File "/home/mailman/Mailman/Queue/Runner.py", line 105, in __oneloop
File "/home/mailman/Mailman/Queue/Runner.py", line 155, in __onefile
keepqueued = self._dispose(mlist, msg, msgdata)
File "/home/mailman/Mailman/Queue/IncomingRunner.py", line 111, in _dispose
status = self._dopipeline(mlist, msg, msgdata, pipeline)
File "/home/mailman/Mailman/Queue/IncomingRunner.py", line 134, in _dopipeline
sys.modules[modname].process(mlist, msg, msgdata)
File "/home/mailman/Mailman/Handlers/Tagger.py", line 47, in process
File "/home/mailman/Mailman/Handlers/Tagger.py", line 101, in scanbody
msg = email.message_from_string(EMPTYSTRING.join(lines))
File "/home/mailman/pythonlib/email/__init__.py", line 36, in message_from_string
File "/home/mailman/pythonlib/email/Parser.py", line 45, in parsestr
File "/home/mailman/pythonlib/email/Parser.py", line 40, in parse
File "/home/mailman/pythonlib/email/Parser.py", line 69, in _parseheaders
HeaderParseError: Continuation line seen before first header
Now, I'd believe there was something wrong with the header (although
mm ought to catch this more elegantly), except the user had just sent it
to list1@myserver,list2@myserver, and it made it to *list2*, it just
won't go through to list1. I unshunted it, and it failed again the same
So how in heck did it get to list2?
Barry, I saved the copy I got (I'm on both lists), and the shunt files,
if you want them; there's nothing private in the message.
I uploaded a patch to the SF bug tracker today that adds support for
doing SpamAssassin (http://spamassassin.taint.org/) checks to the
mailman message pipeline:
This will contact the spamd daemon to score the message. If the message
gets scored above one threshold, it gets discarded (this defaults to 10,
but can be customised in the mm_cfg.py file). If the message scores
above another lower threshold, it gets held for moderation (this
defaults to 5).
I wrote this to try and reduce the number of messages held for
moderation. I wrote it for mailman 2.0.x (as that is what I am using at
the moment), but it should be fairly easy to update for 2.1.
It might be worth using on the python.org mailing lists ...
(I am not on the mailing list, so please don't remove me from the CC
list on replies).
When selecting the "forward to" option (and leaving it otherwise deferred)
I get this:
Traceback (most recent call last):
File "/home/mailman/scripts/driver", line 82, in run_main
File "/home/mailman/Mailman/Cgi/admindb.py", line 159, in main
process_form(mlist, doc, cgidata)
File "/home/mailman/Mailman/Cgi/admindb.py", line 644, in process_form
File "/home/mailman/Mailman/ListAdmin.py", line 175, in HandleRequest
File "/home/mailman/Mailman/ListAdmin.py", line 311, in __handlepost
File "/home/mailman/Mailman/Message.py", line 158, in __init__
File "/home/mailman/pythonlib/email/Message.py", line 160, in set_payload
File "/home/mailman/pythonlib/email/Message.py", line 198, in set_charset
File "/home/mailman/pythonlib/email/Encoders.py", line 75, in encode_7or8bit
AttributeError: Message instance has no attribute 'encode'
This was a fairly large note with a mime attachment.