From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,BAYES_00 shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 6B5841F4B5; Tue, 12 Nov 2019 21:53:07 +0000 (UTC) Date: Tue, 12 Nov 2019 21:53:07 +0000 From: Eric Wong To: Florian Weimer Cc: meta@public-inbox.org Subject: Re: Archiving HTML mail Message-ID: <20191112215307.GA20307@dcvr> References: <87r22ddxly.fsf@mid.deneb.enyo.de> <20191112210923.GA9729@dcvr> <874kz8eqwf.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <874kz8eqwf.fsf@mid.deneb.enyo.de> List-Id: Florian Weimer wrote: > * Eric Wong: > > text/html is currently shown inline as raw HTML since > > https://public-inbox.org/meta/20191031031220.21048-2-e@80x24.org/ > > But maybe the HTML part shouldn't be shown inline at all in > > multiparts parents. > > Yeah, there's some concern that this could be used to host phishing > forms. I've seen this occasionally in the Debian mailing list archive > (where anti-phishing companies tend to report them several years later > to security@). Those should've been caught by spam filters, first; but if they weren't, public-inbox-learn can be used to remove them from the WWW/NNTP viewers (w/o breaking git history) and train SpamAssassin. > My feeling is that it would need some post-processing, maybe stripping > image links and forms (and Javascript of course). Plus the separate > domain thing for additional XSS protection (like bugzilla.mozilla.org > does, IIRC). But presumably you could put the entire list archive > under its own domain to avoid having to write code for that. That would mess up DKIM verifications if somebody is trying to verify archives. Having separate domains seem to work alright depending on how nginx/varnish (or similar) is setup, and I host http://ou63pmih66umazou.onion/ and several other non-onion domains on the same -httpd process as https://public-inbox.org/ (and I have some plans for better multi-domain support). > > FWIW, I suggest keeping your lists text-only so contributors can > > flow between different projects more easily and not get blocked > > by spam filters. It's significantly more expensive to do spam > > processing on HTML mail and less accurate IME. Better to teach > > contributors to optimize for low-end computers and limited > > bandwidth situations :) > > While this is true, it is also a bad experience for those who send > their first email (which may be a huge step for some, I completely > lack perspective there), and then it gets rejected with an obscure > message. It's also very confusing if Cc:s are involved and everyone > but the mailing list gets the message. The MTA could be made to show a better message. At least PublicInbox::Filter::Base tries to with: *** We only accept plain-text mail, No HTML *** At least postfix shows puts the above in the rejection message. > In some clients, it's now impossible to switch of HTML mail (but I > don't know which variant, whether that's HTML-only, or whether there's > still a client-generated text/plain alternative). AFAIK, the Android Gmail client was one. But I'm really against corporations dictating formats and complexity like that. Free software hackers should keep fighting for simple, inexpensive formats and pressure Google et. al into supporting them. > > Also, public-inbox-watch is designed to work in parallel with > > existing mailing lists. I archive several lists (including > > libc-alpha@sourceware and git@vger) this way with no special > > permissions or access aside from being a regular subscriber. > > I feel we need to change libc-alpha to accept text/html email. Given there's some cross-posting to vger lists which reject HTML, that could do more harm than good. My goal is not just to get hackers into using plain-text mail, but having them influence non-hackers into using plain-text mail, too.