Postfix includes the possibility of having virtual email addresses. The NixOS postifx module supports these in three varieties of table for defining such aliases: hash, regexp and pcre, the first being the default. The module has the options aliasMapType and virtualMapType for overriding the default.
By setting services.postfix.aliasMapType = "regexp"; I can receive mail at regexp-defined virtual addresses, but not send from them. Setting services.postfix.virtualMapType has no effect on the behaviour of the server that I have managed to observe.
Sending from non-regexp virtual addresses works without any problems.
The aliases defined in my mailserver configuration in configuration.nix end up in at least 3 files on the server:
/var/lib/postfix/conf/valias
/etc/postfix/virtual
/etc/postfix/vaccounts
Setting the *MapType options to "regexp", affects the declaration of /etc/postfix/virtual in main.cf, but the other two files remain declared as having type hash. Specifically, /etc/postfix/master.cf contains two occurences of -o smtpd_sender_login_maps=hash:/etc/postfix/vaccounts.
So it seems likely that the latter would need to have hash replaced with regexp in order to enable sending from regexp-defined virtual accounts.
I get an error stating that this definition conflicts with another one
The option `services.postfix.submissionsOptions.smtpd_sender_login_maps' has conflicting definition values:
- In `/nix/store/5bv2za0lzdn8ap3wa0y6dp6npxfwfxxz-source/mail-server/postfix.nix': "hash:/etc/postfix/vaccounts"
- In `/etc/nixos/configuration.nix': "regexp:/etc/postfix/vaccounts"
I cannot see where this might have been generated, and that’s where grind to a halt.
Can you suggest how to achieve the ability to send from regexp-defined virtual adresses in NixOS Mailserver?
Generically, if you want to override an optionthat seems to have a unique definition, the first thing to try is option = mkForce value; instead of option = value. No guarantees it will achieve anything useful, but more likely than not it will let the thing build.
This does indeed make it build, and regexp has replaced hash in the smtpd_sender_login_maps settings in master.cf, but I still get
Sender address rejected: not owned by user
so looks like I’m still missing some piece of the puzzle.
[Aside: why does master.cf have two identical sections, submission and submissions which differ only in the missing/present s at the of their name? All the -o smtpd_*s in those sections are identical.]
Well, now that might have become a Postfix question. So, any logs? (Preferably after increasing the verbosity…) Also, I think there is some Postfix access control that might require an exact match and ignore the maps?
Mar 13 17:22:06 nixa postfix/smtpd[679509]: NOQUEUE: reject: RCPT from
my.domain[42.42.42.42]: 553 5.7.1 alice-suffix@my.domain: Sender address
rejected: not owned by user alice@my.domain; from=alice-suffix@my.domain
to=alice-suffix@my.domain proto=ESMTP helo=<webmail.my.domain>
How would you do that? journalctl -o verbose doesn’t give any more information than just journalctl.
Yes, I’m way beyond that stage, as I’m using not only aliases but also extraVirtualAliases. Specifically the alice-suffix@my.domain alias in the error shown above, matches a regexp in extraVirtualAliases.
As I said, all these aliases work fine (for both sending and receiving), as long as no regexps are involved. The problem is about getting the whole setup to understand that these alias tables are regexp rather than hash tables … and this already works for receiving. So what remains is to get all the relevant pieces involved in sending, to understand that these are regexp tables … if such a thing is possible.
When the mkForce hack is in place, sending from non-regexp aliases stops working.
Naturally, as it overrides the thing NM generates for non-regexp aliases.
Of course, because this is after the logging has happened.
Maybe it is a better idea to open an issue for regexp alias support in the mailserver module github repository linked from the homepage? You are clearly beyond the supported functionality of the module, and I think there seems to be a more natural place if you really want to discuss non-trivial expansion of Postfix configuration facilities in the module (and at the same time you don’t have a specific override to Postfix config you want to try applying).
I’m not sure whether this is an issue in NM or postfix.
Half of what I needed to do (related to receiving), I have already achieved with postfix module options. Perhaps the other half (related to sending) can be achieved by adding similar options to postfix. This would suggest that NM is not the right place to open an issue (which I have already done, ages ago).
Details
It’s not obvious to me that this is the problem. In the case of sending, using the postfix module’s support for regexp maps replaces hash with regexp in the files that NM generates, simply stating that these tables should be interpreted as regexp tables. This hack seems to do exactly the same for the SMTP side of things … as far as I can tell. But there are bound to be things I’ve missed.
Oh, I see: you wanted the logging level raised before trying to send the message. How would you do that?
You mean like this one that I opened a month ago, which has had no response or acknowledgment from the maintainers whatsoever?
Admittedly, at that stage I didn’t know about postfix regexp tables. Today I would be able to open a more precicely targeted request.
But I’m not sure that NM is the appropriate place to ask for this: I’ve managed to enable receiving for such aliases without changing anything in NM, simply by discovering and using the NixOS postfix module’saliasMapType and virtualMapType options.
Given that postfix itself already has aliasMapType and virtualMapType (for the purpose of switching between hash and regexp lookups), adding something like an smtpSenderLoginMapType (which is what seems to be needed from my naive perspective) it looks to me that postfix is more likely to be the place where this should be implemented. But I’m far from sure about this, as I don’t really understand how the two interact and which takes on which responsibilities.
Ugh. This is one of the pain points of Nix: it would take me about 18 seconds to follow these instructions outside of Nix, but here I have to track down how to persuade the module I happen to be using to inject it in the right place without breaking anything else. Sigh.