Tim Willson wrote:
If I set Non-digest options/"Scrub attachments of regular delivery message?" to Yes my archived messages URL's have an extra = in the URL string at the end of line one and a line break making the URL 2 lines and non-clickable. <snip>
-------------- next part -------------- A non-text attachment was scrubbed... Name: Official notice Spam Filtering Implementation Update 09030.pdf Type: application/octet-stream Size: 76382 bytes Desc: not available Url : <http://www.mn.us/pipermail/listname/attachments/20050901/2d8=> eb35e/OfficialnoticeSpamFilteringUpdate09030.pdf
This was at some point a quoted-printable encoding. I don't know where the '>' at the end of the first line came from, but in quoted-printable speak the '=' at the end of the first line of
Url : <http://www.mn.us/pipermail/listname/attachments/20050901/2d8= eb35e/OfficialnoticeSpamFilteringUpdate09030.pdf
means "there is really no line-break here - join this line to the next".
I've looked at Mailman/Handlers/Scrubber.py, and it doesn't put angle brackets ('<', '>') around the urls. I don't know where they are coming from, but I don't think Mailman is doing it.
Likewise, Scrubber.py does not produce a quoted-printable encoded message. It produces a message with Content-Transfer-Encoding: 8bit.
So it looks like somewhere in the outgoing MTA path, an MTA is converting 8bit to quoted-printable which is changing
Url : http://www.mn.us/pipermail/listname/attachments/20050901/2d8eb35e/Officialno...
to
Url : http://www.mn.us/pipermail/listname/attachments/20050901/2d8= eb35e/OfficialnoticeSpamFilteringUpdate09030.pdf
and then somewhere further along, something is not correctly interpreting the quoted-printable encoding - perhaps the thing which is putting the angle brackets around the http://www.mn.us/pipermail/listname/attachments/20050901/2d8= part.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan