Mailcow-dockerized: SMTP Restrictions vs Rspamd Symbols

[PhoenixPeca]

Hi @andryyy ,

Forgive me if I'm asking a dumb question here..

I would just like to ask, why do we need these restrictions:
reject_invalid_helo_hostname, reject_unknown_reverse_client_hostname, reject_unauth_destination
in the smtpd_recipient_restrictions directive in postfix config? Please correct me if I’m wrong, but doesn’t rspamd have a symbol for this already? Why don’t we just use these symbols and remove those postfix restrictions instead? If we have those restrictions in postfix, then it would make those symbols pointless.. Furthermore, it limits the ability of the mailcow admin to customize which emails gets rejected or not.

_Note: Rspamd symbols in the images provided might be inaccurate for the purpose that I have described here. But I hope I give the general idea that we can use rspamd to reject those messages and not postfix._

Thanks!

Regards,
Phoenix Aspacio

[andryyy]

Hi,

Unauthed should not be removed. Reverse DNS checks and HELO checks could indeed be done by Rspamd only.

Postfix can do these checks much faster and without full DATA stream.

We should increase the scores of these symbols then

Am 02.08.2019 um 14:49 schrieb Phoenix Eve Aspacio [e-mail]:

Hi @andryyy ,

I would just like to ask, why do we need these restrictions:

reject_invalid_helo_hostname, reject_unknown_reverse_client_hostname, reject_unauth_destination
in the smtpd_recipient_restrictions directive in postfix config? Please correct me if I’m wrong, but doesn’t rspamd have a symbol for this already? Why don’t we just use it in mailcow-dockerized instead? If we have those restrictions in postfix, then it would make that symbol pointless.

Note: Rspamd symbols in the images provided might be inaccurate for the purpose that I have described here. But I hope I give the general idea that we can use rspamd to reject those messages and not postfix.

Thanks!

Regards,
Phoenix Aspacio

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[PhoenixPeca]

Thank you @andryyy !!

[mkuron]

Actually these checks should stay in Postfix. As @andryyy said, Postfix is faster and can reject the message before receiving the body. This is similar to how it makes sense to do the DNSBL checks in Postfix already -- Rspamd is never invoked, the message body is never received and computational load is significantly reduced. Also, the sender will get a more precise error message from Postfix (saying exactly which one of the restrictions or DNSBLs led to the rejection) than from Rspamd (which will just say that it's spam), making it easier for them to fix the problem on their end. There is no reason to accept messages that fail the restrictions -- after all, these messages are in violation of the SMTP RFC standard.

[PhoenixPeca]

@mkuron OK, understood! Makes sense now.. Thanks!!

[andryyy]

Cebka is planning to implement a change in the milter plugin to catch that kind of stuff before DATA. We can omit Postfix for these checks then.

[mkuron]

Do you think we should also do the DNSBL checks in rspamd then? I don‘t know about your servers, but I catch like 95% of my spam with DNSBLs, so moving all that traffic to rspamd would considerably increase system load at no gain.

[andryyy]

Not sure, but we would gain a "real" whitelist via Rspamd. :)

------ Originalnachricht ------
Von: "Michael Kuron" [e-mail]
An: "mailcow/mailcow-dockerized" [e-mail]
Cc: "André Peters" [e-mail]; "Mention"
[e-mail]
Gesendet: 02.08.2019 22:43:08
Betreff: Re: [mailcow/mailcow-dockerized] SMTP Restrictions vs Rspamd
Symbols (#2829)

Do you think we should also do the DNSBL checks in rspamd then? I don‘t
know about your servers, but I catch like 95% of my spam with DNSBLs,
so moving all that traffic to rspamd would considerably increase system
load at no gain.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mailcow/mailcow-dockerized/issues/2829?email_source=notifications&email_token=AAWV2FVO5PNUQKL3UIJHF7LQCSL5ZA5CNFSM4II5OLOKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3OZMXY#issuecomment-517838431,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAWV2FX2VQTXJRMA7HSCL33QCSL5ZANCNFSM4II5OLOA.

[mkuron]

Sure, but we already have that with our postscreen forwarding hosts script. Ok, it‘s not pretty, but it‘s been working fine for years. I‘m just saying we shouldn’t make such a change without carefully evaluating the performance impact.

[PhoenixPeca]

I was really hoping to gain more control over the whitelist and blacklist rules in mailcow UI.. having those restrictions at postfix level means less control on those rules, but having those in rspamd level would mean higher load on servers.. this is more like a concern of performance vs user control.. Also, there are some people who prefer to provision a more performant server just to gain more control over things as andré mentioned..

... a "real" whitelist via Rspamd.

While there are others who prefer performance..

[PhoenixPeca]

Still subject for discussion... reopening for final resolution.

[pjv]

+1 for performance over convenience - please don't break my little 2GB, 1 vCPU mailcow server.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.