Feature force unspam

[diroots]

proposition for feature request : #1510

• add a new sieve action : "Force Unspam" which basically creates a sieve filter like

{
    fileinto "INBOX";
    stop;
}

[diroots]

i could test this quickly, and could see in the mail server siece script folder a new entry created from web ui :

it seems it still has some labelling issues :

and action name in the dropdown :

but after saving in the UI, the sieve script was sent to mailserver for the user

[the-djmaze]

There is more to it.

https://datatracker.ietf.org/doc/html/rfc9051#section-2.3.2
https://www.rfc-editor.org/rfc/rfc5232.html

1. removeflag "$Junk";
2. addflag "$NotJunk";
   OR
3. setflag "$NotJunk"; (which removes all other flags)
   OR
4. fileinto :flags "$NotJunk" "INBOX";

Same can be done for "mark as spam" and for "mark as phishing" ($Phishing)

[diroots]

There is more to it.

https://datatracker.ietf.org/doc/html/rfc9051#section-2.3.2 https://www.rfc-editor.org/rfc/rfc5232.html

1. `removeflag "$Junk";`

2. `addflag "$NotJunk";`
   OR

3. `setflag "$NotJunk";` (which removes all other flags)
   OR

4. `fileinto :flags "$NotJunk" "INBOX";`

Same can be done for "mark as spam" and for "mark as phishing" ($Phishing)

Hello @the-djmaze should i continue and also add this flag too or this PR will not be merged as per your comments in initial issue already closed?

[the-djmaze]

I closed the issue because i removed the rainloop option to disallow fileinto INBOX and just allow it.

This PR can stay open so we can improve your suggestion as i mentioned regarding the flags.

So an option for "not spam" and "spam" should be improved with the flags.

[sevmonster]

This sort of broad filter would also affect systems where there are other destination folders for messages... For example I file my messages into subfolders based on local_part_suffix. Since I run Sieve filters after this step, the destination folder would be lost. Just something to consider.