-
Notifications
You must be signed in to change notification settings - Fork 234
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
Check the From header for inbound mail #654
Comments
This is exactly one of the checks enforced by DMARC. If sender domain (as specified in From) opts into DMARC, maddy would check if the From domain matches either DKIM signature domain (if one exists) or domain in EHLO. DMARC checking is enabled by default. While it is definitely possible to implement the check like one you described, I would prefer to not enable it by default to avoid compatibility problems - there are legitimate cases when EHLO will not match From (for example, #603). PRs are welcome. ;) |
I disagree I think this would break tons of staff. Everything with a bounce handler at the very least, this includes mailing lists, notifications of all kind, and everything that is basically a (legitimate) newsletter or subscription. |
Use case
I have received spam email whose domain of MAIL FROM is valid and the EHLO host is also allowed by the SPF.
However, the From header in the body is not match the MAIL FROM command.
This is a clear clue of spam. We need to check this situation. I have read the doc of check.authorize_sender,
it can be only used for checking the From header for outbound mail.
Your idea for a solution
One solution is to add an additional new check for the FROM header, and implement the check logic in the bodyCheck callback.
However, this solution need to add certain configure in the configure file.
I suggest to write a fix check function in the mgspipeline or check_runner and make this as default check so that there is no need to add new configuration.
The text was updated successfully, but these errors were encountered: