-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Rspamd rejects asciinema
e-mails
#4007
Comments
Please note that this response was created using generative AI, leveraging previously available information from the repository. This information may be helpful. However, it is our strong recommendation that you carefully consider the information before blindly applying it. It appears that the email from To address this issue, you can adjust the rspamd settings to prevent legitimate emails from being rejected as spam. Here are a few steps you can take:
For specific instructions on how to configure rspamd settings, you can refer to the rspamd documentation or the configuration files used in your Docker Mail Server setup. This comment was generated by Glime. |
Could you please try reproduce the failure with the |
I switched to
|
I've ran asciinema through https://www.mail-tester.com/ and it got 10/10 so it shouldn't be a configuration issue on their end. Also Gmail accepts the email and so does my other email provider. Only my server has issues with this. Is this some kind of a configuration issue? I have not seen a single email in my spam folder I think. It looks like Spam emails are just rejected instead of moved. I know that Spam score 11 means email not received but IDK why only my instance would score their emails like that. Also I see that some emails have a spam score - eg. a Github Education email had 5.74. But again - I haven't seen a single email moved to Spam so it looks like everything considered spam is rejected. |
Could this be an issue with the |
Remove this ENV unless you have a good reason for it? But I see that I missed it in the example EDIT: The scripts actually still use this it seems, and without having the time to verify we can drop that ENV (I'm pretty sure it was fine to in the past) I'll hold off from making that change for now. docker-mailserver/target/scripts/helpers/ssl.sh Lines 169 to 181 in 016d6b5
docker-mailserver/target/scripts/helpers/ssl.sh Lines 111 to 127 in 016d6b5
I've heard that the ARM rspamd has been iffy in the past, not sure if it's relevant here since it's about spam score rather than anything crashing.
That might be helpful? It's from the HELO greeting when asciinema delivered mail and was rejected as spam. That type of mismatch with the hostname not resolving to the IP it's coming from is sometimes a security check to reject mail on or regard more likely as spam. I don't manage rspamd in DMS, so I'm not sure if it's been configured that way. @georglauterbach will try assist if he can when he has the time to spare :) I'm sure he'd appreciate more insight into your configuration ENV / files as it may be possible you have a misconfiguration or something about how you've configured DMS affects reproducibility. Mostly we lack time to provide much support wise, especially when other users are not chiming in with the same issue to help pin down the cause. It's much easier for us to respond to bugs when users are able to troubleshoot the issue to narrow down where DMS is at fault. In the meantime, you could try with our defaults instead of rspamd to see if the same issue occurs. It might help isolate if it's rspamd specific. Alternatively, mailu and mailcow projects use rspamd too IIRC, if you don't mind trying those out and letting us know if the issue occurs with another mail server rspamd deployment, that'd be insightful 👍 (if there is no issue with another mailserver using rspamd, we could probably compare configuration differences to pinpoint the problem) |
I have no problem with switching to spamassasin and opendkim but from what I saw it was better to run rspamd as it looked easier to setup and the dkim setup was cool too. Will there be a DKIM problem when I switch? Will I have to generate a new key and set it on my DNS? |
Please have a look at the Rspamd log (our Rspamd docs describe the location) and see how such a score came to be. Post the result here, please. I suspect a (temporary) DNS issue. A hostname mismatch causes a +6 in the spam score. Why? Because of
DNS is, in my experience, the most frequent source of errors. We have a dedicated section in our docs on this issue as well (with a big warning and error admonitions). |
Here's the related part of
|
Exactly what I predicted: |
Just to confirm, you've got the reverse DNS resolving in the container correctly? One gotcha you can run into is the default DNS used fails (using # Default DNS is via router 192.168.65.7 on this system, it always fails rDNS lookups:
$ docker run --rm -it ghcr.io/natesales/q --verbose --reverse 64.147.123.154
DEBU[0000] Name: 154.123.147.64.in-addr.arpa.
DEBU[0000] RR types: [CNAME PTR A AAAA NS MX TXT]
DEBU[0000] No server specified or Q_DEFAULT_SERVER set, using /etc/resolv.conf
DEBU[0000] found server [192.168.65.7] from /etc/resolv.conf
DEBU[0000] Server(s): [192.168.65.7]
DEBU[0000] Using server 192.168.65.7:53 with transport plain
DEBU[0000] Using UDP with TCP fallback: 192.168.65.7:53 # While setting the container DNS to use cloudflare 1.1.1.1 works:
$ docker run --rm -it --dns 1.1.1.1 ghcr.io/natesales/q -v -x 64.147.123.154
DEBU[0000] Name: 154.123.147.64.in-addr.arpa.
DEBU[0000] RR types: [AAAA NS MX TXT CNAME PTR A]
DEBU[0000] No server specified or Q_DEFAULT_SERVER set, using /etc/resolv.conf
DEBU[0000] found server [1.1.1.1] from /etc/resolv.conf
DEBU[0000] Server(s): [1.1.1.1]
DEBU[0000] Using server 1.1.1.1:53 with transport plain
DEBU[0000] Using UDP with TCP fallback: 1.1.1.1:53
154.123.147.64.in-addr.arpa. 56m6s PTR wfhigh3-smtp.messagingengine.com. It's possible that rspamd may be configured to use something else internally (I think that's supported, but AFAIK DMS does not mess with it). I also recall Docker in the past year had a bug with a release with DNS too. I don't recall specifics, but it might help to ensure you're using the latest Docker + Docker Compose if a DNS issue remains.
I don't think MX record matters here? Here's what Postfix does (disabled in DMS by default, but I'd assume it's similar with the roughly equivalent rspamd feature being discussed?):
So For MX records, a common problem is when one doesn't exist causing SPF checks to fail and reject bounce the mail (common problem with mailgun apparently). DNS queries for reference: $ docker run --rm -it ghcr.io/natesales/q wfhigh3-smtp.messagingengine.com
wfhigh3-smtp.messagingengine.com. 26m14s A 64.147.123.154
wfhigh3-smtp.messagingengine.com. 23h38m51s TXT "v=spf1 include:spfall.messagingengine.com ~all"
$ docker run --rm -it ghcr.io/natesales/q spfall.messagingengine.com
spfall.messagingengine.com. 24h TXT "v=spf1 ip4:103.168.172.0/24 ip4:64.147.123.0/24 -all"
$ docker run --rm -it ghcr.io/natesales/q hello.asciinema.org
hello.asciinema.org. 1h MX 10 in1-smtp.messagingengine.com.
hello.asciinema.org. 1h MX 20 in2-smtp.messagingengine.com.
hello.asciinema.org. 1h TXT "v=spf1 include:spf.messagingengine.com ?all"
# `/27` subnet range for SPF is 64.147.123.128 => 64.147.123.159 (thus valid for IP above)
$ docker run --rm -it ghcr.io/natesales/q spf.messagingengine.com
spf.messagingengine.com. 24h TXT "v=spf1 ip4:103.168.172.128/27 ip4:64.147.123.128/27 -all"
# MX records resolve to these IP:
$ docker run --rm -it ghcr.io/natesales/q in1-smtp.messagingengine.com
in1-smtp.messagingengine.com. 1h A 103.168.172.216
in1-smtp.messagingengine.com. 1h A 103.168.172.217
in1-smtp.messagingengine.com. 1h A 103.168.172.218
in1-smtp.messagingengine.com. 1h A 103.168.172.219
in1-smtp.messagingengine.com. 1h A 103.168.172.220
in1-smtp.messagingengine.com. 1h A 103.168.172.221
$ docker run --rm -it ghcr.io/natesales/q in2-smtp.messagingengine.com
in2-smtp.messagingengine.com. 1h A 64.147.123.51
in2-smtp.messagingengine.com. 1h A 64.147.123.52 So all looks good there:
MX for the HELO is not relevant AFAIK. If mail is to be bounced it should use the return-path header in the mail IIRC, or bounces it back to the mail server already connected to handle. No MX lookup needed on the HELO FQDN. So please confirm that you can perform rDNS via a container on the Docker host running DMS, like I showed above with the You should have If it's not due to this gotcha, then I am a bit puzzled why you'd still get that warning 🤷♂️ You could try disabling the check temporarily via rspamd config perhaps? |
The command you supplied doesn't work as there's no arm64 image. Also the repositoried in DMS image are broken so I cannot install
I"ve set the container to use Cloudflare: dns:
- 1.1.1.1
- 1.0.0.1
I think I encountered it, that's why I have manually set 1.1.1.1 on some containers.
I'd rather not. I don't know hot that config works and I don't like running "specialized" setups that I have to fix every major release. |
Oh that's a shame it's quite a nice dns tool!
You can also get an ARM64 binary of
Awesome, just wanted to double check to be sure 😅
Fair enough 👍 So there's no reason rspamd should have trouble resolving DNS properly then? I don't know why you'd get that warning still 🤷♂️ Someone will have to spend time to troubleshoot the problem to better isolate the cause. I'm out of ideas 😭 If you really want to push it along without tackling that yourself, it may help if you can reproduce it between two DMS container instances which allows for isolating into an offline environment fully under our control. I understand if that's too much hassle, but I'm also a bit surprised no one else is reporting similar issues 🤔
Could you chime in with what version of Docker and Docker Compose you're running? |
I know but
I use the v2 plugin, not the old binary:
If you'd help me set up such environment I'll gladly do so. I'm not that familiar with mailservers (that's why I use DMS) but I'm happy to help.
AFAIK not that many people use asciinema. I reckon that a pretty small number of people that
|
Is there a way to migrate DKIM from rspamd to opendkim? I'd try to switch from rspamd to see if spamassasin will do the same. But I don't really want to mess my dkim up - I don't want to wait for my DNS records to propagate (it's on Cloudflare so it's quite better but still) |
I've switched to spamassassin and it receives emails from asciinema without any issues. I've tried to migrate the DKIM key from rspamd to opendkim so I'll see whether that works. |
Ok, I managed to setup spamassassin and opendkim. Opendkim even has my old key now (luckily it's not that hard to follow the files and the config) so I'm set up without any issues now. I have both |
Probably related to why you have this problem with rspamd failing to resolve? Something in your environment related to networking is broken? $ docker run --rm -it --platform linux/arm64 mailserver/docker-mailserver apt update
Get:1 http://deb.debian.org/debian bullseye InRelease [116 kB]
Get:2 http://deb.debian.org/debian-security bullseye-security InRelease [48.4 kB]
Get:3 http://deb.debian.org/debian bullseye-updates InRelease [44.1 kB]
Get:5 http://deb.debian.org/debian bullseye/main arm64 Packages [7957 kB]
Get:4 https://rspamd.com/apt-stable bullseye InRelease [3161 B]
Get:6 http://deb.debian.org/debian-security bullseye-security/main arm64 Packages [270 kB]
Get:7 http://deb.debian.org/debian bullseye-updates/main arm64 Packages [16.3 kB]
Get:8 https://rspamd.com/apt-stable bullseye/main arm64 Packages [1569 B]
Fetched 8456 kB in 10s (874 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
37 packages can be upgraded. Run 'apt list --upgradable' to see them.
Ok that's great, what about the main Docker engine though? ( For reference I'm on
I demonstrate here a basic relay setup all managed self-contained in a single I also have this example from 2022 with CoreDNS, and a revised version of that adapted to another response (also 2022), while in Feb 2024 I put together this more recent example with CoreDNS (however this is to demonstrate a different solution so it's config would need to be adjusted, the example also only caters to a single DMS instance to receive mail, but of potential value is the inline TLS config). I have documented how to create local certs that you can test with (or you can just use the existing ones at that link that we use for our tests for Unfortunately I'm low on time, so I can't help atm to simplify the references into a config + instructions that's adapted to your needs, but they should at least provide insight on how to go about getting a local reproduction environment that you could then easily share if you can reproduce what However: As the
Right, but we still have quite a lot of DMS users (although not quite near the pull count that the original Only a small portion of the users are likely to opt-in to rspamd probably, but we still get reports from those giving it a try and often suggest users to try it instead of the defaults to confirm if it fixes some issues reported. I wasn't thinking about |
Bit tired, but I think this link may help with that. At least it explains how to generate DKIM key files agnostic to either tool, you then just need to place them in the expected locations. The config files separate to each service may need to be created though. Eventually I'll have time to tackle that issue to implement what I've detailed there and it'll become much simpler in a future DMS release.
Oh.. awesome then! You already sorted it out. Glad to hear that the issue doesn't occur with SA. @georglauterbach did point out the specific rspamd config responsible for it. I don't know if that has an opt-out in DMS, so as mentioned you'd need to manually override it AFAIK. I don't know about SA having an equivalent, but I did mention earlier what a rough equivalent was in Postfix, and the DMS ENV that enables that (as unlike rspamd it is opt-in). Toggling that is likely to cause the same problem.
Great! I'm just not sure what we can do to fix, other than to add support to opt-out of the feature in rspamd. I'm not sure if that's actually needed via an ENV, or if it's just a simple config file that we already support (I'm not familiar with the rspamd config much, @georglauterbach can chime in on that). Other than that, I'm not sure if there's anything we can fix, as previously mentioned your network environment seems to be faulty in some manner if |
I don't think so because it's fine until I run it in my production container. Here's a recording of the tests:
Because of the issue persisting only in the container I think it's something with the config I have (see the recording). I'll look through the Edit: I'm uploading the recording in case I ever were to delete it. |
Ok I thought that I'd give the But everything works as expected so that's not the issue. |
Try recreating the container? It's an important remedy for many issues that can't be reproduced well. So common that we really try draw attention to it on our troubleshooting docs page and direct users to before starting their report: Perhaps you did follow that advice, but I noticed we didn't discuss it yet and with your last comment noting that FWIW, when I used Docker in VMs that I suspended, the containers would lose network connectivity upon restoring the VM requiring the daemon to be restarted IIRC. There can be lots of these weird networking gotchas with all the layers/abstractions involved. |
That was one of the first things I tried but I can try again. I tried to update the container (this recreates it in Portainer), then it was recreated when I switched to
This system does not suspend at all. It's a Raspberry Pi working 24/7 (I did update and restart it during these issues just in case there was something with the system). |
It was just intended as another example of where networking with a container broke.
Can you try without Portainer? I don't know if that influences the behaviour? Either way, you were not able to reproduce the problem in a fresh container instance as per above, so whatever is gone awry it's likely unrelated to DMS itself? I don't know how we could troubleshoot it further with you unless you can identify something we can actually act on? |
It shouldn't at all. It's just a nicer way to use
I'll try to spin up a new container. I'll make a backup and try whether something in the volumes is messing this up by running it with the devault |
In your containers, can you please run $ rspamadm configdump options | grep -A 10 -F 'dns {' to verify which DNS servers Rspamd is using. I also need $ cat /etc/apt/sources.list.d/rspamd.list and the contents of what is in the
TBH that would indicate network problems in your production container. Using SA + OpenDKIM works now because SA is simply not performing the reverse-DNS-mismatch check this way (it does, but it does not add as much weight IIRC). Still, this is not necessarily a Rspamd problem. |
I found out what broke the docker-mailserver/compose.yaml Line 6 in 03c905e
When I commented it out and used the docker-mailserver/mailserver.env Line 14 in 03c905e
in the |
Looks like it's better but it's greylisted
|
The emails started coming as they should! Only they ended up in SPAM folder, maybe because I've tried logging in multiple times to test different configs/circumstances. So emails that are 90% similar with the same subject from the same email 3 times was maybe enough for it to get there. It doesn't matter though! I got the emails and just moved them to INBOX so rspamd should learn, since it's turned on! I'll leave this open until it's figured out what to do with the failing hostname option: docker-mailserver/compose.yaml Line 6 in 03c905e
|
That's not the first message that belongs to this e-mail (denoted by the "too early"). Can you search for the first and show me? What happens if you set both, |
The too early message was because I created a new login that sent a new email not because the mailserver resent it before the greylist period expired. The greylist since expired and I receive the emails now. It's in spam with a score of 6.11 though. I'll see why that is and whether there's something to do about that. Maybe it's just because there were so many of what is basically the same email.
They are not equivalent since the docker option modifies the network/DNS server of the container while I can try it once I have some free time. |
Hi, Here's the report:
The email was resent and recieved in spam after the greylist expired. |
E-Mails from asciinema seem to be wild:
Hence, I would have been more worried if this did not end up in spam, TBH. If it's not too much trouble, can you post an anonymized version of such an e-mail here? I'd be curious to see one. |
Of course. It's a simple email with a login link. You can also easily get one yourself by logging in/registering here: https://asciinema.org/login/new. There's no password or anything so it's not that annoying to make an account and test this out yourself. The email (without the login token):
SourceHopefully I didn't leave anything sensitive in.
|
I just tried what would rspamd do with my own asciinema instance and it's basically the same (apart from me having a DMARC policy). So it looks like the client sending the emails may be misconfigured? Also I get |
If you think it's appropriate I'll create an issue in the server's repo and report the DMARC error to the default instance admin. |
Thank you for the sources; it looks indeed weird. Nothing too much out of the ordinary, but enough to make Rspamd classify this as spam.
Yes.
Indeed, this is because
That's a formidable idea! If you can, also mention the missing |
So it is local only? Now that I think of it though my DNS is one domain (the intended one) and the rDNS is a subdomain of my isp with the internal ip in it. How can I check whether that issue exists outside local emails?
I already prepared the issue and I linked to your comment where you explained the issues which I think you did pretty well. The issue is on my laptop though so I'll post it later (on my phone RN). |
When you are testing locally, having a dedicated DNS server is very handy. This way, you can have proper (r)DNS entries even for local domains, and you will not encounter the effects you just witnessed anymore. coreDNS is a good DNS server for containers (I use it my K8s cluster); and I also have a dedicated recursive resolver (for Rspamd and the like) (see
Awesome! |
asciinema
e-mails
Sounds cool for testing but that would not solve that my public domain has a rDNS something like |
Depending on who you ask, this is either not serious at all, or a deal-breaker. If you ask me, I think it's awful, and there is likely noting you can do when relying on an ISP. The ISP will not set a proper rDNS for you (kind of understandable). I want to give a brief explanation of my point of view. In my smtpd_sender_restrictions_default =
permit_mynetworks
permit_sasl_authenticated
reject_unknown_reverse_client_hostname
reject_unknown_sender_domain
permit Either you are in Others may use
"This is a stronger restriction than the Now, That being said, there is more to it. For example, whether the assumption that illegitimate e-mails have not PTR record still holds up in 2024. Depending on the link you click on, you get different answers. Because asciinema/asciinema-server#445 is resolved upstream, I will also close this issue. If you'd like to go on with the discussion, feel free to use our discussions :) |
Thanks for all your suggestions, help and explanations. Honestly I didn't realize this was still open. |
I'd just like to thank you all. Thanks to your help the Also I think that the underlying issue (DNS being messed up when using Again, thanks for your help, you're awesome. |
📝 Preliminary Checks
👀 What Happened?
I wanted to log into asciinema but didn't get the login email. When I used another one it worked fine.
When looking into logs I see that the message was outrights rejected instead of being moved to the spam folder:
Logs
👟 Reproduction Steps
🐋 DMS Version
v13.3.1
💻 Operating System and Architecture
Debian GNU/Linux 11 (bullseye) aarch64
⚙️ Container configuration files
📜 Relevant log output
Improvements to this form?
No response
The text was updated successfully, but these errors were encountered: