Allow regex in email address aliases

[chaserdoe]

Implemented #2507

[dragoangel]

Hm, aliases in mailcow not only allow incoming mail, but also and outgoing. Does this work here? Also regex aliases not break alias expanding in rspamd?

[chaserdoe]

Do you mean address rewriting? I only implemented regex for incoming mail aliases. What exactly do you mean by alias expanding? The global filter maps seemed to work fine.

[dragoangel]

1. Any user that has alias allowed to use this address in from header (identity).
2. Rspamd per user settings such as tagged mail or whitelist on user only applies on user itself, but mailcow has script to expand alias to original user to apply this settings correctly in case with alias also.
   Does your PR not break this futures?

[chaserdoe]

1. Works now, but sogo prevents from headers, which are unknown to it. Works fine in other mail clients though.
2. Seems to work fine.

[dragoangel]

Hi @andryyy what you think?:)

[mbretter]

any chance getting this merged?

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[Levivb]

this looks like a very decent feature to support. any chance of getting this merged? I might need it to create a <some-prefix>.<whatever-here>@domain.com

for examplemb.*@domain.com (or maybe mb\.[\w-][email protected] regex style) which would allow [email protected]

[gnasch]

If I understand this correctly this would allow to bind aliases to the services they are used for. This is great because they will refrain from selling traceable addresses, and they can selectively be revoked.

[patschi]

That's indeed a neat feature!
@chaserdoe would you please so kind solving the conflicts on your PR?

I'd like to wait for a quick check and OK from @andryyy before merging it.

[retoo]

This is awesome and absolute critical for my migration path. I'm looking forward to try this!

[apharp]

This is awesome and absolute critical for my migration path. I'm looking forward to try this!

Me too! Really looking forward to this feature!

[Ulrar]

I was just writing a feature request for this, great to see someone already did the work !
Also would be very happy to this see merged, that's what I'm missing to migrate.

[retoo]

@chaserdoe FYI there was some refactoring in upstream

As far as I can tell these changes were done:

• the form field got refactored from edit.php to alias.twig
• it now uses twig notation (instead of pure php)

I'm not very fluent in php, maybe you have a chance to merge in the latest changes. Otherwise I will give a try sooner or later.

Beside that: the regexp alias feature has worked very well in the last two months at my installation.

[retoo]

I've just created an offical ticket asking for the merge of this PR. I offered buying another SAL, maybe some of the watchers are also interested and could chime in. Merging this feature probably is just a few hours of work (plus maintaining it of course).

Cheers
Reto

[andryyy]

This will have so many bad effects on routing, policies and spam filter settings that I’m against merging it. I will not veto it, feel free, I will not support it though.

[retoo]

@andryyy I understand that, and I had some corner cases myself in the past 9 months, but on the other hand it's a feature I which is extremely useful I cannot give up, I have 15 years of 'reto-company-.*' email addresses ;). So maybe it just needs a very fat disclaimer with all the corner cases that are not supported (i.e. sending mails from SOGo).

[apharp]

Not sure what the status of this is, or if it will be supported but I found a quick, dirty, unsupported workaround that's been working for me for the last few months.

Step 1

Create regex virtual map file for postfix

nano data/conf/postfix/regex.cf

This is where you will create your regex rules.

/^someprefix\.(.*)\@(yourdomain\.com)/ [email protected]
/^(reg|regex)\.(.*)\@(yourdomain\.com)/ [email protected],[email protected]

Step 2

Next configure the extra.cf to look for this file. NOTE: since you are replacing virtual_alias_maps from the main config (main.cf) you MUST include the original alias maps + your new alias map.

nano data/conf/postfix/extra.cf

Add this line

virtual_alias_maps = proxy:mysql:/opt/postfix/conf/sql/mysql_virtual_alias_maps.cf,
  proxy:mysql:/opt/postfix/conf/sql/mysql_virtual_resource_maps.cf,
  proxy:mysql:/opt/postfix/conf/sql/mysql_virtual_spamalias_maps.cf,
  proxy:mysql:/opt/postfix/conf/sql/mysql_virtual_alias_domain_maps.cf,
  regexp:/opt/postfix/conf/regex.cf

Step 3

Run postmap

docker-compose exec postfix-mailcow postmap /opt/postfix/conf/regex.cf

Step 4

Reload postfix

docker-compose restart postfix-mailcow

[aHcVolle]

Not sure what the status of this is, or if it will be supported but I found a quick, dirty, unsupported workaround that's been working for me for the last few months.

Step 1

...

I Just tried it and this is working fine.
Thanks for this tip :)

[RafaelKr]

Thank you for this workaround!

BTW my use case would be to have an alias for dmarc@* which forwards this for every domain to [email protected]. [email protected] is the inbox which is scanned by https://github.com/patschi/parsedmarc-dockerized and currently I have to create an alias for every domain manually.

[axello]

+1 (also coming from self-hosted postfix server where I used the regex. Now I have to edit the regex file in the postfix docker container, which is sub-optimal. (but doable, as the regexes do not change often.)
Thanks for the detailed guide above!

[IGLOU-EU]

I've taken a keen interest in this PR and after reading through the comments, I understand some of the concerns that are raised.

Instead of using full regex, we could limit ourselves to wildcard support. We can implement this by using the PHP glob() function, which is simpler and less risky compared to a full regex implementation.

@andryyy Before proceeding, I'd appreciate your thoughts on this. Could this approach address some of your concerns? Could you elaborate a bit more on the potential problems you foresee with this use case so that I can create some test scenarios?

---

EDIT:

After some discussions with the mailcow team on the telegram chan. This feature is not expected and never be merged.
But Algoo company need a simple pattern matching like wildcard *[email protected], so we have made a fork.
Any information in our implementations here #5

[retoo]

@andryyy hey could you imagine working/accepting on solution that works like the "workaround" described by andy (apharp) in #4015 (comment)

I.e. no gui support, and just accepting a new file at a certain path (which is empty by default installation). the difference to the workaround would just be, that we don't have to overwrite the built-in 'virtual_alias_maps'

What do you think?