How to implement plus addressing?

[kanashimia]

I want to handle [email protected] to redirect the message into the mailbox passed.
Like a setting from dovecot: https://doc.dovecot.org/configuration_manual/sieve/examples/#emulating-lmtp-save-to-detail-mailbox-yes
But how to do that?

I tried like this (nix templating, sorry)

session.data.script = "'modify-message'";
sieve.trusted.scripts."modify-message" = {
  name = "Modify Message";
  contents = ''
    require ["variables", "fileinto", "envelope", "subaddress", "mailbox"];
    if envelope :matches :detail "to" "*" {
      set :lower :upperfirst "name" "''${1}";
      fileinto :create "INBOX/''${name}";
    }
  '';
};

And it just doesn't work. If I understand it correctly trusted scripts can't use fileinto at all:

mail-server/crates/common/src/config/scripts.rs

Lines 210 to 215 in 592ca3c

	let mut trusted_runtime = Runtime::new()
	.without_capabilities([
	Capability::FileInto,
	Capability::Vacation,
	Capability::VacationSeconds,
	Capability::Fcc,

I know I could try to do it using manage sieve, but is there a way through config?

BTW docs should be updated, examples are invalid, they don't have name / content or quotes around script name: https://stalw.art/docs/smtp/inbound/data/#sieve https://stalw.art/docs/sieve/examples

[kanashimia]

Anyways, here's a funny story:

I've tried it, and through managed sieve it works, but:

It created another mailbox instead, very cool.
When you change it to "Inbox" then it works.

Also found that you could delete the old one.
And I somehow managed create recursive folder.

Here is image after export:

And yes, INBOX without "role":"inbox"

Which pretty much broke all jmap clients.
Creating new account solved the problem, but when I deleted the previous one, and renamed new one to that old one, same problem happened, inboxes were from the old account too.
Do you store data per account login name or something instead of per something like UUID?

So I pretty much had to wipe the DB.

[mdecimus]

Hi,

Can you share the script you used to create a recursive folders? I'll try to reproduce and fix the issue.

[kanashimia]

Sorry, this was done interactively while I was doing random stuff so I don't entirely sure how it happened. The closest thing I remember is that I was having a layout like this "Inbox" "INBOX" "Inbox.Shrine" then I moved that dir "Inbox.Shrine" to "INBOX.Shrine", then deleted "Inbox", then moved "INBOX.Shrine" to "Shrine"?? something happened then? and deleted "INBOX"? not sure at that point. This was done mainly through JMAP, partially through IMAP too.

At some point basically that folder was lost from the view, I tried to create it again and it created a new folder instead, found that it is recursive after export. Behavior with such infinite folder is as such: IMAP clients don't show it, but they still function, JMAP clients (meli, aerc) are borked and take infinite time to launch.
That's probably because in IMAP these clients don't show the message count for all dirs, but in JMAP mode they show, and it probably counts infinitely?

I will try to investigate it some time later, I know the info is not useful.
At least for when there is a recursive folder I should check JMAP messages.
I don't even know if I manage to reproduce it again, was just noting here just so you know.

My guess is there's probably some missing check somewhere when deleting or moving the folder.

I suggest also detecting such cycles, during the database maintenance phase maybe, fixing them and showing the big fat ERROR message in the log.
Loop detection in general may cost some time, but for such trivial self-recursive cases it will be ok.

[mdecimus]

There server implements loop detection and folder depth limits, so this is a bug. I'll try to reproduce this locally using IMAP because I was not able to do it using JMAP.