-
-
Notifications
You must be signed in to change notification settings - Fork 790
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rework the anti-spoofing rule #2479
Conversation
Thanks for submitting this pull request. bors try Note: if this build fails, read this. |
tryBuild succeeded: |
I'm not sure if completely removing the anti spoofing is the best idea - even in 2022. |
This PR will introduce a change in behaviour. The anti-spoofing rule is now only covered by the SPF check. We should warn about this in the release notes. If there are people who did not publish the DNS records, we have at least warned them via the release notes that envelope-from (and also header-from) spoofing is possible now. For the linked issue, the user can use RELAYNETS as a workaround for now. And as ghostwheel said in the chat, we must test this thoroughly. |
Just to clarify:
I will investigate how we can get rspamd to do the right thing here: reject emails that pretend to be from locally hosted domains where DMARC validation fails (ie: neither SPF nor DKIM pass), regardless of the published DMARC policy |
bors try |
tryBuild succeeded: |
bors try |
tryBuild succeeded: |
If we want to go further than this, and match exactly what was done before, we should add a force_action rule: in multimap.conf
in force_actions.conf:
|
This restores the old behaviour
bors try |
tryBuild succeeded: |
bors try |
tryBuild succeeded: |
It looks like rspamd does not retry to load the map from the /internal/rspamd/local_domains endpoint. Can we tell rspamd to retry accessing the URL on failure? On first startup I saw the following in rspamd log
When sending a test email that spoofed the a local user, it was accepted. After restarting antispam, the anti-spoofing protection worked. The email was blocked.
|
bors try |
tryBuild succeeded: |
This reverts commit 0f17299.
Hmmff. I will just add a sleep-loop workaround The level of complexity to get this to work properly is very high and I really think that it's out of scope for this PR.
We probably can't and shouldn't load up nginx until all the containers are up. |
bors try |
tryBuild succeeded: |
I don't see the print line. It doesn't bother me. People will not notice it anyway. But I suspect it will be logged when using the module logging:
I'm not sure if level info will be visible. At least it is working. The map is successfully downloaded on every redeployment (with recreating all containers). |
I already tested that sending email with spoofed envelope-from/header-from works if the SPF allows it. A small list we need to further test:
|
@Diman0 what do you mean by relayMX, Relayed domain?
|
Yes. I mean relayed domain. So I will test the same things you apparently already tested successfully. It is important to test all these paths because rspamd is used when email is received and when it is send. It might also be relevant to test fetchmail. Email inboxes synced with fetchmail should also trigger rspamd. |
the latest change around delaying rspamd start-up did not work for me, but I realize you changed the admin container as well:
so I have now 3 images live for testing:
|
The test build is working well so far. We have all our mail servers running with the latest build for the past 6 days and I found on our primary mail servers and relay servers emails rejected successfully and the rest working as expected, the only thing we don't use at all and therefore couldn't test is fetchmail. And its really beneficial for debugging misconfigured sender to have all the rejected mails in rspamd history |
Using this specific test build might be fine. Using master is not recommended. The active development branch (master) will contain breaking changes. We also do not guarantee that the master images offer a working Mailu stack (although we strive to achieve this of course). Thank you for confirming everything works as expected! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
bors r+ |
Thanks for the clarification, and yes we use 1.9 for all other services. plus the test build for rspamd admin and postfix. |
Build succeeded: |
will this be added to the 1.9 container build? |
That's not planned. While it's undeniably broken, this PR adds new features too and changes the current behavior. |
Thanks @nextgens, that makes sense :) How would you address this temporarily in a production system.
|
I'd override the minimum to make it work (probably disabling anti-spoofing altogether) and wait for next release |
What type of PR?
Feature
What does this PR do?
We shouldn't assume that Mailu is the only MTA allowed to send emails on behalf of the domains it hosts.
We should also ensure that it's non-trivial for email-spoofing of hosted domains to happen
Previously we were preventing any spoofing of the envelope from; Now we are preventing spoofing of both the envelope from and the header from unless some form of authentication passes (is a RELAYHOST, SPF, DKIM, ARC)
Related issue(s)
Prerequisites
Before we can consider review and merge, please make sure the following list is done and checked.
If an entry in not applicable, you can check it or remove it from the list.