SMTPD_*_RESTRICTIONS

[rbtux]

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...

[BeNe]

Quote:I hope that increases the understanding of postfix smtpd_*_restrictions a bit...

Yes it does!
Thanks for this.

Greez BeNe

[joximu]

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" :-)

[Breaki]

thx @ rbtux, helped a lot!

[rbtux]

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)