Re: Supporting multipart/alternative email with text/plain parts.

["Carlos O'Donell" <carlos at systemhalted dot org>]

On Mon, Mar 5, 2012 at 2:18 PM, Thomas Schwinge <thomas@codesourcery.com> wrote:
> > The sourceware.org ezmlm-idx configuration for this mailing list
> > does not allow text/html email.
>
> For uniformity, I think we should have the same setting for all mailing
> lists.

I have no comment on this.

> > I have been contacted by people who would like to volunteer and
> > participate on this list but are currently sending multipart/alternative
> > emails (text/html and text/plain) and being rejected by the
> > mailing list software.
> >
> > In a desire to see volunteers of every kind participate in the
> > community I have reached out to overseers to change the ezmlm-idx
> > configuration to support multipart/alterjative where there is a
> > minimum of a text/plain part in the alternatives list.
> >
> > This would allow broader support for:
> >
> > * volunteers who are using the default GMail setup which sends
> > multipart/alternative with both text/html and text/plain portions.
> >
> > * volunteers who genuinely like formatted email.
>
> I agree that we should allow the kind of email you describe.

I'm glad you agree.

I count two strong agreements, which is good to see.

> > Just to clarify, the list itself will only record and mail out the
> > text/plain part of the incoming email.
>
> However, I'm not a fan of email munging by mailing list software.
> Parsing and recombining complicated MIME data structures is always
> error-prone. ?Either pass it through unmodified, or reject it. ?What's
> the concern here? ?Some extra bits of traffic?

Given that I'm not the person who set the policy of rejecting
text/html email; I can't comment on the reasons. Perhaps someone on
this alias can answer that question?

Personally I would not have rejected any email, allowing the
submitters to use their own filtering software to remove spam and
unwanted submissions (end-to-end principle). However, I understand
that rejecting text/html email makes certain administrative aspects
easier e.g. less spam, less storage space requirements etc.

Please keep in mind that the true goal is to enable participation by
more volunteers.

Cheers,
Carlos.