Eddie b wrote:
I do stand corrected, I played on our dev box once I returned to work and
have it working perfectly as I want it, but before i allow it to go live i
need to ensure a few things, you see I'm a 20 year sendmail veteran, and a
10 year qmail veteran, but only 10 day postfix newbie :P
I saw that Timo gave you a better way for dovecot.
After researching I think the following would suite our main.cf, would you
suggest any alterations (like whats in recpt should be in sender or
un-needed etc etc etc) to these
The only ones I'm unsure on are...
smtpd_sender_restrictions =
reject_unknown_sender_domain,permit_mynetworks,permi
t_sasl_authenticated,reject_non_fqdn_sender,permit
smtpd_recipient_restrictions =
reject_unknown_recipient_domain,permit_mynetworks
,permit_sasl_authenticated,reject_unauth_destination,reject_unauth_pipelining,re
ject_invalid_hostname,reject_non_fqdn_hostname,reject_non_fqdn_sender,reject_non
_fqdn_recipient,reject_unknown_sender_domain,reject_rbl_client
bl.spamcop.net,re
ject_rbl_client dnsbl.sorbs.net,reject_rbl_client zen.spamhaus.org,permit
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions =
permit_mynetworks,permit_sasl_authenticated,reject_inv
alid_helo_hostname,reject_non_fqdn_helo_hostname,reject_unknown_helo_hostname
I guess this is bloated but I'm trying to mirror, sendmails bad_helo,
bad_mx, PTR and FWD enforcment and so on.
- it is simpler to put all your restrictions under
smtpd_recipient_restrictions (remove smtpd_sender_restrictions and
smtpd_helo_restrictions). the result is the same, but you have a
sequential list (easier to read and maintain) and you don't need to
repeat the "permit_*" whitelisting checks.
- by default (smtpd_delay_reject=yes), reject_unauth_pipelining is
useless before data stage (checks are evaluated at RCPT TO stage, when
pipelining is ok).
your restrictions could be written as:
smtpd_recipient_restrictins =
reject_unknown_sender_domain
reject_unknown_recipient_domain
permit_mynetworks
permit_sasl_authenticated
reject_non_fqdn_sender
reject_non_fqdn_recipient
reject_unauth_destination
reject_invalid_helo_hostname
reject_non_fqdn_hostname
# no point to query dns if address does not exist
reject_unlisted_recipient
reject_unlisted_sender
# the following check will catch legitmate mail
reject_unknown_helo_hostname
reject_rbl_client zen.spamhaus.org
reject_rbl_client bl.spamcop.net
reject_rbl_client dnsbl.sorbs.net
smtpd_data_restrictions =
reject_unauth_pipelining
why do you use the reject_unknown_mumble_domain "soon"? do you want to
reject your own users mail if the sender or rcpt domain doesn't resolve?
This may be undesirable: if you have a dns failure, you force the user
to retry later, which is not very friendly.
I suggest moving reject_unknown_sender_domain down (after
reject_non_fqdn_hostname or even after rbl checks), and removing
reject_unknown_recipient_domain (because after
reject_unauth_destination, the recipient domain is yours, so there is no
point checking it in DNS).
I also suggesting removing reject_unknown_helo_hostname because it does
catch legitimate mail.
if you want to enforce FcrDNS (ip->ptr->ip match), then you want
reject_unknown_client. however, this will catch legitimate clients (even
well configured ones if there is a DNS problem, such as if they are
under a DoS attack).
