You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Joseph Brennan <br...@columbia.edu> on 2018/01/09 15:56:19 UTC
FSL_MIME_NO_TEXT and MIME_NO_TEXT
Both FSL_MIME_NO_TEXT and MIME_NO_TEXT are very similar. Both look for a
multipart/mixed message with no "text/" part that has an attachment.
Combined score is just under 5. That's a lot.
The case in point is an application that sends a report to a few people as
a plain text document, and the only mime part is the attachment, which is
called application/octet-stream and has a .txt file extension. I feel like
this should count in __ANY_TEXT_ATTACH.
I think "multipart/mixed" allows a message with one part. Using
"application/" causes clients to treat a part as an attachment, and I think
the generic "octet-stream" is correct since there is no specific software
that must be used for a plain text file. (I'm actually surprised that there
is nothing like application/plaintext for this case, but I could not
identify such a type in a web search.)
Comments?
--
Joseph Brennan
Columbia University
Re: FSL_MIME_NO_TEXT and MIME_NO_TEXT
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 9 Jan 2018, at 13:47 (-0500), Matus UHLAR - fantomas wrote:
> this is a real duplicity...
Semantic note: "duplication" or "redundancy," NOT "duplicity," which is
English for the flavor of dishonesty involving contradictory statements.
--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steady Work: https://linkedin.com/in/billcole
Re: FSL_MIME_NO_TEXT and MIME_NO_TEXT
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>On 09.01.18 10:56, Joseph Brennan wrote:
>>Both FSL_MIME_NO_TEXT and MIME_NO_TEXT are very similar. Both look for a
>>multipart/mixed message with no "text/" part that has an attachment.
>>Combined score is just under 5. That's a lot.
>>
>>Comments?
On 09.01.18 19:43, Matus UHLAR - fantomas wrote:
>meta FSL_MIME_NO_TEXT (__CTYPE_MULTIPART_MIXED && !__ANY_TEXT_ATTACH_DOC)
>
>meta __MIME_NO_TEXT (__CTYPE_MULTIPART_ANY && !__ANY_TEXT_ATTACH)
>
>meta MIME_NO_TEXT __MIME_NO_TEXT && !__BOUNCE_CTYPE &&
> !__CT_ENCRYPTED && !ALL_TRUSTED && !__MSGID_APPLEMAIL &&
> !__USER_AGENT_APPLEMAIL && !__HAS_IN_REPLY_TO && !__HAS_X_REF &&
> !__HS_SUBJ_RE_FW && !__LCL__ENV_AND_HDR_FROM_MATCH
btw:
mimeheader __ANY_TEXT_ATTACH Content-Type =~ /text\/\w+/i
mimeheader __ANY_TEXT_ATTACH_DOC Content-Type =~ /text\/\w+/i
this is a real duplicity...
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Emacs is a complicated operating system without good text editor.
Re: FSL_MIME_NO_TEXT and MIME_NO_TEXT
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
On 09.01.18 10:56, Joseph Brennan wrote:
>Both FSL_MIME_NO_TEXT and MIME_NO_TEXT are very similar. Both look for a
>multipart/mixed message with no "text/" part that has an attachment.
>Combined score is just under 5. That's a lot.
>
>Comments?
meta FSL_MIME_NO_TEXT (__CTYPE_MULTIPART_MIXED && !__ANY_TEXT_ATTACH_DOC)
meta __MIME_NO_TEXT (__CTYPE_MULTIPART_ANY && !__ANY_TEXT_ATTACH)
meta MIME_NO_TEXT __MIME_NO_TEXT && !__BOUNCE_CTYPE &&
!__CT_ENCRYPTED && !ALL_TRUSTED && !__MSGID_APPLEMAIL &&
!__USER_AGENT_APPLEMAIL && !__HAS_IN_REPLY_TO && !__HAS_X_REF &&
!__HS_SUBJ_RE_FW && !__LCL__ENV_AND_HDR_FROM_MATCH
score FSL_MIME_NO_TEXT 3.274 1.728 3.274 1.728
score MIME_NO_TEXT 1.726 1.999 1.726 1.999
why the rest of comments is correct, this is imho a good example where
similar rules that should not have that big combined score.
looking at those scores, one of those rules should be removed, or at least a
meta should be created, lowering combined scores (aparently through mass-check)
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Spam = (S)tupid (P)eople's (A)dvertising (M)ethod
Re: FSL_MIME_NO_TEXT and MIME_NO_TEXT
Posted by John Hardin <jh...@impsec.org>.
On Tue, 9 Jan 2018, Kris Deugau wrote:
> Joseph Brennan wrote:
>> The case in point is an application that sends a report to a few people as
>> a plain text document, and the only mime part is the attachment, which is
>> called application/octet-stream and has a .txt file extension. I feel like
>> this should count in __ANY_TEXT_ATTACH.
>
>> (I'm actually surprised that there is nothing like application/plaintext
>> for this case, but I could not identify such a type in a web search.)
>
> Personally, I think anything using "application/octet-stream" for any ASCII
> text anything is Doing It Wrong.
>
> If it's really just pure ASCII text, "text/plain" would be a lot better.
+1 - that application is behaving in a very spammy manner.
Also (making an assumption here), you should probably save processing
overhead by bypassing internal automatically-generated emails in your
glue.
--
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
-----------------------------------------------------------------------
Maxim XXXV: That which does not kill you has made a tactical error.
-----------------------------------------------------------------------
8 days until Benjamin Franklin's 312th Birthday
Re: FSL_MIME_NO_TEXT and MIME_NO_TEXT
Posted by Kris Deugau <kd...@vianet.ca>.
Joseph Brennan wrote:
> The case in point is an application that sends a report to a few people
> as a plain text document, and the only mime part is the attachment,
> which is called application/octet-stream and has a .txt file extension.
> I feel like this should count in __ANY_TEXT_ATTACH.
> (I'm actually
> surprised that there is nothing like application/plaintext for this
> case, but I could not identify such a type in a web search.)
Personally, I think anything using "application/octet-stream" for any
ASCII text anything is Doing It Wrong.
If it's really just pure ASCII text, "text/plain" would be a lot better.
-kgd
Re: FSL_MIME_NO_TEXT and MIME_NO_TEXT
Posted by RW <rw...@googlemail.com>.
On Tue, 9 Jan 2018 10:56:19 -0500
Joseph Brennan wrote:
> Both FSL_MIME_NO_TEXT and MIME_NO_TEXT are very similar. Both look
> for a multipart/mixed message with no "text/" part that has an
> attachment. Combined score is just under 5. That's a lot.
>
> The case in point is an application that sends a report to a few
> people as a plain text document, and the only mime part is the
> attachment, which is called application/octet-stream and has a .txt
> file extension. I feel like this should count in __ANY_TEXT_ATTACH.
more like __ANY_TEXT_ATTACH_DOC, but deliberately disguised text
shouldn't count as text.
> Using "application/" causes clients to treat a part as an attachment,
What's wrong with:
Content-Disposition: attachment; filename=...;