Prior to #7, authorized users could only send from a single email address. #7 allowed that field in the allowedUsers
file to be empty, allowing that user to send from any email address.
I would like to have more control, and allow something between 1 and ∞ addreses.
One use case I've identified is very common on Linux machines, running Postfix, where sendmail
(without -r
or any remapping) will send from [email protected]
. That same machine might also run an application that wants to send as [email protected]
This won't work with smptrelay
today, without allowing the server to send as (anyone)@example.com
which is more dangerous.
Options
I have a couple different ideas for handling this:
Option 1
Expand the allowedUsers
parts[2]
syntax even further with two enhancements:
- Allow
internal.example.com
(or perhaps @internal.example.com
) to mean (anyone)@internal.example.com
- Allow a comma-separated list of allowed email addresses
The config file for my stated usecase would be:
appserver bcrypt-password-hash [email protected],appserver.internal.example.com
Pros:
Cons:
Option 2
Update the allowedUsers
parts[2]
syntax to accept a regular expression.
The config file for my stated usecase would be:
appserver passwdhash ^(app@example\.com|.*@appserver\.internal\.example\.com)$
I'm not sure that this can be implemented without breaking backwards compatibility. For example, consider an old config file like this:
If we switched parts[2]
to unconditionally be a regex, then the pattern [email protected]
would erroneously also match:
There are options here:
- Break compatibility, release a v2.0 with a warning
- Require a prefix to use regex, e.g.
regex:
:
joe passwdhash regex:^.*@example.com$
- Require a config file option that enables regex (e.g.
allowed_users_uses_regex = true
)
- Try to auto-detect the use of regex (bad idea; very ambiguous)
Pros:
- Very flexible
- Consistent with other config options that allow regex (
allowedRecipients
, allowedSender
)
Cons:
- Less readable for most use cases
- Hard to implement without breaking backwards compatibility
I suggest Option 1. A regex is probably more powerful than any user will need, and there are a lot of characters allowed in the local-part of an email address that are special in a regex, requiring escaping.