[Mailman-Developers] Various mailman bugs (all in 2.0beta2 under HPUX 10.20)

[Lenny Foner]

[Please keep me CC'ed on any responses.  Thanks!]

I've just started using Mailman, and, while it's quite a nice little
package, I've already tripped over a number of bugs.  I've listed them
approximately in order from most severe to least severe below; I've
fixed 3 & 7-11 myself, but 1 & 2 require someone with at least a
passing familiarity with Python and Mailman's internals, and of course
they should all wind up in the current source tree.

I also spent a while poking at the Jitterbug interface, and concluded
that it wasn't likely that I'd be able to figure out which category
each individual bug should go into, or that it would save anybody any
time for me to try to stick them in the interface in the first place.
It's also incredibly painful to submit bugs by filling in web forms,
because the editing environment available is so poor.  Having the
forms used by Jitterbug also allow file uploading (when supported by
the browser, which most do) would help, but aren't a complete solution.

(1) Mailman doesn't send error reports to the right place.  Our setup
here has individual workstations, such as foo.media.mit.edu,
masquerade such that their mail headers are rewritten to appear to
come from media.mit.edu (which forwards mail to our main mail-handling
machine, and also has an MX pointing there).  This is usually how
large sets of machines are set up everywhere.  But when I was trying
to configure Mailman (with the wrong compiled-in GID [it wasn't clear
to me whether it was the webserver's GID or sendmail's GID that was
the right one], hence any request caused the wrapper to err), Mailman
evidently went out of its way to attempt to send the error mail to the
individual workstation, e.g., foo.media.mit.edu, and -not- to
media.mit.edu, which is what the From: address in the incoming mail to
Mailman specified and which should be respected in any event---From:
should -always- take precedence over some attempt to divine a better
address.  After all, Mailman cannot possibly have a better idea of
which machine is handling mail for the sender than the sender itself
does.  (This meant, btw, that the error mail simply got wedged in the
sendmail queue of the machine I'm running Mailman on, since individual
workstations here don't listen to SMTP requests.)

(2) Sending a message with no subject and no body to listname-request
causes the blank message to simply arrive at the admin address.  I
contend that it would be far nicer to the users -and- the administrator
if a blank message acted like one with "help" in it.  Otherwise, users
see a black hole (until the admin responds), and admins need to deal
with responding in a way that gets users to ask "help" anyway, most
likely.  It's just a pain all around.

(3) mailman-2.0beta2/Mailman/Archiver/HyperArch.py puts the URL
http://starship.skyport.net/crew/amk/maintained/pipermail.html
into the footer of its page describing the message archives,
but this is a dead link.  (I just commented out the footer entirely.)

(4) Feature request:  Mailman should support a --with-default-url as a
build argument so it can use cnames and/or virtual hosts.  Ditto for
the FQDN of the host.  I had to go in and screw around with various
options files to get this set up correctly after Mailman guessed; why
make the user edit this instead of taking it as an arg?  (Yes, I know
you can change it one list at a time in the admin web interface, but
the default should be right, too.)

(5) The doc says to run "make install" in at least 2 places, but never
says to actually run "make" anywhere.  But you -do- have to do a make :)

(6) Should I be creating mailman-owner or owner-mailman as aliases?
The doc is inconsistent, so I did both.  Is this specific to the MTA?
If so, you should figure it out and document it for common ones.  (I'm
using sendmail 8.9.3.)

(7) Even if the list administrator has disabled monthly password
mailings, templates/convert.txt and templates/subscribeack.txt both
claim that users' passwords will be mailed to them monthly (in fact,
the latter seems to say the same thing twice, in both the last and
penultimate paragraphs).  There should be some way for these templates
to check the current setting for the list, and to fail to include this
text if monthly reminders are turned off.  Mailman/HTMLFormatter.py
appears to make this check correctly, though I'm not positive that it's
generating the page I think it is.  [I find monthly password reminders
absolutely pernicious---after all, if I forget the password, I can
-ask- for it and get an instant response from the server anyway.  And
this way, I don't have the extra traffic, my password doesn't get
sent more than it has to over insecure channels, and very low-volume
lists don't send me mostly password-reminder traffic instead of
blessed silence.]

(8) Three's some bad formatting in the help page returned by sending a
"help" request to listname-request, apparently caused by linewrapping
performed by Utils.wrap (in Mailman/Utils.py)---Utils.wrap defaults to
70 columns wide, but the template text in template/help.txt has lines
longer than this (as do a couple of other calls from elsewhere in the
source code which call Utils.wrap on a fixed string; these are less
objectionable, in general, because the constant text isn't also
indented).  The end result looks pretty awful:

	end or --
	   Stop processing commands (good to do if your mailer
    automatically
	   adds a signature file - it'll save you from a lot of cruft).

should be

	end or --
	   Stop processing commands (good to do if your mailer automatically
	   adds a signature file - it'll save you from a lot of cruft).

and

	    unsubscribe from a different address than the one you
    subscribed
	    from, you may specify it in the 'address' field.

should be

	    unsubscribe from a different address than the one you subscribed
	    from, you may specify it in the 'address' field.

I've fixed this by changing the default in Utils.wrap to 78
characters, which is half-baked but works.

(9) Mailman/Handlers/Hold.py spells administrivia as adbministrivia instead
(there shouldn't be a "b" in that word...)

(10) Mailman/Cgi/admindb.py's default textbox message that says
"Please do *not* post administrative requests to the list!" has a
repeated "the" in the next sentence, so it talks about "the the
request address".  (The two "the"'s are separated by a newline in the
source, which makes this harder to see.)  I removed the repeat and
also changed the first sentence to "Please do not post administrative
requests to the list." (no *, no !) so it seems less like the admin is
yelling at the poor user.

(11) templates/subscribeack.txt puts an extra newline before "You" in
the normal (non-umbrella) case in:

      %(optionsurl)s
    %(umbrella)s
    You can also make such adjustments via email by sending a message to:

which I've fixed simply by doing

      %(optionsurl)s %(umbrella)s
    You can also make such adjustments via email by sending a message to:

but this also requires putting the right number of newlines into the
string in Deliverer.py which generates the string in umbrella.  Since
I can't easily test it, I didn't bother fixing that.

(12) It would be less confusing if the "details" page for various
configuration stuff didn't say "don't change it here---change it on
the previous page" or whatever.  Either make the form active on the
details page, or don't make it a form at all.  This wasn't a problem
for me, but I imagine it will be for others.  (Yes, I understand it's
easier to be able to reuse the code that generates the form this way,
but surely it can't be that hard to modularize.)