http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4988
------- Additional Comments From [EMAIL PROTECTED] 2006-07-14 11:49 ------- > > - Issue 1. It should not attempt to mass-check an empty message; if the > > MIME end-boundary for the report_safe encapsulation is not found, it should > > ignore the message as incomplete. (In fact, it should attempt to keep > > reading until it does find the MIME end boundary. But that may get > > complex, since breaking up mboxes into messages takes place in > > ArchiveIterator, which doesn't know about report_safe.) > > -1 -- this isn't a bug in mbox parsing, and we definitely don't want to try > adding logic for it to figure out if something looks "valid" or not. it's > job is to parse an mbox and pass the message on. if the input is corrupt, > then the problem is the input. Hold on; there are two parts involved. One is the mbox parsing in ArchiveIterator, and I agree, changing that would be messy and inappropriate; however, the other part is the calling code, in "mass-check" itself, and it'd be fine to add a hack-fix for this there, in my opinion. That's what I'd suggest doing. Loren: > If that is the original message, and you remove the From line, then it isn't > the original message any more! no, the From line should not be there. Having it there is breaking the MIME message/rfc822 format rules. It has to go. Actually Theo -- even if there are two "From" lines in the input, *none* should be making it into the output message/rfc822 part. It may be GIGO, but if SpamAssassin accepts it, parses it, and marks it as spam correctly, why not fix it on the way out so that we are producing valid message/rfc822 output? "Be liberal in what you accept, strict in what you produce" etc. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
