[Mailman-Users] A scrubber issue

[Todd Zullinger]

Hi Mark,

Mark Sapiro wrote:
> There seems to be another issue in that there is no 'link' to the
> scrubbed part, just a relative URL which doesn't work.

Yes, there are other issues with the configuration there.  Click on
the list info link and then follow that to the archives.  You get into
the top level of the public archive dir, seeing a listing of all of
the lists and list mboxes.

However, I created a fresh list on my system to see whether this was a
list configuration issue or not and it's reproduceable using a default
list setup.  I initially thought it must be some over-agressive
content filtering, but after having it work on a virgin list I don't
think that's the case.  There may still be a way to configure the
content filtering to work around this, but I'm not familiar enough
with the various possibilities to know that.

> You are correct in your assessment of why the part is scrubbed in
> the first place. Also, it seems that according to sec 5.2 of RFC
> 2045 we could assume 'us-ascii', but I expect this may cause other
> problems with non-compliant MUAs. Tokio is responsible for a lot of
> scrubber code, and he has a lot of experience with Japanese so I
> suspect there is a reason we do it this way.

I was guessing this might be the case as well.  Hopefully Tokio or
someone else who's intimate with the code can comment on whether
that's the case or not.  It always sucks when the choice is either not
conform to a standard or not work properly in the real world.  I don't
envy the choices you guys have to make when writing email parsing
code.  :)

If it came to it, perhaps there could be an option to be strict about
the parsing for those that would rather conform than be able to handle
all of the junk that people send?  I tend to go this direction when I
configure my MTA's, but I realize this isn't always a viable choice
for others.

> It seems that a good part of the problem in the above referenced
> archive is that the scrubbed attachment is not given a clickable
> link, and in fact the relative path given doesn't even work. I think
> at least part of this must be specific to this site - perhaps a
> (intentionally?) bad value for PUBLIC_ARCHIVE_URL in mm_cfg.py.

I don't think it's related.  My test list created a proper link to the
second message part, but it still scrubbed both mime parts.  If I
added a content-disposition: inline header to the first part, then it
was similarly scrubbed and a link inserted.  Without that header, the
part just disappeared completely.

I can send you config_list output for the test list if you like, but
there weren't any changes made to the config so it should be nothing
but Mailman default.  I don't know what OS the real gnupg-users list
runs on, but my test list was created on Fedora Core 6, using the
packaged mailman rpm there (version 2.1.9).  I don't think there are
significant deviations from Mailman's source other than the FHS patch
that they apply.  If you think it's relevant, I can install from
source and test as well.

Thanks,

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
======================================================================
It is not enough to be busy, so are the ants. The question is: what
are we busy about?
    -- Henry David Thoreau

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
Url : http://mail.python.org/pipermail/mailman-users/attachments/20061208/c08de151/attachment.pgp