http://bugzilla.spamassassin.org/show_bug.cgi?id=3367
Summary: RFE: allow message/rfc822 parts to be ignored for
body/rawbody/full rules
Product: Spamassassin
Version: SVN Trunk (Latest Devel Version)
Platform: Other
OS/Version: other
Status: NEW
Severity: normal
Priority: P5
Component: Libraries
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
moving from bug 3069, since Dan's original bug was fixed -- but this issue is
still open.
quoting the recent comments that discussed only this issue:
Theo:
the more I think about this, the more I think I'd rather leave the
message/rfc822 parts alone. don't
parse into a subtree, etc.
the majority of MUAs don't display automatically, so I don't think spammers are
going to start doing
this en masse. if this starts happening, and users go and open attachments from
people they don't
know (don't they know not to do this due to worms/etc?), there's really no
difference between that and
if spammers start sending doc, pdf, etc spam attachments. we don't scan those
either.
just because there's a spam attachment message, doesn't mean the whole message
should be
considered spam anyway. mailman notification and (imnsho) DSNs are examples of
this -- non-spam
email messages that may contain spam messages as an attachment, not as an
advertisement.
so I'd say we should take the message/* parts, and ignore them entirely.
------- Additional Comment #29 From Justin Mason 2004-04-29 00:01 -------
Subject: Re: non-text part inside of forwarded message included in "body"
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>the majority of MUAs don't display automatically, so I don't think
>spammers are going to start doing this en masse. if this starts
>happening, and users go and open attachments from people they don't know
>(don't they know not to do this due to worms/etc?), there's really no
>difference between that and if spammers start sending doc, pdf, etc spam
>attachments. we don't scan those either.
...or password-protected ZIP files, for that matter. ;)
>just because there's a spam attachment message, doesn't mean the whole
>message should be considered spam anyway. mailman notification and
>(imnsho) DSNs are examples of this -- non-spam email messages that may
>contain spam messages as an attachment, not as an advertisement.
Yep.
>so I'd say we should take the message/* parts, and ignore them entirely.
Agreed.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Exmh CVS
iD8DBQFAkKhVQTcbUG5Y7woRAkK6AKCyhE8rkSO3ICbUH5+ij8psVK1p4gCfcSWF
Bly3QJ1ylSUvKT1mLpU48N8=
=Ifme
-----END PGP SIGNATURE-----
------- Additional Comment #30 From Daniel Quinlan 2004-04-29 01:02 -------
>so I'd say we should take the message/* parts, and ignore them entirely.
I have to disagree.
1. message/rfc822 attachments that are spammy are typically not wanted
2. opening a message/rfc822 attachment *is* done automatically by some
MUAs and is easy in most other MUAs
3. it's much easier than opening viruses, password protected ZIP files, etc.
and the analogy doesn't really work -- virus scanners (when present) will
catch those, they don't catch spam and spammers don't need someone to
run a message/rfc822 -- they just need someone to look at it, so it will
be considered safe by MUAs.
It's 100% our job to scan ALL of the message, especially this which is so
easy for us to scan. If spammers start attaching other formats, then we can
write rules for that. We can't just mark message/rfc822-containing messages
as spam, but we can check the contents and we should continue to do so.
Not scanning them because we developers might get an occasional spam forwarded
to us is a disservice to 99.99% of SpamAssassin users who don't want this crap.
------- Additional Comment #31 From Theo Van Dinter 2004-05-10 21:07 -------
ok folks... we're going to need to come to some form of conclusion to this.
Right now, we essentially have 2 +1s for not parsing, and 1 +1 for doing the
parsing. I don't think we're going to get consensus on this.
The code required to do the parsing is trivial. It's an if statement and about
4 lines of code. ie: to enable/disable it is trivial.
Shall we take a vote? Do we want more discussion?
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
