Bonjour,

Les journaux de Postfix ne cessent de m'avertir:

postfix/smtpd[8316]: warning: support for restriction
"reject_maps_rbl" will be removed from Postfix; use
"reject_rbl_client domain-name" instead
et
postfix/smtpd[8316]: warning: support for restriction
"check_relay_domains" will be removed from Postfix; use
"reject_unauth_destination" instead

En effet, mon /etc/postfix/main.cf se présente ainsi:

maps_rbl_domains = relays.ordb.org
sbl-xbl.spamhaus.org
header_checks = regexp:/etc/postfix/header_checks
body_checks = regexp:/etc/postfix/body_checks
smtpd_helo_required = yes
smtpd_sender_restrictions = regexp:/etc/postfix/forbid_from,
reject_unauth_pipelining, permit_mynetworks,
reject_unauth_destination, reject_non_fqdn_sender
smtpd_recipient_restrictions = permit_mynetworks, reject_maps_rbl,
check_relay_domains

Bref, il faudrait que je remplace reject_maps_rbl et
check_relay_domains dans les smtpd_recipient_restrictions.

Le problème est que je ne comprends pas bien la documentation¹
puisqu'elle ne mentionne pas les anciennes options: sont-elles
équivalentes et puis-je simplement remplacer les restrictions par
leur nouveau nom?

D'autre part, je ne suis pas vraiment sûr qu'utiliser
reject_unauth_pipelining et reject_unauth_destination pour les
smtpd_sender_restrictions soit pertinent. Qu'en pensez-vous?

Toute remarque bienvenue quant à ma configuration, du reste (inspirée
de <http://colino.net/computing/unix.php3>.

Merci.

----------------------------
1)<http://x.guimard.free.fr/postfix/index.php?page=postconf.5.html#smtpd_recipient_res trictions>

>>>>> "V" == Vincent Ramos <siva_sans_spam@kailaasa.net.invalid> writes:

V> Le problème est que je ne comprends pas bien la documentation¹
V> puisqu'elle ne mentionne pas les anciennes options: sont-elles
V> équivalentes et puis-je simplement remplacer les restrictions par
V> leur nouveau nom?

Pour comprendre le problème il faut savoir que MAPS a été l'une des
premières DNSBL a être "massivement" utilisé et que ce choix a changé
quand
* MAPS est devenu payant
* certains ont critiqué les choix fait par MAPS

Elle a été progressivement remplacée par d'autres, tel que
sbl-xbl.spamhaus.org, et en ce sens il ne semblait plus logique de
conserver le nom de MAPS dans la directive, d'où l'apparition d'un nouveau
nom reject_rbl_client qui correspond mieux à la réalité.

Elles correspondent, toutes les deux, à une même action : interroger une
DNSBL pour refuser un message.

V> D'autre part, je ne suis pas vraiment sûr qu'utiliser
V> reject_unauth_pipelining et reject_unauth_destination pour les
V> smtpd_sender_restrictions soit pertinent. Qu'en pensez-vous?

Par défaut postfix a

smtpd_delay_reject = yes

ce qui fait que cela n'a pas grand sens de mettre reject_unauth_pipelining
dans smtp_sender_restrictions puisque tous les test (helo, sender,
recipient) vont se faire après la phase RCPT TO.

reject_unauth_destination est plutôt pour smtpd_recipient_restrictions


--

Guy Decoux

>>>>> "V" == Vincent Ramos <siva_sans_spam@kailaasa.net.invalid> writes:

V> Le problème est que je ne comprends pas bien la documentation¹
V> puisqu'elle ne mentionne pas les anciennes options: sont-elles
V> équivalentes et puis-je simplement remplacer les restrictions par
V> leur nouveau nom?

Pour comprendre le problème il faut savoir que MAPS a été l'une des
premières DNSBL a être "massivement" utilisé et que ce choix a changé
quand
* MAPS est devenu payant
* certains ont critiqué les choix fait par MAPS

Elle a été progressivement remplacée par d'autres, tel que
sbl-xbl.spamhaus.org, et en ce sens il ne semblait plus logique de
conserver le nom de MAPS dans la directive, d'où l'apparition d'un nouveau
nom reject_rbl_client qui correspond mieux à la réalité.

Elles correspondent, toutes les deux, à une même action : interroger une
DNSBL pour refuser un message.

V> D'autre part, je ne suis pas vraiment sûr qu'utiliser
V> reject_unauth_pipelining et reject_unauth_destination pour les
V> smtpd_sender_restrictions soit pertinent. Qu'en pensez-vous?

Par défaut postfix a

smtpd_delay_reject = yes

ce qui fait que cela n'a pas grand sens de mettre reject_unauth_pipelining
dans smtp_sender_restrictions puisque tous les test (helo, sender,
recipient) vont se faire après la phase RCPT TO.

reject_unauth_destination est plutôt pour smtpd_recipient_restrictions


--

Guy Decoux

ts égrapsen en <rfcmzopwrzu.fsf@moulon.inra.fr>:

> Par défaut postfix a
>
> smtpd_delay_reject = yes
>
> ce qui fait que cela n'a pas grand sens de mettre
> reject_unauth_pipelining dans smtp_sender_restrictions puisque tous
> les test (helo, sender, recipient) vont se faire après la phase
> RCPT TO.
>
> reject_unauth_destination est plutôt pour
> smtpd_recipient_restrictions

Merci.

ts égrapsen en <rfcmzopwrzu.fsf@moulon.inra.fr>:

> Par défaut postfix a
>
> smtpd_delay_reject = yes
>
> ce qui fait que cela n'a pas grand sens de mettre
> reject_unauth_pipelining dans smtp_sender_restrictions puisque tous
> les test (helo, sender, recipient) vont se faire après la phase
> RCPT TO.
>
> reject_unauth_destination est plutôt pour
> smtpd_recipient_restrictions

Merci.