TL;DR: I think I’ve figured this issue out. A bunch of waffling below, with a couple of questions at the end that I’d really like someone with greater knowledge than mine of mailcow and rspamd to ponder and provide some insight/feedback.
I have an old server running Plesk for Linux, that I use for some small-scale web and email hosting. It uses qmail for mail and I have two accounts: firstname.lastname@example.org for my regular/personal email, and email@example.com for “everything else”. The way qmail works historically is it supports plus addressing but using - instead of + as a separator between the user part and tag/extension (see http://www.lifewithqmail.org/lwq.html#extension-addresses for details) so I have accounts like firstname.lastname@example.org, email@example.com etc. I’m guessing they took this approach to solve the issue due to some forms having issues with validation of email addresses with a “+” in them (maybe also with spaces being escaped to + in URL strings?)
I want to migrate to Mailcow for many reasons, but the enforcing of “+” as a separator causes some pain. Trying to figure out how to get things working “as they are now, in my world” lead me to this page (amongst others).
If I change recipient_delimeter in ~/data/conf/dovecot/dovecot.conf and ~/data/conf/postfix/main.cf it works as far as mail being delivered to the right account, which for my use is pretty much where the story ends - I’m not using any subject line rewriting or sub-folder tagging. While that might be “good enough”, I’m concerned that it’s not “right” as far as rspamd is concerned, based on the messages in this thread.
Using regular plus addressing, when I look at the rspamd web UI history tab, the [Envelope To] correctly shows firstname.lastname@example.org (ie without the tag). Changing the recipient_delimiter to “-” as described above, the [Envelope To] field shows the full email@example.com address. This makes me think that rspamd is seeing each tagged address as a separate entity, which is probably where the “Danger Will Robinson!” warnings in this thread come from?
Issue 1146 refers to the TAGGED_RCPT symbol, which is set by rspamd when the recipient address is a plus address. My thinking then is that if rspamd could set that symbol based on the presence of “-” in the recipient address, rather than “+”, we’d be all good?
If I attach to the rspamd container, I can edit /usr/share/rspamd/lualib/lua_util.lua (after installing vim). Changing the patterns in both string.match lines of the remove_email_aliases function (around line 180) and restarting, I now see the expected firstname.lastname@example.org in the rspamd history, and mailcow subject line rewriting or subfolder creation works as expected (I’m seeing the TAGGED_RCPT symbol as expected).
So technically, this would appear to have solved the problem. However, I don’t think it’s sustainable. I’m fine editing the recipient_delimiter in the two files in ~/data/conf as described above, and this would be persistent, but I’m thinking (with my limited docker knowledge) that the change to lua_util.lua would get overwritten the next time mailcow gets updated (or that image gets updated, specifically)?
- If my explanation and hypothesis above is correct, am I ok editing the 2 files in ~/data/conf at initial server setup, and the 1 file in the rspamd container as needed when updating versions, as a vehicle to being able to use “-” instead of “+” as the separator for tagged/extension addresses?
- Is there a way I can make this more sustainable across updates? My thoughts were either somehow being able to redefine the remove_email_aliases function in some kind of override file, or editing the yml file to map a file in ~/data/conf to the relevant location within the rspamd container, but I’m thinking again this may break in the case of updates, and understand that the rspamd container is pretty much “as-is” and not configurable in this way.
Thanks in advance for your thoughts and feedback.