+- ispCP - Board - Support (http://www.isp-control.net/forum)
+-- Forum: ispCP Omega Development Area (/forum-1.html)
+--- Forum: General discussion (/forum-11.html)
+--- Thread: SMTPD_*_RESTRICTIONS (/thread-1756.html)
SMTPD_*_RESTRICTIONS - rbtux - 11-10-2007 10:05 PM
Hi there
there seems to be a bigger problem with the understanding of smtpd_x_restrictions. I thought I'll explain them here a bit further:
smtpd_client_restrictions:
With these restrictions it's possible to permit/reject connections based on information available after connect from client. You can filter:
- hostnames
- ip-adresses
smtpd_helo_restrictions:
With these restrictions it's possible to permit/reject connections based on information available after the client sent HELO/EHLO. You can filter:
- hostnames
- ip-adresses
- Helo
smtpd_sender_restrictions
With these restrictions it's possible to permit/reject connections based on information available after the client sent Mail from:. You can filter:
- hostnames
- ip-adresses
- Helo
- Sender E-Mail address
smtpd_recipient_restrictions:
With these restrictions it's possible to permit/reject connections based on information available after the client sent rcpt from:. You can filter:
- hostnames
- ip-adresses
- Helo
- Sender E-Mail address
- recipient address
smtpd_data_restrictions:
With these restrictions it's possible to permit/reject connections based on information available after the client sent data:. You can filter:
- hostnames
- ip-adresses
- Helo
- Sender E-Mail address
- recipient address
- pipelining
When we now want to save our postfix against the bad guys we could do this configuration:
Quote:smtpd_helo_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_invalid_hostname
smtpd_sender_restrictions =
reject_non_fqdn_sender,
reject_unknown_sender_domain,
permit_mynetworks,
permit_sasl_authenticated
smtpd_recipient_restrictions =
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
check_policy_service...
smtpd_data_restrictions =
reject_multi_recipient_bounce,
reject_unauth_pipelining
The above configuration is identical (in result) with the following shorter one:
Quote:smtpd_recipient_restrictions =
reject_non_fqdn_sender,
reject_unknown_sender_domain,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
permit_mynetworks,
permit_sasl_authenticated,
reject_invalid_hostname,
reject_unauth_destination,
check_policy_service...
smtpd_data_restrictions =
reject_multi_recipient_bounce,
reject_unauth_pipelining
The advantage is: You have the specify permits only in one section. Thats important when you begin using own black/whitellist (check_*_access). That makes it a lot easier to debug a problem within your configuration.
The (very small) disadvantage is: There is some more traffic (1 - 2 kb) for each mail you block. When you got a mailservice which is delivering more than 100000 mails a day you may want to use the first configuration.
I hope that increases the understanding of postfix smtpd_*_restrictions a bit...
RE: SMTPD_*_RESTRICTIONS - BeNe - 11-10-2007 10:25 PM
Quote:I hope that increases the understanding of postfix smtpd_*_restrictions a bit...
Yes it does!
Thanks for this.
Greez BeNe
RE: SMTPD_*_RESTRICTIONS - joximu - 11-10-2007 10:29 PM
Thanx rbtux
I want to add: it's not only the little bit more traffic with the shorter solution - it's also a question of server ressource (cpu, number of connections etc - which can be kept opne by "bad guys") - so I'd say: in a non-private hosting envireonment it's better top take the more complex but also more efficient version...
my 2 cents... (although we have "Rappen" :-)
RE: SMTPD_*_RESTRICTIONS - Breaki - 11-10-2007 10:34 PM
thx @ rbtux, helped a lot!
RE: SMTPD_*_RESTRICTIONS - rbtux - 11-10-2007 11:10 PM
joximu Wrote:it's also a question of server ressource (cpu, number of connections etc - which can be kept opne by "bad guys")
well it does not matter for small sites! (you can increase the max connections if you like). And especially for people who don't know what they are doing with the main.cf (and theres a lot of them) should consider using the second configuration.
But of course if you know about the consequences and know how to avoid breaking the config you can use the first example... (I personally don't)