Chris Turan a écrit :
> Thank you to everyone. I'm getting some great suggestions. I didn't
> know about several of the features postfix provides and have been
> relying mostly on spamassassin to do the work for me.
>
>> I don't see the smtpd_*_restrictions. Sensible ones there cut down on
>> acres of spam and take load off the content scanner, without much in
>> the way of false positives (in fact, I have none).
>
> Well, my smtpd_*_restrictions aren't really used on my exterior mx
> routers. My users do not talk to those servers ever. Mine are
> exceedingly simple.
>
> For the ports the mx gateways connect to:
> smtpd_recipient_restrictions = permit_mynetworks, reject
>
> For ports the users connect to:
> smtpd_recipient_restrictions = permit_sasl_authenticated, reject
>
>
>> I suggest (after permit_mynetworks, for each set):
>> reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname,
>> reject_non_fqdn_hostname, reject_unknown_reverse_client_hostname,
>> reject_unknown_client_hostname, reject_non_fqdn_sender,
>> reject_unknown_sender_domain, reject_unauth_destination,
>> reject_non_fqdn_recipient, reject_rbl_client zen.spamhaus.org,
>> reject_unauth_pipelining
>
> I do have a concern for some of these. I pretty much have to support
> tons of mail clients from roaming users around the states. I have the
> whole run of microsoft mail clients, plus apple, and a significant linux
> user base as well. In addition, I have no control over the networks
> they're coming from, trust me their dns is severely messed up over
> there. I'll have to be relatively conservative in which ones I use here.
>
> I definitely can't use reject_unknown_reverse_client_hostname and
> reject_unknown_client_hostname. reject_unauth_destination is
> superfluous for my servers since there is a clean divide on the ports
> that users and regular incoming mail uses. reject_unknown_sender_domain
> also looks like a no-go since some users have non-resolvable internal
> domains. They do stuff like my-company-name.local instead of
> my-company-name.com.
>
> Here's a list of the ones that look ok for my setup.
> reject_invalid_helo_hostname
> reject_non_fqdn_helo_hostname,
> reject_non_fqdn_hostname
reject_non_fqdn_helo_hostname is the new name for reject_non_fqdn_hostname
> reject_non_fqdn_sender,
> reject_non_fqdn_recipient
> reject_unauth_pipelining
>
> I can't use the PBL, so I'll probably have to use this instead.
> reject_rbl_client sbl-xbl.spamhaus.org
>
when you use
smtpd_recipient_restrictions =
reject_non_fqdn_sender
reject_non_fqdn_recipient
permit_mynetworks
permit_sasl_authenticated
reject_unauth_destination
reject_invalid_helo_hostname
reject_non_fqdn_helo_hostname
reject_unknown_sender_domain
reject_rbl_client zen.spamhaus.org
on your MX, the last reject checks (starting from
reject_unauth_destination) are not applied to authenticated transactions
nor to clients listed in mynetworks (that's the goal of the permit_*
checks). Order does matter;-p
>
> Has anyone seen any weird issues when using the ones I've listed above.
> I'd rather pass the mail than risk a false positive.
>
if you are afraid, add warn_if_reject before each check. for example
warn_if_reject reject_invalid_helo_hostname
warn_if_reject reject_non_fqdn_helo_hostname
you can also get more logs using:
smtpd_client_restrictions =
check_reverse_client_hostname_access pcre:/etc/postfix/log_transaction
...
== log_transaction:
/./ WARN Transaction logged: PTR=$1
This way, you will have the PTR and the HELO of each transaction, even
if the transaction is just a probe.
> Any non-compliant microsoft products? :-)
some MTAs used to send a non fqdn helo. I'm not sure if there are still
many. (If there are still, I'd be interested to hear about it).
>
> Thanks for all the help again!
>
