On 12-Jul-17 12:39, Mark Sapiro wrote:
Also, with respect to Mailman 2.1, if you want the scrubber to preserve file names and extensions, set the following in mm_cfg.py
SCRUBBER_DONT_USE_ATTACHMENT_FILENAME = False SCRUBBER_USE_ATTACHMENT_FILENAME_EXTENSION = True
and if you want scrubbed HTML to not be HTML escaped so it renders rather than looking like raw html, set
ARCHIVE_HTML_SANITIZER = 3
but note this comment from Defaults.py
# 3 - Remove text/html as attachments but don't HTML-escape them. Note: this # is very dangerous because it essentially means anybody can send an HTML # email to your site containing evil JavaScript or web bugs, or other # nasty things, and folks viewing your archives will be susceptible. You # should only consider this option if you do heavy moderation of your list # postings.
This is an issue with HyperKitty as it appears this is what HyperKitty does and there's no way to turn it off.
This warning seems a bit dated, though it's not completely wrong. It comes from the days when HTML was new, browsers were fragile, and javascript treated with suspicion. And virus/spam scanners for email were non-existent.
Today, it's a very rare website that doesn't rely on javascript (Postorious and Hyperkitty use JS). Browsers, while they still have bugs, are much more defensive. And there are plenty of truly evil sites that they have to defend against.
It is certainly true that archived e-mail can turn your site into an unknowing distributor of malware: FLASH bugs, documents with embedded buffer overflows, cross-site scripting and the other many ills of the day. Wikis deal with this frequently.
However, in these cases, your mailing list has distributed the same bits to your subscribers - a community that you probably care more about than a random visitor to your (open) archive.
I wouldn't run a list - public or private - where the traffic doesn't go through SPAM and virus filtering before Mailman sees it. (SpamAssassin and ClamAV are good open-source solutions.) And once you've done that (and Mailman 3's optional DMARC), most of these attacks are defanged/mitigated. This is essentially automated moderation - to a point.
Note that all the Djano authentication schemes packaged with Mailman (facebook, google, etc) rely on javascript and are sites littered with what the comment refers to as "webbugs" - Google Analytics, tracking cookies, browser fingerprinting, 0 size images (the original webbug). They make money (and have become mainstream) using technologies that were considered anti-social when that warning was written. (Personally, I still think of them as anti-social, but the public has chosen to pay for services with privacy...)
While some may elect to stick with the highly restrictive policies of "plain text only", this limits the information content and applicability of the the platform. Whether this is acceptable depends on the community that you serve. Mailman can be an effective mechanism to deliver rich media on a "push" basis. And that's "rich" by 1980 standards (bold, well-formatted tables, an attached agenda or document package); not even "rich" by today's (sleeping cat videos...).
I think that Mailman has to be able to handle today's rich media with a reasonable degree of safety and convenience. Including in the archives. I thought that was one of the goals for Mailman Version 3...
I also think that the advice quoted above should be modified to better reflect these realities. Mailman isn't the only tool available to protect users from evil content, and aggressively filtering to plaintext is a very blunt instrument. Including anti-spam, anti-virus, DNS blacklisting, DKIM/DMARC tests in the delivery pipeline (most of which can be/is done before Mailman touches a post) should be strongly recommended.
Checks for headers indicating checked-by local (anti-spam/anti-virus) agents should be available in the Mailman rulesets (and require some cooperation from the MTA to ensure that they can't be passed through from outside.)
There is nothing wrong with running a plain text only site, if it serves your community. But if Mailman wants to be relevant in today's environment, it has to adapt to rich content as more than an unwelcome guest. (As I have :0)