[Mailman-Users] Is it OK to unshunt "bad" messages?

[Mark Sapiro]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sebastian Hagedorn wrote:
|
| --On 25. April 2008 09:21:12 -0700 Mark Sapiro <mark at msapiro.net> wrote:
|>
|> I'm guessing that you are running Mailman 2.1.10 with the patch from
|> <http://mail.python.org/pipermail/mailman-users/2008-April/061360.html>,
|> since there's little else these days that would put anything in the
|> 'bad' queue.
|
| No, it's 2.1.9 with two patches you sent me a few weeks ago.
|
|> Did the file have a .psv extension?
|
| No, it was a .pck file. I found this entry in the vette log:
|
| (3438) Message discarded, msgid: <c39b437d2808.47ee2e26 at wmich.edu>


This should have nothing to do with anything in the 'bad' queue. This
message is logged when a handler decides to discard an incoming post,
e.g. a post from a non-member in discard_these_nonmembers or any other
condition with a discard action.


| Then I read this comment in Defaults.py:
|
| # When a message that is unparsable (by the email package) is received,
| what
| # should we do with it?  The most common cause of unparsable messages is
| # broken MIME encapsulation, and the most common cause of that is
| viruses like
| # Nimda.  Set this variable to No to discard such messages, or to Yes to
| store
| # them in qfiles/bad subdirectory.
| QRUNNER_SAVE_BAD_MESSAGES = Yes
|
| So I guess that's what happened, although the log line "message
| discarded" is a bit misleading. BTW, is there a reason why the list a
| message was addressed to isn't logged when messages are discarded?


That setting in Defaults.py and the qfiles/bad directory have not been
used by anything other than the bin/update script for a long time (since
2.0.x I think). I just resurrected them in the 2.1.10 patch I posted
this week.

How old was the file you unshunted or how old was the message in it?

The list isn't logged in the case of a 'qfiles/bad' entry because some
error prevents the original entry from being properly read so we can't
get all the nice information like what list it was for.

The list name isn't logged in the case of the vette log entry, because
whoever created that code didn't think it would be useful or just didn't
think to do it (You could find the message-id in the MTA log if you
really wanted to know the list). Changing long standing log messages is
not something to be done lightly as it potentially breaks peoples log
analysis tools.


|> You should really look in the 'error' log to see the message associated
|> with preserving the entry.
|
| There was nothing in "error", only that line in "vette".


This is not surprising given that this is Mailman 2.1.9, as I think that
means the message must have been quite old.


|> The main problem with unshunting a message from the 'bad' queue (other
|> than having to change the extension from .psv to .pck or .bak) is that
|> true shunted messages have an item in the metadata indicating the
|> original queue. Preserved messages in the 'bad' queue don't have this,
|> so they will be unshunted to the 'in' queue by default, which may not be
|> correct - e.g. they may have come from the bounce queue.
|
| But that should be obvious after looking at it with show_qfiles, right?


In that example, yes, but not necessarily if it came from the 'out' or
'archive' queues. At least in these cases it would be more subtle, and
you might need to see the metadata which show_qfiles doesn't show you
(but dumpdb does).

- --
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)

iD8DBQFIEhHrVVuXXpU7hpMRAlMtAKD19MKheItlXE9LM/xQd7GkctsvjwCbBBQk
ng4WZlj0GkijdRMc9uDeWA0=
=bvB1
-----END PGP SIGNATURE-----