Replacement for antispam plugin
David Mehler
dave.mehler at gmail.com
Fri Feb 10 19:46:50 UTC 2017
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
>
More information about the dovecot
mailing list