Should dovecot_config_version = 2.4.0 keep mail_attachment_detection_options empty on 2.4.5?

Hello,

I'm hoping someone can help me understand how dovecot_config_version is meant to interact with mail_attachment_detection_options. I may well be misreading the docs...

Some background: I help with docker-mailserver, which normally ships Debian's Dovecot 2.4.1. I've been testing a build that uses the CE packages from repo.dovecot.org instead (2:2.4.5-2+debian13 on Debian trixie, amd64). The config is Debian's, so it starts with:

dovecot_config_version = 2.4.0
dovecot_storage_version = 2.4.0

The upgrade notes for 2.4.1 to 2.4.2 list mail_attachment_detection_options under "Changed Setting Defaults", with the new default "add-flags content-type=!application/signature", and say these changes don't take effect until dovecot_config_version is changed to 2.4.2. So I expected it to stay empty for us.

doveconf seems to agree:

$ doveconf -d mail_attachment_detection_options
mail_attachment_detection_options = add-flags "content-type=!application/signature"
$ doveconf mail_attachment_detection_options
mail_attachment_detection_options =

But when a message is delivered over LMTP into a maildir mailbox, it still gets the $HasNoAttachment keyword, and so the file goes into cur/ rather than new/:

$ doveadm fetch -u user1@localhost.localdomain 'flags' all
flags: \Recent $HasNoAttachment

$ cat .../user1/dovecot-keywords
0 $HasNoAttachment

With Debian's 2.4.1 and the same config, the same delivery has no keyword and lands in new/. If I set "mail_attachment_detection_options =" explicitly, 2.4.5 behaves like 2.4.1 again.

I noticed the settings reference gives this default per mail driver ("mbox, imapc: <empty>, others: add-flags ..."), so my guess is that the per-driver default doesn't go through the config version check. Is that the intended behaviour, or should dovecot_config_version = 2.4.0 keep it empty here as well? I've only tried LMTP delivery to maildir, so I don't know whether other paths act the same.

Setting it explicitly is easy for us, so this isn't urgent. I'd just like to describe it correctly in our config, and to know whether we can drop the workaround one day.

Thanks for your time.

Chris