Docker Mailserver
Replies: 2 comments
-
This isn't my area of expertise, but we do want to switch over to rspamd as the default in a future release, so if you'd be willing to give that a go and provide feedback if it improves the issue that'd be good. It'd also good to know how our rspamd docs are doing, I haven't heard any complaints so far, but we're always interested in providing a better experience for users. We want these in good shape too once we do the switch to rspamd. From what I know, rspamd is meant to be much better at handling these tasks, and from feedback since we introduced rspamd support we've been tailoring it to work well. v14 should be in pretty good condition by now AFAIK. I'm not sure if Amavis + SA works on mail being forwarded to another MTA via a virtual alias, or how that likewise affects how much processing rspamd performs vs local delivery. @georglauterbach might have input on that for rspamd, @casperklein prefers SpamAssassin I think and might have input there, although I'm not sure if either have virtual aliases to forward mail in their deployments. The main issue though is that you have One issue with forwarding mail AFAIK is that your DMS container is sending the mail with a sender address that you do not actually own. Anyone that configures DNS properly for their mail domains such as SPF are going to forbid you from sending mail with that sender address. The SPF failure from gmail alone does not necessary mean spam in that case. While I think some MTAs may overlook SPF checks if other security checks pass like DKIM/DMARC? (again this is not my area as I don't actually deploy and use DMS personally) I state this, just to clarify that we're certain that the mail is spam in it's actual contents, not because some other mail that was legitimate was successfully sent out (but may have otherwise failed an SPF check against DMS too?) Normally for DMS to send mail outbound for a sender address it does not manage, it needs to be granted the authority to do so, an SPF record in that domain owners DNS allows for that. Gmail then checks the sender domain DNS for the SPF record, and notices that your DMS FQDN/IP are not authorized to send mail and rejects it. AFAIK we have PostSRSd as a way to workaround this, which rewrites the sender address to your own or something like that (it was community contributed a while back, I don't know how well it works). I would focus on ensuring DMS is correctly preventing spam, and if it is then understand the issue is likely as I've described above since you are forwarding to a third-party MTA you have an account with, but that MTA is not configured to blindly trust anything received from DMS that is sent to your account with them. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for your extensive answer @polarathene! I'm now using PostSRSd and rspamd to check spam before forwarding and it's filtering out the most obvious stuff which works fine. |
Beta Was this translation helpful? Give feedback.
-
I sometimes see e-mails that DMS tried to forward to a gmail.com user (which is setup on DMS) where the original e-mail is clearly spam and Google states it fails SPF. Is there a way to prevent such clear spam e-mails being forwarded at all? Should I run Rspamd to achieve this or could this be done another way?
aaa.bbb.ccc.ddd is the spamme'rs IP; xxx.xxx.xxx.xxx is DMS' IP).
This use case looks a bit like described here: https://github.com/orgs/docker-mailserver/discussions/3687 but this doesn't seem to go in to SPF fails as above.
Beta Was this translation helpful? Give feedback.
All reactions