Restricting relay of attachments
Sorry if this is a bit simple, but I can't seem to figure out how the components fit together. Given the following: 1) MX/Relay machine running postfix: relay.domain1.com 2) Client machine: client.domain2.com I'd like to restrict/deny (5xx permanent error) incoming messages from the Internet to client.domain2.com if they contain attachments. But no such restriction should be applied to other clients or to users on relay.domain1.com. I presume this would be done with some type of header check plus some type of restriction class. If that's true, then I need some help with both. If I don't even have that right, I'll need a some more help. ;-) Thanks, Michael
Re: Restricting relay of attachments
On 9/10/2014 1:24 AM, Michael Fox wrote: Sorry if this is a bit simple, but I can’t seem to figure out how the components fit together. Given the following: 1) MX/Relay machine running postfix: relay.domain1.com 2) Client machine: client.domain2.com I’d like to restrict/deny (5xx permanent error) incoming messages from the Internet to client.domain2.com if they contain attachments. But no such restriction should be applied to other clients or to users on relay.domain1.com. I presume this would be done with some type of header check plus some type of restriction class. If that’s true, then I need some help with both. If I don’t even have that right, I’ll need a some more help. ;-) Header_checks and/or restriction classes are the wrong tool for this. You'll need some external milter/content_filter/smtpd_proxy_filter with per-destination controls. - header_checks examine one header at a time, so you can't combine destination + attachment tests. - restriction classes (and other smtpd restrictions) deal with envelope information and cannot determine if an attachment is present.
Re: Restricting relay of attachments
On 9/10/2014 1:24 AM, Michael Fox wrote: I'd like to restrict/deny (5xx permanent error) incoming messages from the Internet to client.domain2.com if they contain attachments. But no such restriction should be applied to other clients or to users on relay.domain1.com. Noel Jones: Header_checks and/or restriction classes are the wrong tool for this. You'll need some external milter/content_filter/smtpd_proxy_filter with per-destination controls. Correct. However, if you have separate mail streams for mail clients (TCP port submission/587 or smtps/465) and for MX service (TCP port 25), then you can apply different policies to each stream. /etc/postfix/main.cf: mua_cleanup_service = mua_cleanup mua_header_checks = ... mua_body_checks = ... /etc/postfix/master.cf: smtp inet n - n - - smtpd mua_cleanup unix n - n - 0 cleanup -o header_checks=mua_header_checks -o body_checks=mua_body_checks submission inet n - n - - smtpd -o cleanup_service=$mua_cleanup_service -o syslog_name=postfix/submission ...[see sample master.cf file for more]... smtps inet n - n - - smtpd -o cleanup_service=$mua_cleanup_service -o syslog_name=postfix/smtps -o smtpd_tls_wrappermode=yes ...[see sample master.cf file for more]... By keeping the mua_xxx parameter settings in main.cf, configuration is not as ugly as it would be with settings in master.cf. Wietse
RE: Restricting relay of attachments
Hmmm. O.K. Thanks to both of you. It will take me some time to think this through. The level of indirection between main.cf and master.cf sure adds flexibility. But, as someone who doesn't work in postfix every day or even every week, it also leaves my head spinning. ;-) Thanks again. Michael -Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix- us...@postfix.org] On Behalf Of Wietse Venema Sent: Wednesday, September 10, 2014 6:54 AM To: Postfix users Subject: Re: Restricting relay of attachments On 9/10/2014 1:24 AM, Michael Fox wrote: I'd like to restrict/deny (5xx permanent error) incoming messages from the Internet to client.domain2.com if they contain attachments. But no such restriction should be applied to other clients or to users on relay.domain1.com. Noel Jones: Header_checks and/or restriction classes are the wrong tool for this. You'll need some external milter/content_filter/smtpd_proxy_filter with per-destination controls. Correct. However, if you have separate mail streams for mail clients (TCP port submission/587 or smtps/465) and for MX service (TCP port 25), then you can apply different policies to each stream. /etc/postfix/main.cf: mua_cleanup_service = mua_cleanup mua_header_checks = ... mua_body_checks = ... /etc/postfix/master.cf: smtp inet n - n - - smtpd mua_cleanup unix n - n - 0 cleanup -o header_checks=mua_header_checks -o body_checks=mua_body_checks submission inet n - n - - smtpd -o cleanup_service=$mua_cleanup_service -o syslog_name=postfix/submission ...[see sample master.cf file for more]... smtps inet n - n - - smtpd -o cleanup_service=$mua_cleanup_service -o syslog_name=postfix/smtps -o smtpd_tls_wrappermode=yes ...[see sample master.cf file for more]... By keeping the mua_xxx parameter settings in main.cf, configuration is not as ugly as it would be with settings in master.cf. Wietse
Re: Restricting relay of attachments
On Wed, Sep 10, 2014 at 09:55:16AM -0700, Michael Fox wrote: Hmmm. O.K. Thanks to both of you. It will take me some time to think this through. The level of indirection between main.cf and master.cf sure adds flexibility. But, as someone who doesn't work in postfix every day or even every week, it also leaves my head spinning. ;-) The easiest way to understand this is that main.cf is just a lookup table that preempts built-in defaults and is loaded at the start of each Postfix daemon process. This lookup table is in turn preempted by -o command-line switches. However, both on the command-line and in main.cf itself, parameters can be recursively defined in terms of other parameters or just ad-hoc made up macros. Since the master.cf file is does not support white-space in argument values, and is not a good place for maintaining complex parameter settings, the best practice approach to master.cf overrides is to define them indirectly in terms of sensibly named macros that are actually defined in main.cf. main.cf: some_override = ... too complex to specify directly in master.cf ... master.cf service type ... daemon-program -o some_parameter=$some_override ... Even if the override value is very simple, it may be better to use indirection via main.cf, so that someone reading just main.cf can infer that there are likely master.cf overrides and it may be wise to look there also. -- Viktor.
RE: Restricting relay of attachments
That's helpful. Thanks. -Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix- us...@postfix.org] On Behalf Of Viktor Dukhovni Sent: Wednesday, September 10, 2014 10:11 AM To: postfix-users@postfix.org Subject: Re: Restricting relay of attachments On Wed, Sep 10, 2014 at 09:55:16AM -0700, Michael Fox wrote: Hmmm. O.K. Thanks to both of you. It will take me some time to think this through. The level of indirection between main.cf and master.cf sure adds flexibility. But, as someone who doesn't work in postfix every day or even every week, it also leaves my head spinning. ;-) The easiest way to understand this is that main.cf is just a lookup table that preempts built-in defaults and is loaded at the start of each Postfix daemon process. This lookup table is in turn preempted by -o command-line switches. However, both on the command-line and in main.cf itself, parameters can be recursively defined in terms of other parameters or just ad-hoc made up macros. Since the master.cf file is does not support white-space in argument values, and is not a good place for maintaining complex parameter settings, the best practice approach to master.cf overrides is to define them indirectly in terms of sensibly named macros that are actually defined in main.cf. main.cf: some_override = ... too complex to specify directly in master.cf ... master.cf service type ... daemon-program -o some_parameter=$some_override ... Even if the override value is very simple, it may be better to use indirection via main.cf, so that someone reading just main.cf can infer that there are likely master.cf overrides and it may be wise to look there also. -- Viktor.
