[Pkg-mlmmj-devel] Bug#622621: missing/incomplete documentation
Alexander Zangerl
az at debian.org
Wed Apr 13 12:58:38 UTC 2011
Package: mlmmj
Version: 1.2.17-2
Severity: normal
during a recent list conversion to mlmmj i've run into a number of
issues where the mlmmj documentation isn't complete, missing or incorrect.
* README.listtexts
is completely missing from the package; looks like upstream put it
on the website but not in the vcs.
README.listtexts doesn't mention that texts are read not just
from the listdir - but also from /usr/share/mlmmj/text.skel/default
and /usr/share/mlmmj/text.skel/en: the first existing text file of
a given name will be used.
README.listtexts doesn't mention that most of the substitutions
don't work across the board; for example, $maxmailsize$ isn't expanded in
either help or faq text, $originalmail$ isn't available during
subscription moderation and so on.
this needs to be fixed; ideally all substitutions should work
everywhere (minus where there isn't any context, e.g. $originalmail$
for help or faq), but until then the README file should at least spell out
what works where (see 'data' arg to prepstdreply() in mlmmj-*.c).
* README and delimiter
coming from other mailinglist software it's not obvious why
mlmmj is interested in the local/part delimiter in email addy's
- most other list managers use separate addresses.
README should mention that mlmmj uses listname+allkindsofthings at domain
to distinguish between functions, and that listname+* must be routed to
mlmmj-recieve.
* TUNABLES
the footer mechanism isn't mentioned anywhere except in the main README;
it should be briefly mentioned somewhere near the customheader
explanation.
mention that the customheaders file mustn't contain any blank lines,
or the headers of your outgoing mail will be wrecked (the blanks
aren't removed, dumpfd2fd.c doesn't have the smarts and
do_all_the_voodo_here() doesn't help it along either).
for delheaders it's even worse: a blank line there will REMOVE
ALL HEADERS! (findit() in do_all_the_voodo_here.c happily says
match because strncasecmp with n=0 always matches).
* sendmail and headers:
the default program mailer doesn't provide a Return-Path,
but mlmmj can't live without one (with other mtas it uses SENDER from the
environment, but sendmail doesn't provide that either).
how to make the shell mailer send a return-path is hidden too well in
README.sendmail (=as an aside while discussing the verp hack); it should
be stated more prominently. I'm thinking of something like this,
before the verp hack:
Sendmail + mlmmj:
-----------------
mlmmj needs the Return-Path header, and sendmail's program mailer
doesn't include that by default.
You'll need to add the following to /etc/mail/sendmail.mc,
make sendmail.cf and reload sendmail:
dnl make mlmmj happy: add return-path header
define(`LOCAL_SHELL_FLAGS',`eu9P')dnl
* verp
the TUNABLES implies (to me at least) that verp isn't used unless
asked for, but that's not correct: by default (= without control/verp),
mlmmj simply sends one mail per conversation and does the verp "by hand".
mlmmj does only use a static envelope from if staticbounceaddr is set.
the TUNABLES entry on verp should state that it enables *mta-based*
verp where possible, and that without staticbounceaddr mlmmj does verp
by hand.
* verp and sendmail
README.sendmail shows a complex hack for making sendmail offer verp,
but it doesn't state anywhere that verp "by hand" works just fine.
the hack also embeds list configs in the sendmail.mc, and as given doesn't
work for more than a single list on this host (the regex map is
very specific).
because of this limitation and the fact that "manual" verp works just fine
i believe the hack should be labelled optional - right now the
(incorrect) explanation of verp in TUNABLES plus the README.sendmail
implies that you have to hack up your sendmail to get verp
going at all, which isn't true.
* mlmmj-maintd
manpage doesn't mention the fixed sleep time (7200s) between runs when
in daemon mode.
* mlmmj.operation.log
nothing ever mentions that some mlmmj operations will be logged in
the list dir, in mlmmj.operation.log. (but then the logging situation
in mlmmj is pretty dire anyway.)
that's it for now; i've given this severity=normal because i think some
of those missing info bits affect a smooth deployment of mlmmj quite badly.
regards
az
More information about the Pkg-mlmmj-devel
mailing list