But you are of course right: having a text/plain part that just tells you to see the HTML part defeats the entire point of multipart MIME; it'd be better even to just have no text/plain parts compared to having one that is useless.
For that matter, I wonder if the e-mails in SE2 are any better?
]]>I suppose the main bayesian problem is the text/plain part of the email is too short and including the markdown source as text/plain will fix the issue.
]]>I am not exactly sure how MO can change the software (assuming we can even do that) to evade all Bayesian SPAM filters, since that heavily depends on how a user/sys-admin trains the filter....
]]>FYI: Got email notification which was marked as spam by the widely used anti spam software spamassasin.
Here is the log:
From: MathOverflow <info@mathoverflow.net>
Subject: *****SPAM***** 1 Question Has 1 Answer - MathOverflow
X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02)
X-Spam-Status: Yes, score=9.3 required=6.2 tests=BAYES_99=6.1,HTML_MESSAGE=1.8,
MIME_QP_LONG_LINE=1.396 autolearn=no version=3.2.1
X-Spam-Report:
* 6.1 BAYES_99 BODY: Bayesian spam probability is 99 to 100%
* [score: 0.9963]
* 1.8 HTML_MESSAGE BODY: HTML included in message
* 1.4 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars
I can live with this and don't complain, but more aggressive spam settings might bury the email deeper.
]]>