Reading the original messages from spamassassin reports

["Theodoros V. Kalamatianos" <th...@softlab.ece.ntua.gr>]

Hi,

I am using spamassassin-3.0.3, in a procmail setup. It seems to be working 
properly, as far as detecting spam goes (although It could use some 
tweaking). The problem is that I cannot read the original messages from 
spamassassin reports. I use PINE regularly and although I can see the 
original message in raw form, using the View Headers option, I cannot read 
it in any other way. I also tried with mozilla-1.7.2 (the spambox was 
accessed via dovecot/IMAP) and got the same results. They both are able to 
display the message headers, but not its body, although it is physically 
there. I had a look with a text viewer and compared the SA reports with 
other messages. It occurred to me that the SA reports have no ending MIME 
content boundary string. Is this normal/legitimate ? Could it be the cause 
of this problem ?

I would like any comments on this, since I seem to have a problem 
recovering the original messages (spamassassin -d also seems unable to 
correctly recover the message).


Regards,

Theodoros V. Kalamatianos



PS: spamassassin is called as spamassassin -L from a procmail filter rule

Re: Reading the original messages from spamassassin reports

["Theodoros V. Kalamatianos" <th...@softlab.ece.ntua.gr>]

On Sun, 3 Jul 2005, Theodoros V. Kalamatianos wrote:

> Hm. I ran some isolated test (only one message for now). Strangely enough the 
> boundary was there. Perhaps something is eating up the last line of the 
> message. Most of my messages were from old mailboxes, so they were passed 
> through formail. Perhaps that is the culprit. It is strange though that I 
> have found no other malformed messages.

Ooops, I found the cause of this. I used to call spamassassin with the 
following procmail rule:

:0 fhw
| spamassassin -L

Note the h flag - it makes it so that _only_ the message header is passed 
to SA. It is no wonder the spam filtering was ineffective - SA could only 
process the message headers, and when creating a spam report it 
encapsulated an empty message. Then procmail appended the body of the message
thus keeping the processed message sizes somewhat correct.

I guess the procmail documentation is somewhat fuzzy on the h flag issue - 
or I did not RTFM well enough (probably the second).

Anyway, I corrected the rule and used a script to recover the messages, so 
everything is ok now.


Thank you for your time,

Theodoros V. Kalamatianos

Re: Reading the original messages from spamassassin reports

["Theodoros V. Kalamatianos" <th...@softlab.ece.ntua.gr>]

On Sat, 2 Jul 2005, Loren Wilton wrote:

>> other messages. It occurred to me that the SA reports have no ending MIME
>> content boundary string. Is this normal/legitimate ? Could it be the cause
>> of this problem ?
>
> It isn't normal and certainly won't match the RFCs, and it may be part or
> all of your problem.  I don't think I recall having heard of this sort of
> thing happening with procmail, although I vaguely recall a problem with some
> other tool that would occasionally drop the last part of a stream on a
> network connection, causing something like this.

Hm. I ran some isolated test (only one message for now). Strangely enough 
the boundary was there. Perhaps something is eating up the last line of 
the message. Most of my messages were from old mailboxes, so they were 
passed through formail. Perhaps that is the culprit. It is strange though 
that I have found no other malformed messages.

> Are you sure that you don't just see the spam report in Pine, and the actual
> message is an attachment that you will have to do something extra to see?
> I'm not a Pine user, so I don't know how it deals with attachments.

I use the Attachment Index screen, and somehow although the report is say 
150K, its parts are only 2K. I have to recheck my whole mail chain right 
now. I'll see what I can find and report back.

>
>        Loren
>

Thanks for the quick reply,

Theodoros V. Kalamatianos

Re: Reading the original messages from spamassassin reports

[Loren Wilton <lw...@earthlink.net>]

> other messages. It occurred to me that the SA reports have no ending MIME
> content boundary string. Is this normal/legitimate ? Could it be the cause
> of this problem ?

It isn't normal and certainly won't match the RFCs, and it may be part or
all of your problem.  I don't think I recall having heard of this sort of
thing happening with procmail, although I vaguely recall a problem with some
other tool that would occasionally drop the last part of a stream on a
network connection, causing something like this.

Look to your value of report_safe in local.cf.  You can set this to various
values to encapsulate the spam as an attachment (which sounds like how you
have things) or to simply add SA headers to the headers of the original mail
message, and I think maybe a couple other ways of doing things.  Possibly
you can find a setting that will make Pine happier.

Are you sure that you don't just see the spam report in Pine, and the actual
message is an attachment that you will have to do something extra to see?
I'm not a Pine user, so I don't know how it deals with attachments.

        Loren