EDIT: This should already provide the desired behaviour by default... what are we actually fixing with this then?

This is a no from me 👎

I have documented why in the associated issue. Basically SA_KILL is a threshold to trigger the Amavis action (we default to D_BOUNCE), and simply bumping this value to an excessively high default to avoid mail being bounced seems redundant?

We have other ENV to support the alternative behaviour this PR is attempting to resolve, it would be better to adjust the defaults instead.

ENV and values were contributed by the original DMS author in Feb 2016, with minimal context. They are the default upstream values (and the ENV docs are taken directly from comments there too).

$sa_tag_level_deflt  = 2.0;  # add spam info headers if at, or above that level
$sa_tag2_level_deflt = 6.31; # add 'spam detected' headers at that level
$sa_kill_level_deflt = 6.31; # triggers spam evasive actions
$final_spam_destiny       = D_PASS;    
$final_bad_header_destiny = D_PASS;     # False-positive prone (for spam)

As detailed below, SA_KILL being at the same value as SA_TAG2 is just to say always perform the configured action when mail is marked as spam.

If you needed some flexibility to conditionally treat some spam differently, such as allowing spam to arrive into the junk folder, but discarding/bouncing mail with a very high spam score (differentiating between maybe spam and definitely spam), this could be a reason to go with a higher SA_KILL and the D_BOUNCE (or other supported actions).

Oh, I misunderstood this too then. Thanks for the clarification! I'd not merge this as is then too, but maybe this PR can bring an enhanced documentation?

• MOVE_SPAM_TO_JUNK - This is only for IMAP setups, not for POP3.
• SPAM_TO_INBOX disables bouncing of SPAM messages completely

Some might set this both to 0.

SA_TAG2 defines when to add spam headers, e.g. changing the subject to *** SPAM *** and SA_KILL defines at what level to bounce the mail.

We can see that we're currently just leaving these ENV to their respective defaults upstream and expecting users to change them if they're not happy with that. That probably isn't an issue, except that we have D_BOUNCE instead of the default D_PASS.

Because we changed it to D_BOUNCE, it's a an issue, or at least not sane:

Setting SA_TAG2 == SA_KILL leads to never receiving an email with *** SPAM *** subject?

SA_KILL=10000.0 might be the wrong approach. As you pointed out, this will basically prevent any mail from bouncing.

But SA_KILL should be higher than SA_TAG2. What do you think?

Because we changed it to D_BOUNCE, it's a an issue, or at least not sane:

EDIT: This was my bad, as shown with snippet at the end of this comment, it should still be D_PASS by default, and only change to D_BOUNCE when explicitly opt-ing out of delivering spam.

• MOVE_SPAM_TO_JUNK - This is only for IMAP setups, not for POP3.

Is it? I thought Dovecot sieve scripts were for handling any mail arriving into the inbox, protocol agnostic?

Mail that is delivered to DMS goes through SA and Amavis, which would add the spam header to trigger the sieve script would it not?:

Then IMAP and POP3 are for mail clients to retrieve mail from Dovecot after the fact? Why would POP3 be excluded from the feature?

Setting SA_TAG2 == SA_KILL leads to never receiving an email with *** SPAM *** subject?

That's what I understand. I am not familiar with spam scores as I don't actually run DMS (all this time and I still just contribute to a project I don't use 😂 ), so I don't know what a good value would be for SA_KILL. Based on the blog I referenced, they had SA_KILL at 2.0, but it wasn't clear what score is 99% likely to be actual spam 🤷‍♂️

But SA_KILL should be higher than SA_TAG2. What do you think?

I am not sure. In what scenario do you want to mark mail as spam, but not handle it differently? (I'm not sure if the action D_PASS actually treats the mail differently, maybe metadata or logs? 🤷‍♂️ )

If there was a reasonable "definitely spam" score that SA_KILL could use for D_BOUNCE perhaps that'd make sense if 6.31 is still prone to a fair amount of false-positives.

SA_KILL=10000.0 might be the wrong approach. As you pointed out, this will basically prevent any mail from bouncing.

Honestly considering what this would do, it just sounds like the smarter choice is to default to D_PASS instead of D_BOUNCE. (**EDIT: which I forgot we already do, I just forgot to update the part of my message that you quoted 😅 )

Ok so if bouncing mail is the problem when that ENV is flipped, we could also use D_DISCARD (I think that's the correct one), which my other reference link said would not deliver the mail, but still keep it stored locally in quarantine.

Alternatively, we better document that disabling SPAMASSASSIN_SPAM_TO_INBOX will bounce any mail marked as spam? And that if that is too aggressive, they can raise the SA_KILL value to increase the threshold of when spam is bounced? (allowing some mail marked as spam through still if SA_TAG2 is lower)

MOVE_SPAM_TO_JUNK - This is only for IMAP setups, not for POP3.
Is it? I thought Dovecot sieve scripts were for handling any mail arriving into the inbox, protocol agnostic?

That's my assumption, or at least part of it, because POP3 does not now the concept of folders. So moving SPAM to junk folder has no effect. In POP3 this have to be configured client side in the MUA as a rule (not in scope of DMS).

You are right, that Sieve processing also apply to POP3, but moving a mail to junk folder in particular will have no effect (from POP3 view).

SPAM_TO_INBOX disables rejecting emails completely. The use case I thought of was:

SPAM_TO_INBOX=0
SA_TAG2=6
SA_KILL=10

This allows to tag mails as SPAM beginning with a score of 6 and rejecting mails with a score of >=10.

SA_KILL=10000.0 is bad I agree, because it disables rejecting mails. But SA_KILL should be higher than SA_TAG2 IMO.

This seems acceptable 👍 Although I prefer there to be an actual demand to warrant the change 🤔

Since it only affects the users explicitly opt-ing in to bouncing mail marked as spam, this change may result in receiving unwanted spam in their inbox. Improving docs probably makes more sense.

That's my assumption, or at least part of it, because POP3 does not now the concept of folders. So moving SPAM to junk folder has no effect.
In POP3 this have to be configured client side in the MUA as a rule (not in scope of DMS).

I thought that this is about what happens when mail arrives to Postfix, it gets filtered through Amavis + SA, then sent to Dovecot for mail storage. The MUA then can access that mailbox via IMAP or POP3.

It should still be in Dovecot's junk folder for that mailbox, and marked as spam in the mail headers?

You are right, that Sieve processing also apply to POP3, but moving a mail to junk folder in particular will have no effect (from POP3 view).

My understanding is that sieve is on Dovecot's end with how it manages mail storage. Agnostic from MUA access regardless of protocol.

This allows to tag mails as SPAM beginning with a score of 6 and rejecting mails with a score of >=10.

SA_KILL=10000.0 is bad I agree, because it disables rejecting mails. But SA_KILL should be higher than SA_TAG2 IMO.

SA_KILL=10 seems okay-ish from a quick look at non-standard values used elsewhere:

• Earlier reference found SA_TAG=0, SA_TAG2=0.5, SA_KILL=2 to work reasonably well for them.
• Other earlier reference used SA_TAG=-999 (always add spam info, for testing?), SA_TAG2=5, SA_KILL=12. They use D_DISCARD, so mail is not delivered to inbox, but not bounced either, but quarantined in local storage.
• ArchWiki config example uses SA_TAG=1, SA_TAG2=1 , SA_KILL=5.
• Some spam scores for test spam mails shared. SA_KILL=10 seems alright based on that.
• 2017 DMS user report with SA_TAG2=5, SA_KILL=1000`: 25 detected as spam, 40 undetected, 10 legitimate emails.
• 2017 DMS user reports with defaults legitimate mail receiving a score of 8.
• 2018 DMS user report with SA_KILL=4 based on their observations of spam often being marked between 4 and 6.
• 2019 DMS user report only mentions legitimate mail marked as spam as sender only sent a URL. That's enough to score the current 6.31 I guess.
• 2020 DMS user report default D_BOUNCE at the time prevented receiving a registration email. UX expressed that some spam came through, they did not expect only some spam to be bounced.

Ok, so for the defaults, this makes no difference right? Due to D_PASS, the mail still gets tagged as spam (SA_TAG2) at the same score, and thus the sieve will move to junk.

SA_KILL only has relevance for our alternative action D_BOUNCE, those users will potentially get more spam delivered instead of rejected (and we don't have any major complaints AFAIK of users opting in to this feature about legitimate mail being rejected).

I suppose with release notes, if there is more spam being delivered when they'd rather it bounced, they can manually change SA_KILL or raise an issue about it 🤷‍♂️ Likewise, no reason to lower SA_TAG2... so sounds good 👍

$sa_dsn_cutoff_level = 10;   # spam level beyond which a DSN is not sent

# You should:
#   Use D_DISCARD to discard data (viruses)
#   Use D_BOUNCE to generate local bounces by amavisd-new
#   Use D_REJECT to generate local or remote bounces by the calling MTA
#   Use D_PASS to deliver the message
#
# Whatever you do, *NEVER* use D_REJECT if you have other MTAs *forwarding*
# mail to your account.  Use D_BOUNCE instead, otherwise you are delegating
# the bounce work to your friendly forwarders, which might not like it at all.
#
# On dual-MTA setups, one can often D_REJECT, as this just makes your own
# MTA generate the bounce message.  Test it first.
#
# Bouncing viruses is stupid, always discard them after you are sure the AV
# is working correctly.  Bouncing real SPAM is also useless, if you cannot
# D_REJECT it (and don't D_REJECT mail coming from your forwarders!).

$final_virus_destiny      = D_DISCARD;  # (data not lost, see virus quarantine)
$final_banned_destiny     = D_DISCARD;  
$final_spam_destiny       = D_PASS;    
$final_bad_header_destiny = D_PASS;     # False-positive prone (for spam)

Related issue history

For better traceability via referencing existing issues / PRs

• March 2020: Add an option to place spam in the inbox, and then sort the mail by a sieve rule #1431
  • Introduced the SPAMAASSASSIN_SPAM_TO_INBOX ENV.
• May 2020: Feature: Spam to Junk folder #1485
  • Introduced the MOVE_SPAM_TO_JUNK ENV (and documents SPAMASSASSIN_SPAM_TO_INBOX=1 but leaving it disabled by default due to maintainer decision).
• Jan 2022: [BUG] sieve error when enabling MOVE_SPAM_TO_JUNK=1 #2366
  • Sieve error due to lack of +w permission for sieve script. Unresolved, potentially user misconfiguration or environment issue.
  • References Feb 2022 PR that changes SPAMASSASSIN_SPAM_TO_INBOX ENV default to 1, released in March 2022 in DMS v10.5.
• Mar 2022: SA_KILL does not superseeds SPAMASSASSIN_SPAM_TO_INBOX #2491

  • Reports FAQ entry in docs, suggestion to create a PR was the only activity, no progress made:

    By default, SPAM and INFECTED emails are put to a quarantine which is not very straight forward to access.

    Apparently D_BOUNCE and some other actions will still quarantine. Our ENV docs for SA_KILL also detail the quarantine location (while a FAQ entry describes how to send to a dedicated mailbox). Amavis docs on quarantine.

    SA_KILL needs to be very high, to make sure nothing is bounced at all (SA_KILL superseeds SPAMASSASSIN_SPAM_TO_INBOX)

    Likewise, inaccurate. As the FAQ entry continues to detail, it seems these were not the defaults, and have not been updated to clarify that this is default behaviour now, and when SA_KILL is relevant.

    These docs were contributed to the original wiki in May 2020 (associated issue). No real content changes to update them since.

• Oct 2022: Weird SPAM behaviour #2816
  • Received no interaction. References another SA FAQ entry (no new updates since migration from Wiki, which had multiple edits in 2019) (associated issue). There was some minor improvements contributed in Aug 2022, but it was mostly focused on adding a section on SA cron for fts_xapian config.
  • They also reference the sieve script from the other mentioned FAQ entry. Their report was about non-deterministic delivery handling, potentially they had that suggested sieve script conflicting with the default one we ship? So first in first serve 🤷‍♂️

I noticed that this only changed a default in the optional .env file. Docs and variables.sh were not updated 😅

Due to #3112 PR wanting to move variables.sh, may be best to wait until after that is sorted out though.