You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Ben Wylie <sa...@benwylie.co.uk> on 2007/02/26 16:01:46 UTC

image multipart/alternative rule

I have a few questions about MIME multipart/alternative, and to suggest 
a rule.

As i understand it, multipart/alternative in emails allows an email to 
be composed in different formats and all formats to be sent together in 
the one email. The user agent used to read the email can then choose 
which alternative version of the same email it would like.
This tends to be text or html.

However, with a lot of image spam, it is often text, html or an image.
As I understand it, with multipart/alternative the order of the parts 
indicates how faithful it is to the original, so usually the text 
version is first and then the html version with formatting. However with 
image spam, there is the third and apparently most faithful version of 
the email, which is the image.

Could a rule be written to catch emails where multipart/alternative is 
used, and an image is apparently the best alternative?
This way, it is not penalising image attachments, but only images which 
claim to be the best alternative version of an email.

Would this be possible to have a rule for?
I'm not quite sure how images which are part of the html part for 
example would be differentiated from image only alternative parts.
What sort of false positives might you get?

Here is an example of what I mean:

Info in header:
MIME-Version: 1.0
Content-Type: multipart/related;
	boundary="----=_NextPart_000_0001_01C7549C.135F6A00"

Info in body:

------=_NextPart_000_0001_01C7549C.135F6A00
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_000E_01C7549C.13F80080"

------=_NextPart_001_000E_01C7549C.13F80080
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

------=_NextPart_001_000E_01C7549C.13F80080
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

------=_NextPart_001_000E_01C7549C.13F80080--

------=_NextPart_000_0001_01C7549C.135F6A00
Content-Type: image/jpeg;
	name="image93.jpg"
Content-Transfer-Encoding: base64
Content-ID: <im...@39933624.26798963>

------=_NextPart_000_0001_01C7549C.135F6A00--

Any thoughts as to whether this is possible, if it would be effective 
and if it has already been done but i have not noticed, would be great.

Thanks
Ben



Re: image multipart/alternative rule

Posted by Theo Van Dinter <fe...@apache.org>.
On Mon, Feb 26, 2007 at 03:01:46PM +0000, Ben Wylie wrote:
> Could a rule be written to catch emails where multipart/alternative is 
> used, and an image is apparently the best alternative?
> This way, it is not penalising image attachments, but only images which 
> claim to be the best alternative version of an email.

What if an image is the best version of a message?  It's up to the author.

> Would this be possible to have a rule for?

Sure.  However, that's not what's going on, see below:

> Content-Type: multipart/related;
> 	boundary="----=_NextPart_000_0001_01C7549C.135F6A00"

Ok, so this is the first part:


> ------=_NextPart_000_0001_01C7549C.135F6A00
> Content-Type: multipart/alternative;
> 	boundary="----=_NextPart_001_000E_01C7549C.13F80080"
> 
> ------=_NextPart_001_000E_01C7549C.13F80080
> Content-Type: text/plain;
> 	charset="us-ascii"
> Content-Transfer-Encoding: 7bit
> 
> ------=_NextPart_001_000E_01C7549C.13F80080
> Content-Type: text/html;
> 	charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
> 
> ------=_NextPart_001_000E_01C7549C.13F80080--

This is where the first part ends.  Then comes the second part:

> ------=_NextPart_000_0001_01C7549C.135F6A00
> Content-Type: image/jpeg;
> 	name="image93.jpg"
> Content-Transfer-Encoding: base64
> Content-ID: <im...@39933624.26798963>
> 
> ------=_NextPart_000_0001_01C7549C.135F6A00--

So you have a multipart/related which has within it a multipart/alternate
and an image/jpeg.  That's exceedingly common.

-- 
Randomly Selected Tagline:
"Remember:  The difference between something that might go wrong and
 something that can't possibly go wrong is that something that can't
 possibly go wrong is impossible to fix."      - Peter Sagerson