Using version 2.55 , thought it was in the headers, oops. It is in the header of the second message since I manually inserted those headers after editing the message and piping it through the spamassassin binary (as opposed to resending the message through Amavisd-new using Mail::SpamAssassin perl module).

Hopefully the mime parser in 2.60 is able to dig into the nested parts.

Ryan Moore
----------
Perigee.net Corporation
704-849-8355 (sales)
704-849-8017 (tech)
www.perigee.net

Bart Schaefer wrote:
On Mon, 25 Aug 2003, Ryan Moore wrote:
I got an email that made it by spamassassin with virtually no hits, which looks like it used some wierd mime technique to get through spamassassin. [...]

Is it valid to specify a different boundary in the mime header (when not attaching a rfc822 source message)?


The sample is a well-formed nested multipart.  I know SA had problems
descending into nested parts in the past, but I've lost track of the
status.  What version are you using?  Can someone say whether this is
still a problem in 2.60?

It's stretching the semantics of multipart/related a bit to make the first
part be multipart/alternative, because the intent is that announcing the
type of the first part of the m/r allows the user agent to decide how to
render the content -- which the UA can't do without lookahead if the first
part is another multipart.  However, it isn't actually invalid AFAICT.






------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk

Reply via email to