On Sat, Nov 24, 2012 at 12:13 PM, Ian Lance Taylor <i...@airs.com> wrote: > Diego Novillo <dnovi...@google.com> writes: > >> Sure. First I wanted to find out whether this requirement is just a >> technical limitation with our mailing list software. > > It is not a technical limitation. We explicitly reject HTML e-mail. We > could accept it. > > As Jonathan pointed out, accepting HTML e-mail and then displaying it in > the web archives will make us even more of a spam target than we already > are, and will mean that we will need some mechanisms for identifying and > removing spam and virus links in the web pages.
I'd love to see data on this. As others have pointed out, almost every other open source project accepts html email. I went through, for example, the LLVM email archives, and i don't see a massive amount of spam. Do you have reason to believe our existing spam detection solution will start to fail massively when presented with html email? After all, if most of the HTML email is spam, something being HTML email is a great signal for it. > > A possible compromise would be to accept HTML e-mail that has a text > alternative, and only display the text alternative in the archives. > That would also work for people who have text-only e-mail readers. In > general that would help for people who use e-mail programs that send > HTML with text alternatives by default. But it would fail for people > who actually use HTML formatting in a meaningful way. I have not seen html formatting used in the other open source projects, just text/html emails. > And, of course, > this would require some administrative work to be done. > > I don't really care one way or the other on this issue. That said: > > 1) People who send HTML e-mail ought to get a bounce message, so I would > think they would be able to reform. At that point they probably don't care. Honestly, any community that actively makes it hard for me to send mail from a common email program, is a huge turn-off. Folks can retort that we may not want users who don't want to take the time to send non-html email. I doubt this is actually true, since the majority of folks i've seen are just using clients that default to html email, and aren't doing anything obnoxious. Note that *we* are currently rejecting multipart/alternative if it contains text/html, even if it contains text/plain. This is fairly obnoxious. > 2) The fact that Android refuses to provide a non-HTML e-mail capability > is ridiculous but does not seem to me to be a reason for us to change > our policy. Expect it to get worse. Folks can say what they like, but other communities i'm a part of, and are much larger than GCC, deal with HTML email with zero problem. All bouncing HTML email is really doing is turning away some people. In the "olden days", when html email was some shitty gobbledygook produced by an old version of exchange, this may have made sense. In the days now of relatively sane multipart/alternative emails, it just seems like folks being annoyed that the rest of the world changed. > > Ian