Replacement for antispam plugin

David Mehler
Fri, 10 Feb 2017 19:46:50 -0000

Hello,

Chiming in on this with a question, and will be getting to it over the
weekend or later this evening time permitting.

Does retraining a message as either spam or ham alter message headers
for example x-spam or the spamassassin-modified subject header?

If not is it possible to do so after processing? For example, I have a
message inadvertently tagged as spam, from Spamassassin it gets an
x-spam header added as well as a modified subject. Retraining that
message as ham moving it to say any other folder but spam i'd like for
that x-spam header to be set to as it is not spam, and the
spamassassin subject to be removed. Is this doable?

Thanks.
Dave.


On 2/10/17, Michael Slusarz <michael.slusarz at dovecot.fi>
wrote:
>
>> On February 10, 2017 at 12:13 PM Ralph Seichter wrote:
>>
>> On 10.02.17 18:34, Michael Slusarz wrote:
>> > > Can we add an exception for the Trash folder?
>> > This is handled in the sieve script. E.g.:
>> >
>> > require "environment";
>> > if environment "imap.mailbox" "Trash" {
>> >  stop;
>> > }
>>
>> This does not work for me, and I don't really expect it to work
either.
>> https://tools.ietf.org/html/rfc6785#section-4.4 states:
>>
>>  The implementation MUST set the Environment [RFC5183] item
>> "imap.mailbox"
>>  to the name of the mailbox that the affected message is in, in the
>>  case of existing messages, or is targeted to be stored into, in the
>>  case of new messages.
>>
>> The message already exists in the Spam folder, hence imap.mailbox
should
>> be "Spam" instead of "Trash", correct?
>
> Incorrect.
>
> When you move a message to a new mailbox, that is a "new message"
event (a
> new UID in the target mailbox is created; the message count increases).? So
> imap.mailbox is set to the name of the *target* mailbox.
>
>> Is there perhaps another way to ensure that manually deleted spam is
not
>> erroneously learned as ham?
>>
>> -Ralph
>