You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by RW <rw...@googlemail.com> on 2016/04/01 00:33:00 UTC
Re: HEADS-UP: MIME_NO_TEXT matches Sendmail MIME DSNs
On Thu, 31 Mar 2016 17:56:21 -0400
Kevin A. McGrail wrote:
> On 3/31/2016 1:34 PM, RW wrote:
> >
> > They have something like:
> >
> > Content-Type: text; charset="utf-8"
> >
> > rather than
> >
> > Content-Type: text/plain; charset="utf-8"
> >
>
> I think you found a bug in sendmail (or something munging things
> along the way.)
No, this is in spam.
The FPs from sendmail are caused by it relying on its visible text
being implicitly text/plain rather that having a Content-Type header.
Re: HEADS-UP: MIME_NO_TEXT matches Sendmail MIME DSNs
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
On 3/31/2016 6:33 PM, RW wrote:
> On Thu, 31 Mar 2016 17:56:21 -0400
> Kevin A. McGrail wrote:
>
>> On 3/31/2016 1:34 PM, RW wrote:
>>> They have something like:
>>>
>>> Content-Type: text; charset="utf-8"
>>>
>>> rather than
>>>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>> I think you found a bug in sendmail (or something munging things
>> along the way.)
> No, this is in spam.
>
> The FPs from sendmail are caused by it relying on its visible text
> being implicitly text/plain rather that having a Content-Type header.
Sorry, I didn't realize you were describing two issues.
But I'd also interpret the behavior you describe from RFC 2405 since
US-ASCII would be the default Charset. I'm not sure the details of the
problem but if it is missing the header or syntactically invalid,
assuming it's plain US-ASCII looks right.
5.2. Content-Type Defaults
Default RFC 822 messages without a MIME Content-Type header are taken
by this protocol to be plain text in the US-ASCII character set,
which can be explicitly specified as:
Content-type: text/plain; charset=us-ascii
This default is assumed if no Content-Type header field is specified.
It is also recommend that this default be assumed when a
syntactically invalid Content-Type header field is encountered. In
the presence of a MIME-Version header field and the absence of any
Content-Type header field, a receiving User Agent can also assume
that plain US-ASCII text was the sender's intent. Plain US-ASCII
text may still be assumed in the absence of a MIME-Version or the
presence of an syntactically invalid Content-Type header field, but
the sender's intent might have been otherwise.
Regards,
KAM
Re: HEADS-UP: MIME_NO_TEXT matches Sendmail MIME DSNs
Posted by John Hardin <jh...@impsec.org>.
On Thu, 31 Mar 2016, RW wrote:
> On Thu, 31 Mar 2016 17:56:21 -0400
> Kevin A. McGrail wrote:
>
>> On 3/31/2016 1:34 PM, RW wrote:
>>>
>>> They have something like:
>>>
>>> Content-Type: text; charset="utf-8"
>>>
>>> rather than
>>>
>>> Content-Type: text/plain; charset="utf-8"
>>
>> I think you found a bug in sendmail (or something munging things
>> along the way.)
>
> No, this is in spam.
>
> The FPs from sendmail are caused by it relying on its visible text
> being implicitly text/plain rather that having a Content-Type header.
How many other point do those messages score? Would having another point
or two from this standards violation push them over the top, or are they
already obviously spammy?
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Vista: because the audio experience is *far* more important than
network throughput.
-----------------------------------------------------------------------
Tomorrow: April Fools' day