wildduck
wildduck copied to clipboard
Potential Backscatter issue/SPF lookup
I'm not sure if this needs to be here, or in wildduck-haraka (or even Haraka itself!). Sorry. I may have even just missed the correct config file.
For info: I am using Wildduck-dockerized (but via podman) if that flags anything up.
First of all - great job on Wildduck, it's fantastic and I like it a lot!
However, I've noticed I am able to send FROM myself, TO myself (and any other internal email address) using an unauthenticated SMTP connection. This only affects internal email accounts, i.e. I cannot send FROM myself TO any external address using the same method.
For Example:
> telnet my.mail.server 25
220 my.mail.server ESMTP WildDuck MX
> helo my.mail.server
250 my.mail.server Hello my.location.rDNS [my.ip.addr.ess]Haraka is at your service.
> mail from: [email protected]
250 sender <[email protected]> OK
> rcpt to: [email protected]
250 recipient <[email protected]> OK
> data
354 go ahead, make my day
> subject: test email
> body content of email
> some more text
> etc.
> and so on
> etc.
> ending with a single dot
> .
250 Message processed (me-ss-age-id)
And the message arrives - no problem at all. I've also tested on another Wildduck server I have access to (but don't manage) and the same is true there. It seems to me, Haraka/Wildduck is not performing SPF lookups on incoming emails correctly, as ultimately, legitimate emails sent FROM a wildduck email address, should not be handled via haraka anyway and handled internally via zonemta and wildduck itself - I could be mistaken though.
Also, I've just noticed I can perform exactly the same process FROM any email address I desire as long as the internal address exists - which is something SPF is supposed to prevent.
So, I'm thinking I'm missing something. I believe Haraka and Wildduck are both very decent mail handling services so I must have missed some configuration somewhere. Can anyone help?
P.S. I'm experienced in configuring DNS, and the records are set up correctly. I also manage many other non-wildduck mail servers which do not experience this problem
Hi!
Both haraka and rspamd have options for checking spf: https://haraka.github.io/plugins/spf/ https://rspamd.com/doc/modules/spf.html
Some quotes from those docs:
The rest of the optional settings (disabled by default) permit deferring or denying mail from senders whose SPF fails the checks.
Moreover, many mail providers have no clear understanding of this technology and misuse the SPF technique. Hence, the scores for SPF symbols are relatively small in Rspamd.
So, no action is taken against an spf policy by default.
Rspamd does have DMARC checking enabled by default: https://rspamd.com/doc/modules/dmarc.html
If you were to add a dmarc policy of reject to emailaddress.com, that should make rspamd reject the emails. Do note that when enabling a DMARC reject policy you need to make sure that the enevelope from and the actual from header domains align, but this is the case by default with wildduck.
Sorry, pressed enter before being finished ;)
You could also configure either haraka or rspamd to rejecty solely based on SPF, but you'll find there's a good reason that that's not the default.
as ultimately, legitimate emails sent FROM a wildduck email address, should not be handled via haraka anyway and handled internally via zonemta and wildduck itself
Since the inbound and outbound servers are completely different applications that's not really practical. You do see this in systems where the inbound smtp server is the same as the outbound server, but it's not a necessity.
Also, I've just noticed I can perform exactly the same process FROM any email address I desire as long as the internal address exists - which is something SPF is supposed to prevent.
Not really. SPF doesn't specifically tell anyone to reject emails. It's something that you as the recipient can decide. DMARC does.
Thanks for your response @louis-lau I'll take a read of the docs tomorrow and digest it all. I think maybe I didn't explain myself regarding the separate inbound and outbound servers - I'm quite used to them being separate, and like it that way. In no way do I think it needs to change, sorry if it came across like that :-)
At the moment I have the emails tranported via my own mail filter which I have configured to handle SPF the way I choose, but would like to separate wildduck away from this at some point so thanks for all the information you have sent!
You're very right about DMARC too - I probably need to stop being lazy and actually configure that.... ;)
In no way do I think it needs to change, sorry if it came across like that
It didn't haha, no worries.
thanks for all the information you have sent
Glad it's useful!
stop being lazy
I know that feeling...
Just in case anyone comes across this as a similar "issue" in the future - as I expected, Wildduck is working perfectly fine and was checking things appropriately.
The issue, for me, was that as I was using Wildduck-dockerised in a rootless podman container, via HAProxy (and then subsequently Traefik to test an alternative) - the proxied connecting/client IP address was being understood as either 127.0.0.1 or 10.0.2.100, dependent on if I'm sending the PROXY command (send-proxy in HAProxy, proxyProtocol: version: 1 for Traefik) or not. Both those IP addresses are effectively localhost for rootless containers in my set up.
So, for me, I fixed it by configuring the Traefik container to use host networking mode (--net host) and to send the PROXY command. I also needed to create a haproxy_hosts file within the haraka config directory and enter the 10.0.2.100 into it (rootless podman network IP)
The connecting client IP is now being understood as the correct public IP, and if I try to send again using a spoof email address, rspamd checks the email and gives me a 451 4.7.1 Try again later error - which is exactly what I want to see.
So, ultimately it's down to me using rootless Podman rather than Docker and shooting myself in the foot a little bit, but sorted now and quite happy!