Viktor, do you mind clarifying why you don't think it's sensible behaviour? Like, what specifically is wrong with this approach? Perhaps I'm missing something important.
I don't mind adding a script to merge aliases, and it may be what I end up doing. I see both pros and cons with this approach. However, after looking at postalias/postmap source code I realise that parsing those files isn't trivial. Therefore, adding a -m option, which trivially modifies the dictionary put logic into a dictionary merge operation would make more sense from where I'm standing. > piling on C-code in postmap/postalias to do the same thing. I don't think it would be more than a few lines - if merging, when duplicates are found, rather than printing a warning/error, you'd concatenate the existing record with the new one. Noel - adding SQLite3 is still a much larger surface area than aliases alone, but I see it could be a solution. I don't actually want a DBMS, I just want to add a few aliases. It won't grow beyond that. The downside of this approach is that it necessitates changes to the main postfix config, which I'd rather avoid, since this then needs to be re-applied each time the postfix package is updated. While working through this, I thought of one more situation where modifying /etc/postfix/aliases isn't great - when you have a package manager supplied set of defaults, but you want to add user-specific ones. It would be nice to have a system supplied /etc/postfix/aliases, plus any user specific ones, e.g. /etc/postfix/aliases.d/$username - it would mean that upgrading the postfix package would work more seamlessly as /etc/postfix/aliases could be updated without affecting user supplied aliases.
