> Do you think this postfix anti-spam configuration is OK:
>
> smtpd_delay_reject = yes
> smtpd_helo_required = yes
> smtpd_helo_restrictions =
> permit_mynetworks,
> reject_non_fqdn_hostname,
> reject_invalid_hostname,
> permit
I'd be careful with non_fqdn_hostname
What's wrong with that? Here's how the postfix docs describe it:
reject_non_fqdn_helo_hostname (with Postfix < 2.3: reject_non_fqdn_hostname)
Reject the request when the HELO or EHLO hostname is not in
fully-qualified domain form, as required by the RFC.
> smtpd_sender_restrictions =
> permit_mynetworks,
> reject_non_fqdn_sender,
> reject_unknown_sender_domain,
> permit
> smtpd_recipient_restrictions =
> permit_mynetworks,
> reject_non_fqdn_recipient,
> reject_unknown_recipient_domain,
> reject_unauth_destination,
> permit
That's pretty much what I run and you might want to look at
smtpd_data_restrictions as well.
What do you use with smtpd_data_restrictions? I was considering
reject_unauth_pipelining but the docs have me confused with the "Note"
below:
reject_unauth_pipelining
Reject the request when the client sends SMTP commands ahead of time
where it is not allowed, or when the client sends SMTP commands ahead
of time without knowing that Postfix actually supports ESMTP command
pipelining. This stops mail from bulk mail software that improperly
uses ESMTP command pipelining in order to speed up deliveries.
Note: reject_unauth_pipelining is not useful outside
smtpd_data_restrictions when 1) the client uses ESMTP (EHLO instead of
HELO) and 2) with "smtpd_delay_reject = yes" (the default). The use of
reject_unauth_pipelining in the other restriction contexts is
therefore not recommended.
> Would it be OK to remove the following aliases since I never use them:
It's good form to keep them on your server and compile with the relvent
RFC which specifies these.
Those aliases must be bringing in some spam though.
- Grant
--
gentoo-user@gentoo.org mailing list
