feat: SPOOF_PROTECTION=1 support config to relax sender restrictions by login#4044
feat: SPOOF_PROTECTION=1 support config to relax sender restrictions by login#4044ncovercash wants to merge 8 commits intodocker-mailserver:masterdocker-mailserver/docker-mailserver:masterfrom ncovercash:add-send-only-aliasesncovercash/docker-mailserver:add-send-only-aliasesCopy head branch name to clipboard
SPOOF_PROTECTION=1 support config to relax sender restrictions by login#4044Conversation
|
Documentation preview for this PR is ready! 🎉 Built with commit: 99514c1 |
We forbid aliasing an actual account. So that is presently not possible. Sharing an alias to multiple recipients is though (not officially endorsed/supported by DMS however).
Isn't that the same as what this PR proposes by introducing a new regexp config to manage which sender addresses a user login (DMS account / address) can use? Or you are referring to only the additional integration in #!/bin/bash
# Include `regexp-send-only` to relax `SPOOF_PROTECTION=1` sender address restrictions for specific logins:
cp -f /tmp/docker-mailserver/postfix-regexp-send-only.cf /etc/postfix/regexp-send-only
postconf 'smtpd_sender_login_maps = unionmap:{ texthash:/etc/postfix/virtual, hash:/etc/aliases, pcre:/etc/postfix/maps/sender_login_maps.pcre, pcre:/etc/postfix/regexp-send-only }'Initial Review / ConcernsI'm a little confused, while there is value in this PR,
|
polarathene
left a comment
There was a problem hiding this comment.
- I need to push out a rewrite docs that affects
user-management.md. Your change will need to be adjusted to that afterwards. I'll try get that done for you by this weekend. - Likewise the
CHANGELOG.mditems will need to be rebased after the v14 release. This is too late to land in that and will have to be delayed to 14.1. - I've not reviewed the test contribution yet, I have seen your questions but will address that closer to resolving this PR as I'm a bit short on time and this is touching an area of functionality that has known issues already.
unionmaplogic inspoofing.shwon't be accepted. I think my existing PR has concerns related to this area with LDAP, so that may need to be addressed prior. All you're really doing here is appending a string of additional files, which could be handled via variable.
A good contribution overall, I was only expecting docs so I apologize about any blockers I'm responsible for. I'll see what I can do to get those out of the way.
| ```cf | ||
| /^.*@example.com$/ admin@example.com | ||
| /^.*$/ superadmin@example.com | ||
| ``` | ||
|
|
||
| In this example, `admin@example.com` would be able to send as any address at `example.com` and `superadmin@example.com` would be able to send as any address at any domain. |
There was a problem hiding this comment.
superadmin@example.com will not be able to send as user@example.com AFAIK, this is a caveat with regex lookup tables that you need to be aware of. The 1st match from top-down on the sender address will then check to the right-side value(s) for permitted logins (which are often email addresses in DMS, but they could just be user names).
You did not escape . for .com in the regex, in this example it shouldn't be a real issue, since alternative characters aren't going to produce a valid sender address, but it's still a caveat to be careful of:
jan.doe@example.com would also grant janedoe@example.com sender address to the login account, which might be a security problem when using the feature for accounts that aren't admins.
There was a problem hiding this comment.
Good catch on both counts; I'll clarify that in the documentation and warn about the caveats.
It looks like the following would allow superadmin@example.com to get the desired effect:
| ```cf | |
| /^.*@example.com$/ admin@example.com | |
| /^.*$/ superadmin@example.com | |
| ``` | |
| In this example, `admin@example.com` would be able to send as any address at `example.com` and `superadmin@example.com` would be able to send as any address at any domain. | |
| ```cf | |
| /^.*@example.com$/ admin@example.com superadmin@example.com | |
| /^.*$/ superadmin@example.com | |
| ``` | |
| In this example, `admin@example.com` would be able to send as any address at `example.com` and `superadmin@example.com` would be able to send as any address at any domain. | |
| ...some notes about needing to order/etc |
| } | ||
|
|
||
| function _handle_postfix_regexp_send_only_config() { | ||
| : >/etc/postfix/regexp-send-only |
There was a problem hiding this comment.
I'd prefer not creating a file explicitly when it's not used.
There was a problem hiding this comment.
I was just copying the regular postfix-regexp logic here — would I be OK to also remove the same thing in the _handle_postfix_regexp_config() above (and corresponding # TODO: Investigate why this file is always created, nothing seems to append only the cp below? comment)?
There was a problem hiding this comment.
There's probably a related issue already open about details for that.
Without looking for that, I can't quite say. I've not had as much time for DMS as I'd like, but if the change was delayed I may have detailed why. I'd leave it alone for now, unless you have time to sink 😅
Proper actionable feedback from me is going to need to wait until I have the time to refresh on related context like this. I'll try to get that sorted for you by this weekend if possible, sorry about the friction that adds.
| if [[ -f /etc/postfix/regexp && -f /etc/postfix/regexp-send-only ]]; then | ||
| postconf 'smtpd_sender_login_maps = unionmap:{ texthash:/etc/postfix/virtual, hash:/etc/aliases, pcre:/etc/postfix/maps/sender_login_maps.pcre, pcre:/etc/postfix/regexp, pcre:/etc/postfix/regexp-send-only }' | ||
| elif [[ -f /etc/postfix/regexp-send-only ]]; then | ||
| postconf 'smtpd_sender_login_maps = unionmap:{ texthash:/etc/postfix/virtual, hash:/etc/aliases, pcre:/etc/postfix/maps/sender_login_maps.pcre, pcre:/etc/postfix/regexp-send-only }' | ||
| elif [[ -f /etc/postfix/regexp ]]; then |
There was a problem hiding this comment.
Not acceptable. See the related SPOOF_PROTECTION=1 issue.
This section needs to be refactored to unify with LDAP. You'll need to wait on that being resolved. I am adding friction here due to blockers I introduce external to this PR, I'll need to address those first.
Yes; the primary purpose of this was to have a more "DMS-friendly" way that would 1) be supported in the documentation and 2) not require the user directly patching the main.cf. Sure, this could all be accomplished by a user adding their patches, but theoretically so is most of the config, so it seems like it'd be good for DMS to support/expose what it can?
Sure; I can edit the commands to prepend the user-provided configuration above this and use the same file; I personally felt it was a little cleaner to have separate files for this and the user-provided ones. Your judgement there, just let me know what would be best.
Yes; I can rewrite the added documentation if there's a better way to describe it (maybe "permitted sender addresses"?). Let me know if there's a name you would prefer.
This feature does not overlap, since
Good catch; I can change to a non-regex version, I just wanted to align closely with the existing
I personally use |
SPOOF_PROTECTION=1 support config to relax sender restrictions by login
I'm happy to hold off, I did not realize there were blockers. I have this temporarily worked around on my local mailserver, but I wanted to make a better experience for those who came after me. And no worries, I thought this would be a doc-only thing and then I realized it was (relatively) easy to add first-class support and figured may as well. No rush at all, let me know when I need to update my changes to align with yours. Thanks for the review! |
AFAIK It's probably best that we keep
I think it would be simpler to document and support a non-regex table. If some users request regex support, then we could add that as another file.
👍 No worries, we can have both then :)
Thanks ❤️ I really want to resolve the LDAP PR and related docs rewrite this month. The LDAP test also touches on After that I can better go over the related So uhh, if you're comfortable with it, perhaps best to just wait until later this month before taking any further action. |
|
Sure thing, no worries! @ me when you're ready to proceed! |
|
Hi @ncovercash, I just have some security concerns about the admin@example.com/ superadmin@example.com send email as user@example.com
|
They're an admin, it would not be surprising for them to have elevated permissions to do things that could be abused. That concern is unrelated to this feature.
No. Without The PR here is just to allow relaxing what additional sender addresses can be used per user. A sent folder is something your mail client keeps on it's end AFAIK (unless your mailbox in
Not with this feature. If the admin has control of the DMS deployment they can do whatever they want with the container really. AFAIK, your mail client submits mail to DMS when you want to send mail out, that will temporarily be stored in a mail queue, and then is sent outbound to an external mail server or delivered to a mailbox within DMS. So if the sent copy is only kept with your mail client storage (like Thunderbird), it can't be touched. If it's in
Technically yes. If your response is submitted to DMS, Postfix will receive it and it'll end up in the queue. It could be monitored and read there if that is the only time it is available in transit. That requires actual access to the DMS container, not just a DMS user account (Postfix/Dovecot login). Otherwise same caveats regarding deleting a sent copy as for being able to read one. There is an on-disk encryption feature for You can have your mail client use PGP encryption so long as the recipient also has this configuration to decrypt the mail, and then the mail is always encrypted between systems, DMS won't know the contents or be able to access it then. |
Description
Currently, the only way to allow a user to send mail as another user (for example, to allow
admin@example.comto send asuser@example.com) would be to:SPOOF_PROTECTION(undesirable as it would allow any user to spoof any other user)user@example.comtoadmin@example.com(undesirable asuser@example.com's mail would be sent to theadminmailbox)To improve this experience, this PR adds a new configuration file,
postfix-regexp-send-only.cf, which allows configuring send-only aliases. These aliases differ from regular aliases in that they do not affect incoming mail, only outgoing, enabling admin/system accounts to send as other users, and with all the granular access control which regex can offer.Some use cases could include:
Fixes #4042, relates to #2819
Type of change
Checklist
docs/)CHANGELOG.mdQuestions
test/tests/parallelshould my tests go in? I did not see any that related to postfix/auth, so I created a folder insideset2as it seemed to be the smallest test set; please let me know how this should be organized to best fit in with the rest of the tests.tests.batsinto this separate parallel file, since they cover the same cases.