Re: Archiving HTML mail

[Eric Wong <e@80x24.org>]

Florian Weimer <fw@deneb.enyo.de> 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.