Marcio Luciano Donada:
> Hi list
> Yesterday I updated to postfix version postfix-2.10.0, and am
> having trouble allowing the relay without authentication that was
> working perfectly before the update. The rules are as follows:
As described in the RELEASE_NOTES file. We aim to document so that
people don't have to ask the same question every time.
Wietse
Major changes - relay safety
----------------------------
[Incompat 20121007] As part of a forward compatibility safety net,
the Postfix installation procedure adds the following
smtpd_relay_restrictions entry to main.cf when there is none:
smtpd_relay_restrictions =
permit_mynetworks
permit_sasl_authenticated
defer_unauth_destination
If your site has a complex mail relay policy configured under
smtpd_recipient_restrictions, this safety net will defer mail that
the built-in smtpd_relay_restrictions setting would bounce.
To eliminate this safety net, take one of the following three
actions:
- Set smtpd_relay_restrictions empty, and keep using the existing
mail relay authorization policy in smtpd_recipient_restrictions.
- Copy the existing mail relay authorization policy from
smtpd_recipient_restrictions to smtpd_relay_restrictions.
- Set smtpd_relay_restrictions by hand to the new built-in
policy: permit_mynetworks reject_unauth_destination.
There is no need to change the value of smtpd_recipient_restrictions.
[Feature 20121007] This version introduces the smtpd_relay_restrictions
feature for mail relay control. The new built-in default settings
are:
smtpd_relay_restrictions =
permit_mynetworks
reject_unauth_destination
smtpd_recipient_restrictions =
( optional spam blocking rules would go here )
For comparison, this is the Postfix before 2.10 default:
smtpd_recipient_restrictions =
permit_mynetworks
reject_unauth_destination
( optional spam blocking rules would go here )
With Postfix versions before 2.10, the mail relay policy and spam
blocking policy were combined under smtpd_recipient_restrictions,
resulting in error-prone configuration.
As of Postfix 2.10, the mail relay policy is preferably implemented
with smtpd_relay_restrictions, so that a permissive spam blocking
policy under smtpd_recipient_restrictions will not unexpectedly
result in a permissive mail relay policy.
As usual, this new feature is introduced with safety nets to prevent
surprises when a site upgrades from an earlier Postfix release.
1 - FORWARD COMPATIBILITY SAFETY NET: the Postfix installation
procedure adds the following smtpd_relay_restrictions entry to
main.cf when there is none:
smtpd_relay_restrictions =
permit_mynetworks
permit_sasl_authenticated
defer_unauth_destination
If your site has a complex mail relay policy configured under
smtpd_recipient_restrictions, this safety net will defer mail
that the built-in smtpd_relay_restrictions setting would bounce.
To eliminate this safety net, take one of the following three
actions:
- Set smtpd_relay_restrictions empty, and keep using the existing
mail relay authorization policy in smtpd_recipient_restrictions.
- Copy the existing mail relay authorization policy from
smtpd_recipient_restrictions to smtpd_relay_restrictions.
- Set smtpd_relay_restrictions by hand to the new built-in
policy: permit_mynetworks reject_unauth_destination.
There is no need to change the value of smtpd_recipient_restrictions.
2 - BACKWARDS COMPATIBILITY SAFETY NET: sites that migrate from
Postfix versions before 2.10 can set smtpd_relay_restrictions
to the empty value, and use smtpd_recipient_restrictions exactly
as they used it before.
-
Wietse
> In main.cf
> smtpd_recipient_restrictions = check_client_access
> hash:/usr/local/etc/postfix/maps/sender_access
>
> in sender_access:
> 189.x.x.1 OK
>
> In maillog
> warning: 189-x-x-1.abc.com.br[189.x.x.1]: SASL LOGIN authentication failed:
> authentication failure
>
> My question is, something has changed in this new version for authentication.
> I'm using FreeBSD 9.1-STABLE.
>
> __
> M?rcio Luciano Donada
> ?
>
>
>
>
>
