EnglishI’d like to add/change the symbol/character used for tagging from, say just + to, say + or -.
I could probably change this in postfix, but I assume it will get lost on updates etc.
Is there an approved/best way to do this? [A search didn’t turn up anything.]
TIA
-Greg
Have something to say?
Join the community by quickly registering to participate in this discussion. We'd like to see you joining our great moo-community!
I’ve seen that document already.
That only changes how the suffix is output in the subject line - provided you’re using the subject pre-pend option. , [Leave the case alone with the supplied patch. The default is to set the tag in the subject to lower-case.]
I’m not sure why this is confusing - I know that the current tag delimiter is “+” - I’d like to add an additional delimiter. [Or if that’s not possible, perhaps change the delimiter. Instead of using just “+” how about two different delimiters “+” and “-”.
I’m not sure how mailcow goes about handling the delimiters - I suspect it’s in postfix. I could probably directly change the postfix config - but that’s likely to get overwritten when updates are done, or postfix configurations are changed.
So, I’m asking how to do this so the change “works with the system” instead of just going out and directly hacking at the postfix config. [Even assuming the postfix config is where to handle it, which I’m not sure is correct.]
Bump on this topic.
Even if someone can point me in the direction where, in the source, this is configured, I might be able to figure out how to solve it myself.
But knowing the moo-ish way to add/change the + tag character to something else would be best. [Mucking in the config/source-code seems likely to be a bad way that will only last until the next config update.]
I’ll answer my own question, with what I believe is the proper way to solve this issue.
1) Find the location for the docker config - I’m not sure if this is the same for all distros, but on Ubuntu 18.04 it’s here:
/opt/mailcow-dockerized/data/conf/postfix
2) You can modify the main.cf file - but that will get lost when the config file gets re-written.
2a) The better way is to [as noted at the top of main.cf] is to create extra.cf and put the changes there.
The config line for tagging is:
recipient_delimiter = +
You can replace the + with something else, or add another character , like, say “-” [a dash].
3) After you’ve made the change, you need to restart the docker postfix instance.
docker-compose restart postfix-mailcow
I need to test this on a production system - but I think it works.
4) Also note that if you change the character, or add one - that new/different character probably won’t work for the options for a subfolder/subject line modification (I’m guessing there’s a sieve script that handles that sort of thing, and I don’t know how to find/modify it). It should however work for simply allowing those messages that use the recipient_delimiter to get put into the inbox of the appropriate mailbox/account.
That’s not enough.
I suggest to not do that.
Some things will eventually fail. Don’t do that. If you do that, live with any consequences.
Wow. How about suggesting something more useful than “Don’t do that.”
Why?
What should I do otherwise?
So many questions.
I’ve had a chance to do some testing, and there are some more details to add to the post above.
You’ll also need to tweak the dovecot configuration;
1) Add a dovecot config file; /opt/mailcow-dockerized/data/conf/dovecot/extra.conf
Add a line: recipient_delimiter = _+
Replace the delimiters I have above with the ones you want to use. [I tested with those two delimiters and they work - you can use either. I didn’t have any luck with a “.” added to those. Not sure exactly why. So, test whatever you choose to use.]
Save the file.
2) Modify the postfix config file from above to match.
3) Restart the dovecot and postfix docker components.
docker-compose restart dovecot-mailcow; docker-compose restart postfix-mailcow;
Test some mail-pieces to ensure it works like you want.
And as noted: There are options to put the postfixed tag into the subject line or to drop the mail-piece into a subfolder named after the postfixed tag - I suspect those options will work at all, if you change the tag character from the default of “+” - so take that into account. If you need the subject/folder modifications, don’t use this “hack” to tweak the tag character.
It is not supported. It will break things. Especially in Rspamd and its settings.
Don’t do that. It obviously works with a single parameter in Postfix, that’s why it seems to work fine. But, no, it is not supported and will break things.
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: paul@example.com for my regular/personal email, and web@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 for details) so I have accounts like web-amazon@example.com, web-dropbox@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 web@example.com (ie without the tag). Changing the recipient_delimiter to “-” as described above, the [Envelope To] field shows the full web-sometag@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? GitHub
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 web@example.com 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)?
My questions:
Thanks in advance for your thoughts and feedback.
The settings map in (iirc) data/conf/rspamd/dynmaps needs to be adjusted, too. There is a lot of regex for the delimiter.
That’s just one thing that came to my mind. There might be other Rspamd symbols, that break.
Hello @paulc
We’re in the same situation, we’ve have an existant server since more than 10 years with aliases on character “-” rather than “+”, to prevent detection on websites registration ( so as you, we add the name of the domain in your email: guillaume-google@mydomain … ).
So we tried to move to Mailcow, but not sure it’s possible for my company, Mailcow doesn’t seems to be customized, so may be it’s not the good solution for us, and need to go on other solutions ( docker-mailserver, mailu, iredmail… )
But Mailcow seems to have a lot of updates, and so we would like to check if there is a solution or not.
Could you tell us how to you have hacked the function remove_email_aliases() in rspamd please?
For me theses lines are concerned:
local cap, pluses = string.match(no_dots_user, '^([^%+][^%+]*)(%+.*)$')
return cap, rspamd_str_split(pluses, '+'), nil
local cap, pluses = string.match(addr.user, '^([^%+][^%+]*)(%+.*)$')
return cap, rspamd_str_split(pluses, '+'), nilAnd may be should be updated like that:
local cap, pluses = string.match(no_dots_user, '^([^%][^%-]*)(%-.*)$')
return cap, rspamd_str_split(pluses, '-'), nil
local cap, pluses = string.match(addr.user, '^([^%-][^%-]*)(%-.*)$')
return cap, rspamd_str_split(pluses, '-'), nilRight ?
And to prevent any problem of update, we need to revert back our changes before applying the Mailcow update (not needed for the 2 others ~/data/conf files)
@diekuh Thanks also for the feedback and warnings, as Paulc we don’t care about subject line rewriting or sub-folders tagging features. I believe most of people use this kind of configuration, and may be this could be really useful feature to propose to your users. If not, I’m ok to revert back my changes every time there is an update. BTW if you can just confirm your last precision, about the lines to update in ~/data/conf/rspamd/dynmaps/settings.php :
$rcpt[] = ‘/^’ . str_replace(‘/’, ‘\/’, $local) . ‘[+].’ . str_replace(‘/’, ‘\/’, $domain) . ‘$/i’;
$rcpt[] = ‘/^’ . str_replace(‘/’, ‘\/’, $local) . ‘[+].’ . str_replace(‘/’, ‘\/’, $domain) . ‘$/i’;
like this I suppose:
$rcpt[] = ‘/^’ . str_replace(‘/’, ‘\/’, $local) . ‘[-].’ . str_replace(‘/’, ‘\/’, $domain) . ‘$/i’;
$rcpt[] = ‘/^’ . str_replace(‘/’, ‘\/’, $local) . ‘[-].’ . str_replace(‘/’, ‘\/’, $domain) . ‘$/i’;
Right ?
Thanks for your help and long life to Mailcow :-)
Looks ok, but there are other places like data/conf/rspamd/meta_exporter/pipe.php or data/conf/rspamd/meta_exporter/pushover.php (not pipe_rl). 
You can customize mailcow in many/all ways you want. I do already put a lot of free time in this project, but there are limits. If we integrated everything a few users might need, we would have much trouble supporting and maintaining mailcow and also introduce some nasty bugs. If you customze mailcow to your needs, it is absolutely fine for us, but we may not be able to provide support then. Your change is not that huge, but I think it needs a lot of testing and rework.
We have - as competitors - features that are unique. It depends on what you need. It does not put me in distress when alternatives are mentioned. The solutions are not really interchangeable in my opinion.
I appreciate your effort to make it work, it can help us integrate it at some point. Thank you! I would love to read about your results. If you like, you can add a new var to vars.inc.php to determine a delimiter to use.
@diekuh Yes I understood your point of view. Thanks for your explanations :-)
We currently trying with some new domains, and if all is ok for few days, we will move totally all our domains to Mailcow. We really like the fact you have a lot of updates, it’s not a dead project as there is a lot in this domain, this why Mailcow is our first choice.
We’ll revert back our change before applying an upgrade, for rspamd container, it’s sure we need to do that before, but is it also required on theses conf/php files inside /data/conf ?
Thanks