Todd A. Jacobs a écrit :
> On Mon, Jan 26, 2009 at 10:15:44PM +0100, mouss wrote:
>
>> This is useless. at this stage, the domain is yours (other domains have
>> been rejected by the anti-relay control: reject_unauth_destination).
>
> Nevertheless, if I don't put permit_mynetworks in both
> smtpd_client_restrictions and smtpd_recipient_restrictions, email sent
> to a mailman list address on the local server will be rejected because
> it's considered an unauthorized relay when:
>
> Jan 27 14:21:39 penguin postfix/smtpd[32089]: NOQUEUE: reject: RCPT from
> localhost.localdomain[127.0.0.1]: 554 5.7.1 <[email protected]>: Relay
> access denied; from=<[email protected]>
> to=<[email protected]> proto=ESMTP helo=<penguin.example.org>
>
> So, if I don't permit_mynetworks explicitly, mail sent to the mailman list
> address is received, but can't be sent on to the list participants. I get
> "relay access denied" when mailman attempts to resend the mail.
>
I insist;-p removing the _trailing_ permit_mynetworks from
smtpd_client_restrictions will change nothing. so you must have another
problem.
but it is recommended to put permit_mynetworks at the beginning.
smtpd_client_restrictions =
permit_mynetworks
reject_rbl_client zen.spamhaus.org
check_client_access hash:/etc/postfix/domain_access
>> consider putting all your checks under smtpd_recipient_restrictions.
>
> Or not. From http://www.postfix.org/SMTPD_ACCESS_README.html:
>
> Some people recommend placing ALL the access restrictions in the
> smtpd_recipient_restrictions list. Unfortunately, this can result in
> too permissive access.
>
This doesn't mean it is bad. this only means that care is needed. In
your setup, you query zen.spamhaus.org even in the case of a relay
attempt, invalid helo, ... this is not "optimal" (it unecessarily loads
your network and the dnsbl servers).
if you want to split your restrictoins, you need to duplicate your
whitelists (permit_mynetworks in your case): you need to put them before
other checks.
Here is a possible rewrite of your restrictions. as I don't know what's
in domain_access, I didn't move it to smtpd_recipient_restrictions.
smtpd_client_restrictions =
permit_mynetworks
check_client_access hash:/etc/postfix/domain_access
smtpd_helo_restrictions =
smtpd_sender_restrictions =
smtpd_recipient_restrictions =
permit_mynetworks
reject_unauth_destination
reject_invalid_helo_hostname
reject_non_fqdn_helo_hostname
reject_unknown_helo_hostname
check_recipient_access hash:/etc/postfix/recipient_access
check_sender_access hash:/etc/postfix/sender_access
reject_unknown_sender_domain
check_sender_mx_access hash:/etc/postfix/sender_mx_access
reject_rbl_client zen.spamhaus.org
check_policy_service inet:127.0.0.1:60000
smtpd_data_restrictions = reject_unauth_pipelining
PS reject_unknown_helo_hostname is generally "unsafe". you may need to
watch your logs.
> I posted the relevant sections of my configuration, but I'll put the
> output of postconf here to avoid argument:
>
yes, 'postconf -n' is the preferred method for reporting main.cf config
(main.cf may contain duplicate definitions, or you may have a typo, ...
etc).
> $ sudo postconf -n
> [snip]
> smtpd_client_restrictions = reject_rbl_client zen.spamhaus.org
> check_client_access hash:/etc/postfix/domain_access permit_mynetworks
> smtpd_data_restrictions = reject_unauth_pipelining
> smtpd_delay_reject = yes
> smtpd_error_sleep_time = 5
> smtpd_helo_required = yes
> smtpd_helo_restrictions = reject_invalid_helo_hostname
> reject_non_fqdn_helo_hostname reject_unknown_helo_hostname
> smtpd_recipient_restrictions = permit_mynetworks
> reject_unauth_destination reject_unknown_recipient_domain
> check_recipient_mx_access hash:/etc/postfix/recipient_mx_access
> check_recipient_access hash:/etc/postfix/recipient_access
> check_policy_service inet:127.0.0.1:60000
> smtpd_sender_restrictions = check_sender_mx_access
> hash:/etc/postfix/sender_mx_access check_sender_access
> hash:/etc/postfix/sender_access reject_unknown_sender_domain
> smtpd_soft_error_limit = 2
>
> My educated guess is that it has something to do with
> reject_unauth_destination in the smtpd_recipient_restrictions, but I'm
> not sure how that is being evaluated in this particular context.
>
the rejection log is indeed caused by reject_unauth_destination. but in
your smtpd_restrictions, this check comes after permit_mynetworks. here
are some possibilities to check:
- you have a reject_unauth_destination in domain_access
- you override mynetworks or smtpd_*_restrictions in master.cf
- mailman is using another smtpd, which has its own configuration.
master.cf should tell.
- the postfix you can configure is not the running one. you can check
this one by adding a check that return a WARN.
PS. if you use a content_filter, you don't want to re-filter list mail.
so you can configure mailman to use the smtpd that is after the filter
(for example, by setting SMTPPORT = 10025 in mm_cfg_py). you can do this
even if you don't have a content_filter, so that you can set specific
smtpd restrictions for mailman mail.
