[Mailman-Users] Some notes on mailman...

[Chuq Von Rospach]

At 2:04 AM -0400 5/18/2000, Tom Limoncelli wrote:
>chuq: this is really useful research!  Thanks!


Glad it's useful. I hope at some point to actually sit down and work 
on fixing things instead of just complaining, too...


>  > 8) moderator and admin messages go to the list owners for processing
>>  (and approvals via the admin web site).
>
>This is actually a negative thing for me.  I want them to go to
>different people.  In fact, I want bounces to just go to /dev/null :-)

bounces to /dev/null is a fine option, but you still need to do some 
bounce processing. Bandwidth isn't free or infinite, and while small 
lists may not seem like big deals, it adds up. (I ran a mailing last 
week that generated a 200 megabyte bounce file. I'm still processing 
bounces out of it, five days later -- but we're finally trying to 
catch up and clean up a lot of deferred bounce mail. It really starts 
to add up...)

>  > 13) integrated bounce processing system.
>
>I run a number of mailing lists for people in the telecom world and they
>all seem to use mail systems with odd and/or broken bounce mechanisms.

This can be an amazing pain. It gets even worse when your audience 
goes global, as mine does, and the error messages get translated into 
languages other than English.

One thing I hope to do at some point is integrate support for 
smartbounce into mailman, since it's great at handling this stuff 
(it's just not free, so it can't be the default). And an upcoming 
version of smartbounce will fully support verped email. Verping is a 
huge plus here, and frankly, I think it's more and more important to 
make sure the user knows what address the mail is being sent to, 
since so many folks are using forwarders, multiple addresses, and all 
sorts of things they can't keep track of easily. This is something 
I'm currently implementing into my big server.

(IMHO, the MLM ought to put the address into the "To:" field for 
lists where reply-to-list is disabled. If reply-to is set to the 
list, it's arguabl whether the to: *still* ought to be the user (with 
a reply-to field), or whether it ought to be the list. IMHO, I'd set 
it up so the To: points to the user under all circumstances, and 
reply-to is used to coerce replies if that's what people want (and 
frankly, they rarely should. But that's a different argument). I 
think that's the cleanest interpretation of the RFCs, also.

This implies VERP, of course, since you have to individualize every 
message, but I think it's worth it. you can customize unsub and admin 
links, all sorts of stuff to make life easier for the user (and by 
definition, the admin, who then only has to deal with really bizarre 
cases and the walking braincramps).

>I default users to MIME digests for this reason.  Things work pretty
>well.  I only switch someone to plain digests if they use a broken
>mailer.

Smart move -- over the last six months, users have moved pretty much 
en-masse to html/mime enabled clients (I've also seen 4.X browsers 
finally take over from earlier versions as well). There are still 
pockets of older stuff you can't ignore, but it's no longer a 
majority case that people can't use it or don't want it. We did a 
subscriber survey recently to see (among other things) whether there 
was interest in HTML-based versions of our mailings, and 80% of our 
users were in favor of it. And we're now doing it (both HTML and 
plain-text as separate mailings -- in this case, 
multi-part/alternative isn't the right way to go, because we've found 
if they support mime, they want HTML, and if they don't support mime, 
alternative makes life worse. And it helps those that have mailers 
that use MIME, but don't want HTML -- but that's a tiny number..)

>I think this is a major issue.  I'd love to see it detach all
>attachments, store them in a directory somewhere, and replace them with
>URLs to the stored files.

I know someone who did that for a netnews feed -- automatically grab 
all of the binaries, put them together, stuff them into an HTTP 
server, and rewrite the messages with links instead of all that 
garbage. Very nice, but not trivial. But that's where I think the 
archives need to head over time.

>  > 2) It's in Python: but I guess it's time to learn a new 
>programming language...
>
>I feel the same way!

By the way, this isn't a criticism of Python -- I've already gone 
over the first intro book, and it looks ike a great language. but 
just waht I need, to spend a few weeks learning it... Not that I have 
anything else to do...

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui at plaidworks.com)
Apple Mail List Gnome (mailto:chuq at apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"