Postfix et envoi de mails

mouss

23/09/2007 à 14:30

Sylvain wrote:

Bonjour à tous,

C'est un peu HS, mais je tente ma chance ;-)

J'ai un serveur de mail qui tourne sous Postfix et qui est configuré
pour faire du smtp auth avec tls : aucun problème, mon serveur n'est a
priori pas ouvert, et je ne peux envoyer de mail vers d'autres domaines
sans m'être correctement authentifié. Dans le cas contraire, je récupère
bien un "Relay access denied".

Par contre, je viens de m'apercevoir d'une chose : si depuis thunderbird
je choisis comme serveur d'envoi mon serveur sous Postfix, mais
configuré cette fois sans login/mdp ni tls, et que j'envoie un mail à un
de mes utilisateurs locaux (cela ne se passe heureusement que dans ce
cas là), le serveur accepte la requête et mon utilisateur local reçois
quand même le mail, sans que j'ai eu à m'authentifier ...

Est ce un comportement normal ?

disons quece n'est pas gênant. car si un utilisateur local envoie des
"mauvais" messages à un utilisteur local, il est possible d'agir
"localement".

N'y a t'il pas moyen de forcer
l'utilisation d'un login/mdp sous TLS, également pour l'envoi de mail à
des utilisateurs locaux ?

si, mais attention à ne pas bloquer les machine et applications qui
envoient du mail. ça peut arriver s'il y a des machines qui envoient des
rapport cron (logwatch par exemple), ... etc. Il ne serait pas super
pratique de devoir les configurer pour qu'ils utilisent de
l'authentification et/ou tls (enfin, ça depend du nombre de machines et
applications)

Mon main.cf :

en general, il faut envoyer la sortie de 'postconf -n'. (main.cf peut
contenir des erreurs, des duplications, ... alors que postconf -n dira
exactement ce que postfix a compris en parsant le fichier).

[snip]
smtpd_helo_restrictions > permit_mynetworks,
permit_sasl_authenticated,
reject_non_fqdn_hostname,
reject_invalid_hostname,
permit

smtpd_sender_restrictions > permit_mynetworks,
permit_sasl_authenticated,
reject_non_fqdn_sender,
reject_unknown_sender_domain,
permit

il vaut mieux mettre les checks ci-dessus dans
smtpd_recipient_restrictions, pour éviter de repeter les permit_* (la
permit_mynetworks et permit_sasl_authenticated est repete 3 fois).

smtpd_recipient_restrictions > permit_mynetworks,

c'est la. permit_mynetworks renvoie "OK" si le client est dedans. donc
aucun autre test ne sera appliqué.

reject_unlisted_recipient
reject_non_fqdn_recipient,

tu devrais intervertir les deux checks ci-dessus. pas la peine de
chercher dans une liste si l'adresse n'est ps bonne.

reject_unknown_recipient_domain,

c'est pas gentil pour les utilisateurs. en cas de problème dns (timeout,
...), thunderbird va recevoir un 4xx, ce qui va forcer l'utilisateur à
sauver le message, et de reessayer jusqu'à ce que ça passe.

il ne faut pas appliquer à tes propres utilisateurs des tests qui
peuvent foirer sans que ce soit de leur faute (problème dns, problème
serveur, ... etc). sinon, ils vont te hair assez vite. ce qui est loin
de rendre l'environnement sain.

permit_sasl_authenticated,
reject_unauth_destination,
reject_unauth_pipelining,

ça ne sert à rien ici. RCPT TO est une commande asynchrone (on peut en
envoyer plein sans attendre la réponse du serveur). donc postfix ne
jettera rien. par contre, tu peux la mettre dans smtpd_data_restrictions
(car DATA est une commande synchrone: le client doit attendre le "300
tapez votre mail et terminiez par un point")

check_policy_service inet:127.0.0.1:60000,
permit

si tu veux forcer l'authentification pour les clients (sauf localhost),
tu peux faire

mynetworks = 127.0.0.1
smtpd_sender_login_maps hash:/etc/postfix/sender_login

# on vire smtpd_[helo|sender|client]_restrictions
# et on met tous les tests sous smtpd_recipient_restrictions
# c'est sequentiel, et donc plus facile à suivre, et ça
# evite de repeter les permit_* ...

smtpd_recipient_restrictions reject_non_fqdn_sender
reject_non_fqdn_recipient
reject_unlisted_sender
reject_unlisted_recipient
permit_mynetworks
reject_sender_login_mismatch
permit_sasl_authenticated
reject_unauth_destination
reject_unknown_sender_domain
#check_sender_mx_access cidr:/etc/postfix/mx_access
reject_invalid_hostname
reject_non_fqdn_hostname
#reject_rbl_client zen.spamhaus.org
#reject_rbl_client korea.services.net
check_policy_service inet:127.0.0.1:60000

Le reject_sender_login_mismatch empeche un utilisateur d'utiliser une
adresse qui n'est pas la sienne. par exemple, si la table citée dans
smtpd_sender_login_maps contient

sylvain

alors il faut s'authentifier en tant que 'sylvain' si on veut utiliser
"" comme addresse d'expéditeur. si l'adresse n'est
pas dans la table, n'importe qui peut l'utiliser.

Attention: la ça s'applique à tout le mail, y compris un mail forwardé
de l'exterieur. mais bon, ça devrait être rare. d'aucuns prédisent même
que le forwarding à l'anicenne deviendra obsolète. mais restons sur terre.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Sylvain wrote:

Bonjour à tous,

C'est un peu HS, mais je tente ma chance ;-)

J'ai un serveur de mail qui tourne sous Postfix et qui est configuré
pour faire du smtp auth avec tls : aucun problème, mon serveur n'est a
priori pas ouvert, et je ne peux envoyer de mail vers d'autres domaines
sans m'être correctement authentifié. Dans le cas contraire, je récupère
bien un "Relay access denied".

Par contre, je viens de m'apercevoir d'une chose : si depuis thunderbird
je choisis comme serveur d'envoi mon serveur sous Postfix, mais
configuré cette fois sans login/mdp ni tls, et que j'envoie un mail à un
de mes utilisateurs locaux (cela ne se passe heureusement que dans ce
cas là), le serveur accepte la requête et mon utilisateur local reçois
quand même le mail, sans que j'ai eu à m'authentifier ...

Est ce un comportement normal ?

disons quece n'est pas gênant. car si un utilisateur local envoie des
"mauvais" messages à un utilisteur local, il est possible d'agir
"localement".

N'y a t'il pas moyen de forcer
l'utilisation d'un login/mdp sous TLS, également pour l'envoi de mail à
des utilisateurs locaux ?

si, mais attention à ne pas bloquer les machine et applications qui
envoient du mail. ça peut arriver s'il y a des machines qui envoient des
rapport cron (logwatch par exemple), ... etc. Il ne serait pas super
pratique de devoir les configurer pour qu'ils utilisent de
l'authentification et/ou tls (enfin, ça depend du nombre de machines et
applications)

Mon main.cf :

en general, il faut envoyer la sortie de 'postconf -n'. (main.cf peut
contenir des erreurs, des duplications, ... alors que postconf -n dira
exactement ce que postfix a compris en parsant le fichier).

[snip]
smtpd_helo_restrictions > permit_mynetworks,
permit_sasl_authenticated,
reject_non_fqdn_hostname,
reject_invalid_hostname,
permit

smtpd_sender_restrictions > permit_mynetworks,
permit_sasl_authenticated,
reject_non_fqdn_sender,
reject_unknown_sender_domain,
permit

il vaut mieux mettre les checks ci-dessus dans
smtpd_recipient_restrictions, pour éviter de repeter les permit_* (la
permit_mynetworks et permit_sasl_authenticated est repete 3 fois).

smtpd_recipient_restrictions > permit_mynetworks,

c'est la. permit_mynetworks renvoie "OK" si le client est dedans. donc
aucun autre test ne sera appliqué.

reject_unlisted_recipient
reject_non_fqdn_recipient,

tu devrais intervertir les deux checks ci-dessus. pas la peine de
chercher dans une liste si l'adresse n'est ps bonne.

reject_unknown_recipient_domain,

c'est pas gentil pour les utilisateurs. en cas de problème dns (timeout,
...), thunderbird va recevoir un 4xx, ce qui va forcer l'utilisateur à
sauver le message, et de reessayer jusqu'à ce que ça passe.

il ne faut pas appliquer à tes propres utilisateurs des tests qui
peuvent foirer sans que ce soit de leur faute (problème dns, problème
serveur, ... etc). sinon, ils vont te hair assez vite. ce qui est loin
de rendre l'environnement sain.

permit_sasl_authenticated,
reject_unauth_destination,
reject_unauth_pipelining,

ça ne sert à rien ici. RCPT TO est une commande asynchrone (on peut en
envoyer plein sans attendre la réponse du serveur). donc postfix ne
jettera rien. par contre, tu peux la mettre dans smtpd_data_restrictions
(car DATA est une commande synchrone: le client doit attendre le "300
tapez votre mail et terminiez par un point")

check_policy_service inet:127.0.0.1:60000,
permit

si tu veux forcer l'authentification pour les clients (sauf localhost),
tu peux faire

mynetworks = 127.0.0.1
smtpd_sender_login_maps hash:/etc/postfix/sender_login

# on vire smtpd_[helo|sender|client]_restrictions
# et on met tous les tests sous smtpd_recipient_restrictions
# c'est sequentiel, et donc plus facile à suivre, et ça
# evite de repeter les permit_* ...

smtpd_recipient_restrictions reject_non_fqdn_sender
reject_non_fqdn_recipient
reject_unlisted_sender
reject_unlisted_recipient
permit_mynetworks
reject_sender_login_mismatch
permit_sasl_authenticated
reject_unauth_destination
reject_unknown_sender_domain
#check_sender_mx_access cidr:/etc/postfix/mx_access
reject_invalid_hostname
reject_non_fqdn_hostname
#reject_rbl_client zen.spamhaus.org
#reject_rbl_client korea.services.net
check_policy_service inet:127.0.0.1:60000

Le reject_sender_login_mismatch empeche un utilisateur d'utiliser une
adresse qui n'est pas la sienne. par exemple, si la table citée dans
smtpd_sender_login_maps contient

sylvain@example.com sylvain

alors il faut s'authentifier en tant que 'sylvain' si on veut utiliser
"sylvain@example.com" comme addresse d'expéditeur. si l'adresse n'est
pas dans la table, n'importe qui peut l'utiliser.

Attention: la ça s'applique à tout le mail, y compris un mail forwardé
de l'exterieur. mais bon, ça devrait être rare. d'aucuns prédisent même
que le forwarding à l'anicenne deviendra obsolète. mais restons sur terre.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Vous avez filtré cet utilisateur ! Consultez son message

Sylvain wrote:

Bonjour à tous,

C'est un peu HS, mais je tente ma chance ;-)

J'ai un serveur de mail qui tourne sous Postfix et qui est configuré
pour faire du smtp auth avec tls : aucun problème, mon serveur n'est a
priori pas ouvert, et je ne peux envoyer de mail vers d'autres domaines
sans m'être correctement authentifié. Dans le cas contraire, je récupère
bien un "Relay access denied".

Par contre, je viens de m'apercevoir d'une chose : si depuis thunderbird
je choisis comme serveur d'envoi mon serveur sous Postfix, mais
configuré cette fois sans login/mdp ni tls, et que j'envoie un mail à un
de mes utilisateurs locaux (cela ne se passe heureusement que dans ce
cas là), le serveur accepte la requête et mon utilisateur local reçois
quand même le mail, sans que j'ai eu à m'authentifier ...

Est ce un comportement normal ?

disons quece n'est pas gênant. car si un utilisateur local envoie des
"mauvais" messages à un utilisteur local, il est possible d'agir
"localement".

N'y a t'il pas moyen de forcer
l'utilisation d'un login/mdp sous TLS, également pour l'envoi de mail à
des utilisateurs locaux ?

si, mais attention à ne pas bloquer les machine et applications qui
envoient du mail. ça peut arriver s'il y a des machines qui envoient des
rapport cron (logwatch par exemple), ... etc. Il ne serait pas super
pratique de devoir les configurer pour qu'ils utilisent de
l'authentification et/ou tls (enfin, ça depend du nombre de machines et
applications)

Mon main.cf :

en general, il faut envoyer la sortie de 'postconf -n'. (main.cf peut
contenir des erreurs, des duplications, ... alors que postconf -n dira
exactement ce que postfix a compris en parsant le fichier).

[snip]
smtpd_helo_restrictions > permit_mynetworks,
permit_sasl_authenticated,
reject_non_fqdn_hostname,
reject_invalid_hostname,
permit

smtpd_sender_restrictions > permit_mynetworks,
permit_sasl_authenticated,
reject_non_fqdn_sender,
reject_unknown_sender_domain,
permit

il vaut mieux mettre les checks ci-dessus dans
smtpd_recipient_restrictions, pour éviter de repeter les permit_* (la
permit_mynetworks et permit_sasl_authenticated est repete 3 fois).

smtpd_recipient_restrictions > permit_mynetworks,

c'est la. permit_mynetworks renvoie "OK" si le client est dedans. donc
aucun autre test ne sera appliqué.

reject_unlisted_recipient
reject_non_fqdn_recipient,

tu devrais intervertir les deux checks ci-dessus. pas la peine de
chercher dans une liste si l'adresse n'est ps bonne.

reject_unknown_recipient_domain,

c'est pas gentil pour les utilisateurs. en cas de problème dns (timeout,
...), thunderbird va recevoir un 4xx, ce qui va forcer l'utilisateur à
sauver le message, et de reessayer jusqu'à ce que ça passe.

il ne faut pas appliquer à tes propres utilisateurs des tests qui
peuvent foirer sans que ce soit de leur faute (problème dns, problème
serveur, ... etc). sinon, ils vont te hair assez vite. ce qui est loin
de rendre l'environnement sain.

permit_sasl_authenticated,
reject_unauth_destination,
reject_unauth_pipelining,

ça ne sert à rien ici. RCPT TO est une commande asynchrone (on peut en
envoyer plein sans attendre la réponse du serveur). donc postfix ne
jettera rien. par contre, tu peux la mettre dans smtpd_data_restrictions
(car DATA est une commande synchrone: le client doit attendre le "300
tapez votre mail et terminiez par un point")

check_policy_service inet:127.0.0.1:60000,
permit

si tu veux forcer l'authentification pour les clients (sauf localhost),
tu peux faire

mynetworks = 127.0.0.1
smtpd_sender_login_maps hash:/etc/postfix/sender_login

# on vire smtpd_[helo|sender|client]_restrictions
# et on met tous les tests sous smtpd_recipient_restrictions
# c'est sequentiel, et donc plus facile à suivre, et ça
# evite de repeter les permit_* ...

smtpd_recipient_restrictions reject_non_fqdn_sender
reject_non_fqdn_recipient
reject_unlisted_sender
reject_unlisted_recipient
permit_mynetworks
reject_sender_login_mismatch
permit_sasl_authenticated
reject_unauth_destination
reject_unknown_sender_domain
#check_sender_mx_access cidr:/etc/postfix/mx_access
reject_invalid_hostname
reject_non_fqdn_hostname
#reject_rbl_client zen.spamhaus.org
#reject_rbl_client korea.services.net
check_policy_service inet:127.0.0.1:60000

Le reject_sender_login_mismatch empeche un utilisateur d'utiliser une
adresse qui n'est pas la sienne. par exemple, si la table citée dans
smtpd_sender_login_maps contient

sylvain

alors il faut s'authentifier en tant que 'sylvain' si on veut utiliser
"" comme addresse d'expéditeur. si l'adresse n'est
pas dans la table, n'importe qui peut l'utiliser.

Attention: la ça s'applique à tout le mail, y compris un mail forwardé
de l'exterieur. mais bon, ça devrait être rare. d'aucuns prédisent même
que le forwarding à l'anicenne deviendra obsolète. mais restons sur terre.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Sylvain

23/09/2007 à 16:10

Bonjour,

Merci beaucoup pour tes explications détaillées. Je crois que j'y vois
un peu plus clair ;-)

Néanmoins, une petite chose m'embête :

smtpd_recipient_restrictions >> permit_mynetworks,

c'est la. permit_mynetworks renvoie "OK" si le client est dedans. donc
aucun autre test ne sera appliqué.

Justement, le client est un client distant qui ne s'est pas authentifié.
Comment peut il être considéré comme faisant partie de "mynetwork" ? Je
crois en fait que je ne comprends pas bien à quel moment le filtre
smtpd_recipient_resctictions s'applique ...

--
Sylvain

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Sylvain

23/09/2007 à 16:10

> Si je ne me trompe pas, mynetworks contient par défaut :
mynetworks = 127.0.0.0/8, 192.168.1.0/24

Si ton réseau est bien en 192.168.1.0/24, la machine distante est
automatiquement autorisée à utiliser le SMTP sans passer par les autres
tests.

Justement, ma variable est fixée comme suit :
mynetworks = 127.0.0.0/8
et rien d'autre (c'est un serveur dédié qui n'est pas chez moi).

Du coup, je ne comprends pas ...

--
Sylvain

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Julien Valroff

23/09/2007 à 16:10

Bonjour,

Le dimanche 23 septembre 2007 à 16:00 +0200, Sylvain a écrit :

Bonjour,

Merci beaucoup pour tes explications détaillées. Je crois que j'y vois
un peu plus clair ;-)

Néanmoins, une petite chose m'embête :

>> smtpd_recipient_restrictions > >> permit_mynetworks,
>
> c'est la. permit_mynetworks renvoie "OK" si le client est dedans. donc
> aucun autre test ne sera appliqué.

Justement, le client est un client distant qui ne s'est pas authentifié.
Comment peut il être considéré comme faisant partie de "mynetwork" ? Je
crois en fait que je ne comprends pas bien à quel moment le filtre
smtpd_recipient_resctictions s'applique ...

Si je ne me trompe pas, mynetworks contient par défaut :
mynetworks = 127.0.0.0/8, 192.168.1.0/24

Si ton réseau est bien en 192.168.1.0/24, la machine distante est
automatiquement autorisée à utiliser le SMTP sans passer par les autres
tests.

@++
Julien

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Stephane Bortzmeyer

23/09/2007 à 18:50

On Sun, Sep 23, 2007 at 04:09:00PM +0200,
Sylvain wrote
a message of 26 lines which said:

Justement, ma variable est fixée comme suit :
mynetworks = 127.0.0.0/8
et rien d'autre (c'est un serveur dédié qui n'est pas chez moi).

Mouais, je suis sceptique, je demande à voir les journaux du serveur
Postfix pour être sûr que le client est bien différent de 127.0.0.0/8.

Du coup, je ne comprends pas ...

Un tunnel, non ? C'est courant avec les machines qu'on gère à
distance.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Sylvain

23/09/2007 à 20:30

> Mouais, je suis sceptique, je demande à voir les journaux du serveur
Postfix pour être sûr que le client est bien différent de 127.0.0.0/8.

Alors voilà ce que j'ai dans mail.log :

Sep 23 20:11:34 kimsufi postfix/smtpd[8547]: connect from
mir31-2-82-227-181-153.fbx.proxad.net[82.227.181.153]
Sep 23 20:11:35 kimsufi postgrey[3670]: delayed 25100 seconds:
client=mir31-2-82-227-181-153.fbx.proxad.net, from=,
to=
Sep 23 20:11:35 kimsufi postfix/smtpd[8547]: 12AE1268F9:
client=mir31-2-82-227-181-153.fbx.proxad.net[82.227.181.153]
Sep 23 20:11:35 kimsufi postfix/cleanup[10447]: 12AE1268F9:
message-id=
Sep 23 20:11:35 kimsufi postfix/qmgr[27015]: 12AE1268F9:
from=, sizec9, nrcpt=1 (queue active)
Sep 23 20:11:35 kimsufi spamd[15282]: spamd: connection from
localhost.localdomain [127.0.0.1] at port 3758
Sep 23 20:11:35 kimsufi spamd[15282]: spamd: setuid to sylar succeeded
Sep 23 20:11:35 kimsufi spamd[15282]: spamd: processing message
for sylar:1000
Sep 23 20:11:35 kimsufi postfix/smtpd[8547]: disconnect from
mir31-2-82-227-181-153.fbx.proxad.net[82.227.181.153]
Sep 23 20:11:35 kimsufi spamd[15282]: spamd: clean message (0.0/5.0) for
sylar:1000 in 0.6 seconds, 764 bytes.
Sep 23 20:11:35 kimsufi spamd[15282]: spamd: result: . 0 -
scantime=0.6,sizev4,user=sylar,uid00,required_score=5.0,rhost=localhost.localdomain,raddr7.0.0.1,rport758,mid=,autolearn=ham

Sep 23 20:11:35 kimsufi spamd[26474]: prefork: child states: II
Sep 23 20:11:35 kimsufi postfix/local[10448]: 12AE1268F9:
to=, relay=local, delay=1, delays=0.28/0.01/0/0.73,
dsn=2.0.0, status=sent (delivered to command: procmail -a "$EXTENSION")
Sep 23 20:11:35 kimsufi postfix/qmgr[27015]: 12AE1268F9: removed

Un tunnel, non ? C'est courant avec les machines qu'on gère à
distance.

C'est à dire ? J'avoue que ne comprends tjs pas ...

--
Sylvain

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

> Mouais, je suis sceptique, je demande à voir les journaux du serveur
Postfix pour être sûr que le client est bien différent de 127.0.0.0/8.

Alors voilà ce que j'ai dans mail.log :

Sep 23 20:11:34 kimsufi postfix/smtpd[8547]: connect from
mir31-2-82-227-181-153.fbx.proxad.net[82.227.181.153]
Sep 23 20:11:35 kimsufi postgrey[3670]: delayed 25100 seconds:
client=mir31-2-82-227-181-153.fbx.proxad.net, from=sylar@sylar.org,
to=sylar@sylar.org
Sep 23 20:11:35 kimsufi postfix/smtpd[8547]: 12AE1268F9:
client=mir31-2-82-227-181-153.fbx.proxad.net[82.227.181.153]
Sep 23 20:11:35 kimsufi postfix/cleanup[10447]: 12AE1268F9:
message-id=<46F6AD20.2070709@sylar.org>
Sep 23 20:11:35 kimsufi postfix/qmgr[27015]: 12AE1268F9:
from=<sylar@sylar.org>, sizec9, nrcpt=1 (queue active)
Sep 23 20:11:35 kimsufi spamd[15282]: spamd: connection from
localhost.localdomain [127.0.0.1] at port 3758
Sep 23 20:11:35 kimsufi spamd[15282]: spamd: setuid to sylar succeeded
Sep 23 20:11:35 kimsufi spamd[15282]: spamd: processing message
<46F6AD20.2070709@sylar.org> for sylar:1000
Sep 23 20:11:35 kimsufi postfix/smtpd[8547]: disconnect from
mir31-2-82-227-181-153.fbx.proxad.net[82.227.181.153]
Sep 23 20:11:35 kimsufi spamd[15282]: spamd: clean message (0.0/5.0) for
sylar:1000 in 0.6 seconds, 764 bytes.
Sep 23 20:11:35 kimsufi spamd[15282]: spamd: result: . 0 -
scantime=0.6,sizev4,user=sylar,uid00,required_score=5.0,rhost=localhost.localdomain,raddr7.0.0.1,rport758,mid=<46F6AD20.2070709@sylar.org>,autolearn=ham

Sep 23 20:11:35 kimsufi spamd[26474]: prefork: child states: II
Sep 23 20:11:35 kimsufi postfix/local[10448]: 12AE1268F9:
to=<sylar@sylar.org>, relay=local, delay=1, delays=0.28/0.01/0/0.73,
dsn=2.0.0, status=sent (delivered to command: procmail -a "$EXTENSION")
Sep 23 20:11:35 kimsufi postfix/qmgr[27015]: 12AE1268F9: removed

Un tunnel, non ? C'est courant avec les machines qu'on gère à
distance.

C'est à dire ? J'avoue que ne comprends tjs pas ...

--
Sylvain

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Vous avez filtré cet utilisateur ! Consultez son message

> Mouais, je suis sceptique, je demande à voir les journaux du serveur
Postfix pour être sûr que le client est bien différent de 127.0.0.0/8.

Alors voilà ce que j'ai dans mail.log :

Sep 23 20:11:34 kimsufi postfix/smtpd[8547]: connect from
mir31-2-82-227-181-153.fbx.proxad.net[82.227.181.153]
Sep 23 20:11:35 kimsufi postgrey[3670]: delayed 25100 seconds:
client=mir31-2-82-227-181-153.fbx.proxad.net, from=,
to=
Sep 23 20:11:35 kimsufi postfix/smtpd[8547]: 12AE1268F9:
client=mir31-2-82-227-181-153.fbx.proxad.net[82.227.181.153]
Sep 23 20:11:35 kimsufi postfix/cleanup[10447]: 12AE1268F9:
message-id=
Sep 23 20:11:35 kimsufi postfix/qmgr[27015]: 12AE1268F9:
from=, sizec9, nrcpt=1 (queue active)
Sep 23 20:11:35 kimsufi spamd[15282]: spamd: connection from
localhost.localdomain [127.0.0.1] at port 3758
Sep 23 20:11:35 kimsufi spamd[15282]: spamd: setuid to sylar succeeded
Sep 23 20:11:35 kimsufi spamd[15282]: spamd: processing message
for sylar:1000
Sep 23 20:11:35 kimsufi postfix/smtpd[8547]: disconnect from
mir31-2-82-227-181-153.fbx.proxad.net[82.227.181.153]
Sep 23 20:11:35 kimsufi spamd[15282]: spamd: clean message (0.0/5.0) for
sylar:1000 in 0.6 seconds, 764 bytes.
Sep 23 20:11:35 kimsufi spamd[15282]: spamd: result: . 0 -
scantime=0.6,sizev4,user=sylar,uid00,required_score=5.0,rhost=localhost.localdomain,raddr7.0.0.1,rport758,mid=,autolearn=ham

Sep 23 20:11:35 kimsufi spamd[26474]: prefork: child states: II
Sep 23 20:11:35 kimsufi postfix/local[10448]: 12AE1268F9:
to=, relay=local, delay=1, delays=0.28/0.01/0/0.73,
dsn=2.0.0, status=sent (delivered to command: procmail -a "$EXTENSION")
Sep 23 20:11:35 kimsufi postfix/qmgr[27015]: 12AE1268F9: removed

Un tunnel, non ? C'est courant avec les machines qu'on gère à
distance.

C'est à dire ? J'avoue que ne comprends tjs pas ...

--
Sylvain

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Sylvain

23/09/2007 à 20:40

[Alors voilà ce que j'ai dans mail.log :]

J'ai oublié de préciser que tout cela était lors d'un envoi vers un
utilisateur local, avec le serveur d'envoi configuré sans usr/mdp ni tls.

Dans un autre cas (message vers la liste), voilà ce que j'ai :
Sep 23 20:26:10 kimsufi postfix/smtpd[11293]: connect from
mir31-2-82-227-181-153.fbx.proxad.net[82.227.181.153]
Sep 23 20:26:12 kimsufi postfix/smtpd[11293]: 01555268E9:
client=mir31-2-82-227-181-153.fbx.proxad.net[82.227.181.153],
sasl_method=CRAM-MD5, sasl_username=
Sep 23 20:26:12 kimsufi postfix/cleanup[11327]: 01555268E9:
message-id=
Sep 23 20:26:12 kimsufi postfix/qmgr[27015]: 01555268E9:
from=, size(97, nrcpt=1 (queue active)
Sep 23 20:26:12 kimsufi postfix/smtpd[11293]: disconnect from
mir31-2-82-227-181-153.fbx.proxad.net[82.227.181.153]
Sep 23 20:26:13 kimsufi postfix/smtp[11329]: 01555268E9:
to=,
relay=murphy.debian.org[70.103.162.31]:25, delay=1.6,
delays=0.35/0.04/0.77/0.42, dsn=2.0.0, status=sent (250 Ok: queued as
6A5E52E59D)
Sep 23 20:26:13 kimsufi postfix/qmgr[27015]: 01555268E9: removed

--
Sylvain

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Stephane Bortzmeyer

24/09/2007 à 21:40

On Sun, Sep 23, 2007 at 08:34:52PM +0200,
Sylvain wrote
a message of 37 lines which said:

J'ai oublié de préciser que tout cela était lors d'un envoi vers un
utilisateur local,

Là, c'est moi, qui ne comprend plus. Si l'utilisateur est local, il
est normal que cela marche, non ? Sinon, un MTA distant (a priori sans
compte chez vous) ne pourrait jamais envoyer de courrier.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

mouss

25/09/2007 à 02:00

Sylvain wrote:

[Alors voilà ce que j'ai dans mail.log :]

J'ai oublié de préciser que tout cela était lors d'un envoi vers un
utilisateur local, avec le serveur d'envoi configuré sans usr/mdp ni tls.

l'envoi vers un utilisateur local est autorisé sauf si tu le bloques
explicitement. reject_unauth_destination empeche le relay, c'est-à-dire
l'envoi à des domaines que tu ne geres pas.

Dans un autre cas (message vers la liste), voilà ce que j'ai :
Sep 23 20:26:10 kimsufi postfix/smtpd[11293]: connect from
mir31-2-82-227-181-153.fbx.proxad.net[82.227.181.153]

la il se connecte, et le pid de smtpd est le même que la ligne suivante,
donc même transaction:

Sep 23 20:26:12 kimsufi postfix/smtpd[11293]: 01555268E9:
client=mir31-2-82-227-181-153.fbx.proxad.net[82.227.181.153],
sasl_method=CRAM-MD5, sasl_username=

la, l'utilisateur s'est authentifié. donc permit_sasl_authenticated
l'autorise à passer.

Sep 23 20:26:12 kimsufi postfix/cleanup[11327]: 01555268E9:
message-id=

c'est rapport au même message (même queueid)

Sep 23 20:26:12 kimsufi postfix/qmgr[27015]: 01555268E9:
from=, size(97, nrcpt=1 (queue active)

encore la même transaction (toujours le queueid)

Sep 23 20:26:12 kimsufi postfix/smtpd[11293]: disconnect from
mir31-2-82-227-181-153.fbx.proxad.net[82.227.181.153]

il se deconnecte (le pid de smtpd est celui d'en haut)

Sep 23 20:26:13 kimsufi postfix/smtp[11329]: 01555268E9:
to=,
relay=murphy.debian.org[70.103.162.31]:25, delay=1.6,
delays=0.35/0.04/0.77/0.42, dsn=2.0.0, status=sent (250 Ok: queued as
6A5E52E59D)

la; le message est relayé (même queueid).

Sep 23 20:26:13 kimsufi postfix/qmgr[27015]: 01555268E9: removed

et la, qmgr dit qu'il en fini avec (toujours le même queueid).

donc les logs ci-dessus concernent une transaction authentifée.

pour revenir à une question précédente, les smtpd_*_restrictions sont
exécutées à chaque RCPT TO (donc une fois par destinataire). [la, je
parle du mode par défaut. si tu mets smtpd_delay_reject=no, les
smtpd_*_restrictions sont executées à chaque "stage". mais ce mode n'est
pas conseillé, car tu auras moins de logs, et aussi parce que certains
softs de mail gèrent mal les réponses "inattendues" avant RCPT TO.).

En admettant que tu n'ayes que smtpd_recipient_restrictions, les tests
sont faits de façon séquentielle. si un test renvoie une "résultat
final", le resultat est utilisé, et les tests s'arretent. si un test ne
retourne pas de resultat ou s'il retourne un resultat "non final", le
resultat est utilisé, mais les tests suivants seront examinés.

- resultat final: principalement OK et REJECT (et leur famille, y
compris des reject_*).

- resultat non final: DUNNO (neutre, on fait rien et on passe au test
suivant), FILTER (ça selectionne le content_filter. attention à ne pas
l'utiliser en fonction du destinataire, car ça causera des surprises en
cas de message adressé à plusieurs destinataires), REDIRECT, ...

comme je ne paye pas ma connexion à la ligne je vais me permettre de
faire long :)

Reprenons l'exemple:

smtpd_recipient_restrictions reject_non_fqdn_sender

- on rejette si l'adresse de l'expediteur ne contient pas de domaine
avec un point (ça jettera "toto" et "", mais ne jettera pas
"").

reject_non_fqdn_recipient

- idem pour l'adresse destinataire

reject_unlisted_sender
- on rejette si l'adresse de l'expediteur utilise un de nos domaine,
mais n'existe pas dans nos listes (genre "").

reject_unlisted_recipient
- idem pour le destinataire. [ce dernier test n'est pas necessaire dans
la config par defaut, car postfix le fera à la fin. mais il vaut mieux
l'executer ici, histoire de ne pas faire des requetes dns et autres pour
un mail qu'on va jeter].

permit_mynetworks
- si le client est dans mynetworks, on autorise la transaction. dans ce
cas, les tests suivants ne seront pas executés (c'est comme un "break"
dans une boucle for/while).

reject_sender_login_mismatch
- si l'adresse de l'expediteur a un "owner", il faut que la transaction
soit authentifiée avec le bon login.

permit_sasl_authenticated
- si l'utilisateur s'est authentifié, on autorise. sinon, on continue
avec les tests suivants.

reject_unauth_destination
- on jette si le destinataire n'est pas dans un de nos domaines. c'est
le test le plus important, car sans lui, on ouvre un trou (open relay).
il faut faire attention à ne pas retourner un "OK" accidentel avant ce
test. (donc, evite les check_sender_access et compagnie avant ce test.
si necessaire, les mettre dans smtpd_sender_restrictions ou autres).

reject_unknown_sender_domain
- si on ne peut pas resoudre le domaine de l'expediteur, alors on ne
pourra pas lui répondre, et peut-etre n'existe-t-il pas. on rejette (si
l'echec est temporaire, le code de retour le sera aussi. et par defaut,
le code sera toujours temporaire, même si on a un NXDOMAIN. à ne changer
que si on sait pourquoi).

#check_sender_mx_access cidr:/etc/postfix/mx_access
- on verifie que le domaine de l'expediteur n'a pas un MX "pourri". ce
test est generalement fait pour choper les domaines "martiens" (le mx
est une IP privée, principalement 127.0.0.1) ou les domaines
"inverifiables" (domaines avec des "wildcard". comme a fait verisign
pendant un moment avec son sitefinder. mais comme le font encore
quelques TLDs comme "museum". essaye host "*.museum" ou host
random_name.musuem. on peut même faire host _.museum, alors que _ n'est
pas un caractere valide. à part museum, il y a une dizaine de suffixes
de pays qui ont le même problème).

reject_invalid_hostname
- on jette si l'argument de HELO/EHLO contient des caracteres non
valables. par souci de compatibilité, le '_' est autorisé. si tu veut le
bloquer, il faut utiliser un check_helo_access.

reject_non_fqdn_hostname
- on jette si l'argument de helo/ehlo n'est pas une vraie "literal IP"
ni un domaine avec un point '.' dedans. (ça jettera donc "10.1.2.3",
"[900.1.2.3]", "mycomputer3", mais pas "tata.toto"). ça jettera aussi
"localhost", même si un puriste peut dire que c'est un fqdn (ça remonte
jusqu'au root du tld, qui est lui même), mais compte tenu de la
tradition des resolvers qui rajoute les domaines listés dans
/etc/resolv.conf en cas d'absence de '.', les puriste n'ont plus rien à
dire:).

#reject_rbl_client zen.spamhaus.org
- on jette si l'IP du client est dans zen.spamhaus.org. liste conseillée
vivement.

#reject_rbl_client korea.services.net
- on jette si l'IP est dans la liste sus-nommée. liste créee par John
Levine, qui est quelqu'un de respectable, et on peut lui faire
confiance. de toute façon, ça ne concerne que des IPs corréennes.
sachant qu'il y des gens qui bloquent tout le pays, ...

check_policy_service inet:127.0.0.1:60000
- on passe au "policy server"...

j'espère que ça clarifie des choses.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Sylvain wrote:

[Alors voilà ce que j'ai dans mail.log :]

J'ai oublié de préciser que tout cela était lors d'un envoi vers un
utilisateur local, avec le serveur d'envoi configuré sans usr/mdp ni tls.

l'envoi vers un utilisateur local est autorisé sauf si tu le bloques
explicitement. reject_unauth_destination empeche le relay, c'est-à-dire
l'envoi à des domaines que tu ne geres pas.

Dans un autre cas (message vers la liste), voilà ce que j'ai :
Sep 23 20:26:10 kimsufi postfix/smtpd[11293]: connect from
mir31-2-82-227-181-153.fbx.proxad.net[82.227.181.153]

la il se connecte, et le pid de smtpd est le même que la ligne suivante,
donc même transaction:

Sep 23 20:26:12 kimsufi postfix/smtpd[11293]: 01555268E9:
client=mir31-2-82-227-181-153.fbx.proxad.net[82.227.181.153],
sasl_method=CRAM-MD5, sasl_username=mailuser@sylar.org

la, l'utilisateur s'est authentifié. donc permit_sasl_authenticated
l'autorise à passer.

Sep 23 20:26:12 kimsufi postfix/cleanup[11327]: 01555268E9:
message-id=<46F6B08E.8020001@sylar.org>

c'est rapport au même message (même queueid)

Sep 23 20:26:12 kimsufi postfix/qmgr[27015]: 01555268E9:
from=<mailinglist@sylar.org>, size(97, nrcpt=1 (queue active)

encore la même transaction (toujours le queueid)

Sep 23 20:26:12 kimsufi postfix/smtpd[11293]: disconnect from
mir31-2-82-227-181-153.fbx.proxad.net[82.227.181.153]

il se deconnecte (le pid de smtpd est celui d'en haut)

Sep 23 20:26:13 kimsufi postfix/smtp[11329]: 01555268E9:
to=<debian-user-french@lists.debian.org>,
relay=murphy.debian.org[70.103.162.31]:25, delay=1.6,
delays=0.35/0.04/0.77/0.42, dsn=2.0.0, status=sent (250 Ok: queued as
6A5E52E59D)

la; le message est relayé (même queueid).

Sep 23 20:26:13 kimsufi postfix/qmgr[27015]: 01555268E9: removed

et la, qmgr dit qu'il en fini avec (toujours le même queueid).

donc les logs ci-dessus concernent une transaction authentifée.

pour revenir à une question précédente, les smtpd_*_restrictions sont
exécutées à chaque RCPT TO (donc une fois par destinataire). [la, je
parle du mode par défaut. si tu mets smtpd_delay_reject=no, les
smtpd_*_restrictions sont executées à chaque "stage". mais ce mode n'est
pas conseillé, car tu auras moins de logs, et aussi parce que certains
softs de mail gèrent mal les réponses "inattendues" avant RCPT TO.).

En admettant que tu n'ayes que smtpd_recipient_restrictions, les tests
sont faits de façon séquentielle. si un test renvoie une "résultat
final", le resultat est utilisé, et les tests s'arretent. si un test ne
retourne pas de resultat ou s'il retourne un resultat "non final", le
resultat est utilisé, mais les tests suivants seront examinés.

- resultat final: principalement OK et REJECT (et leur famille, y
compris des reject_*).

- resultat non final: DUNNO (neutre, on fait rien et on passe au test
suivant), FILTER (ça selectionne le content_filter. attention à ne pas
l'utiliser en fonction du destinataire, car ça causera des surprises en
cas de message adressé à plusieurs destinataires), REDIRECT, ...

comme je ne paye pas ma connexion à la ligne je vais me permettre de
faire long :)

Reprenons l'exemple:

smtpd_recipient_restrictions reject_non_fqdn_sender

- on rejette si l'adresse de l'expediteur ne contient pas de domaine
avec un point (ça jettera "toto" et "toto@tata", mais ne jettera pas
"toto@patata.patati").

reject_non_fqdn_recipient

- idem pour l'adresse destinataire

reject_unlisted_sender
- on rejette si l'adresse de l'expediteur utilise un de nos domaine,
mais n'existe pas dans nos listes (genre "nexistepas@mydomain.example").

reject_unlisted_recipient
- idem pour le destinataire. [ce dernier test n'est pas necessaire dans
la config par defaut, car postfix le fera à la fin. mais il vaut mieux
l'executer ici, histoire de ne pas faire des requetes dns et autres pour
un mail qu'on va jeter].

permit_mynetworks
- si le client est dans mynetworks, on autorise la transaction. dans ce
cas, les tests suivants ne seront pas executés (c'est comme un "break"
dans une boucle for/while).

reject_sender_login_mismatch
- si l'adresse de l'expediteur a un "owner", il faut que la transaction
soit authentifiée avec le bon login.

permit_sasl_authenticated
- si l'utilisateur s'est authentifié, on autorise. sinon, on continue
avec les tests suivants.

reject_unauth_destination
- on jette si le destinataire n'est pas dans un de nos domaines. c'est
le test le plus important, car sans lui, on ouvre un trou (open relay).
il faut faire attention à ne pas retourner un "OK" accidentel avant ce
test. (donc, evite les check_sender_access et compagnie avant ce test.
si necessaire, les mettre dans smtpd_sender_restrictions ou autres).

reject_unknown_sender_domain
- si on ne peut pas resoudre le domaine de l'expediteur, alors on ne
pourra pas lui répondre, et peut-etre n'existe-t-il pas. on rejette (si
l'echec est temporaire, le code de retour le sera aussi. et par defaut,
le code sera toujours temporaire, même si on a un NXDOMAIN. à ne changer
que si on sait pourquoi).

#check_sender_mx_access cidr:/etc/postfix/mx_access
- on verifie que le domaine de l'expediteur n'a pas un MX "pourri". ce
test est generalement fait pour choper les domaines "martiens" (le mx
est une IP privée, principalement 127.0.0.1) ou les domaines
"inverifiables" (domaines avec des "wildcard". comme a fait verisign
pendant un moment avec son sitefinder. mais comme le font encore
quelques TLDs comme "museum". essaye host "*.museum" ou host
random_name.musuem. on peut même faire host _.museum, alors que _ n'est
pas un caractere valide. à part museum, il y a une dizaine de suffixes
de pays qui ont le même problème).

reject_invalid_hostname
- on jette si l'argument de HELO/EHLO contient des caracteres non
valables. par souci de compatibilité, le '_' est autorisé. si tu veut le
bloquer, il faut utiliser un check_helo_access.

reject_non_fqdn_hostname
- on jette si l'argument de helo/ehlo n'est pas une vraie "literal IP"
ni un domaine avec un point '.' dedans. (ça jettera donc "10.1.2.3",
"[900.1.2.3]", "mycomputer3", mais pas "tata.toto"). ça jettera aussi
"localhost", même si un puriste peut dire que c'est un fqdn (ça remonte
jusqu'au root du tld, qui est lui même), mais compte tenu de la
tradition des resolvers qui rajoute les domaines listés dans
/etc/resolv.conf en cas d'absence de '.', les puriste n'ont plus rien à
dire:).

#reject_rbl_client zen.spamhaus.org
- on jette si l'IP du client est dans zen.spamhaus.org. liste conseillée
vivement.

#reject_rbl_client korea.services.net
- on jette si l'IP est dans la liste sus-nommée. liste créee par John
Levine, qui est quelqu'un de respectable, et on peut lui faire
confiance. de toute façon, ça ne concerne que des IPs corréennes.
sachant qu'il y des gens qui bloquent tout le pays, ...

check_policy_service inet:127.0.0.1:60000
- on passe au "policy server"...

j'espère que ça clarifie des choses.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Vous avez filtré cet utilisateur ! Consultez son message

Sylvain wrote:

[Alors voilà ce que j'ai dans mail.log :]

J'ai oublié de préciser que tout cela était lors d'un envoi vers un
utilisateur local, avec le serveur d'envoi configuré sans usr/mdp ni tls.

l'envoi vers un utilisateur local est autorisé sauf si tu le bloques
explicitement. reject_unauth_destination empeche le relay, c'est-à-dire
l'envoi à des domaines que tu ne geres pas.

Dans un autre cas (message vers la liste), voilà ce que j'ai :
Sep 23 20:26:10 kimsufi postfix/smtpd[11293]: connect from
mir31-2-82-227-181-153.fbx.proxad.net[82.227.181.153]

la il se connecte, et le pid de smtpd est le même que la ligne suivante,
donc même transaction:

Sep 23 20:26:12 kimsufi postfix/smtpd[11293]: 01555268E9:
client=mir31-2-82-227-181-153.fbx.proxad.net[82.227.181.153],
sasl_method=CRAM-MD5, sasl_username=

la, l'utilisateur s'est authentifié. donc permit_sasl_authenticated
l'autorise à passer.

Sep 23 20:26:12 kimsufi postfix/cleanup[11327]: 01555268E9:
message-id=

c'est rapport au même message (même queueid)

Sep 23 20:26:12 kimsufi postfix/qmgr[27015]: 01555268E9:
from=, size(97, nrcpt=1 (queue active)

encore la même transaction (toujours le queueid)

Sep 23 20:26:12 kimsufi postfix/smtpd[11293]: disconnect from
mir31-2-82-227-181-153.fbx.proxad.net[82.227.181.153]

il se deconnecte (le pid de smtpd est celui d'en haut)

Sep 23 20:26:13 kimsufi postfix/smtp[11329]: 01555268E9:
to=,
relay=murphy.debian.org[70.103.162.31]:25, delay=1.6,
delays=0.35/0.04/0.77/0.42, dsn=2.0.0, status=sent (250 Ok: queued as
6A5E52E59D)

la; le message est relayé (même queueid).

Sep 23 20:26:13 kimsufi postfix/qmgr[27015]: 01555268E9: removed

et la, qmgr dit qu'il en fini avec (toujours le même queueid).

donc les logs ci-dessus concernent une transaction authentifée.

pour revenir à une question précédente, les smtpd_*_restrictions sont
exécutées à chaque RCPT TO (donc une fois par destinataire). [la, je
parle du mode par défaut. si tu mets smtpd_delay_reject=no, les
smtpd_*_restrictions sont executées à chaque "stage". mais ce mode n'est
pas conseillé, car tu auras moins de logs, et aussi parce que certains
softs de mail gèrent mal les réponses "inattendues" avant RCPT TO.).

En admettant que tu n'ayes que smtpd_recipient_restrictions, les tests
sont faits de façon séquentielle. si un test renvoie une "résultat
final", le resultat est utilisé, et les tests s'arretent. si un test ne
retourne pas de resultat ou s'il retourne un resultat "non final", le
resultat est utilisé, mais les tests suivants seront examinés.

- resultat final: principalement OK et REJECT (et leur famille, y
compris des reject_*).

- resultat non final: DUNNO (neutre, on fait rien et on passe au test
suivant), FILTER (ça selectionne le content_filter. attention à ne pas
l'utiliser en fonction du destinataire, car ça causera des surprises en
cas de message adressé à plusieurs destinataires), REDIRECT, ...

comme je ne paye pas ma connexion à la ligne je vais me permettre de
faire long :)

Reprenons l'exemple:

smtpd_recipient_restrictions reject_non_fqdn_sender

- on rejette si l'adresse de l'expediteur ne contient pas de domaine
avec un point (ça jettera "toto" et "", mais ne jettera pas
"").

reject_non_fqdn_recipient

- idem pour l'adresse destinataire

reject_unlisted_sender
- on rejette si l'adresse de l'expediteur utilise un de nos domaine,
mais n'existe pas dans nos listes (genre "").

reject_unlisted_recipient
- idem pour le destinataire. [ce dernier test n'est pas necessaire dans
la config par defaut, car postfix le fera à la fin. mais il vaut mieux
l'executer ici, histoire de ne pas faire des requetes dns et autres pour
un mail qu'on va jeter].

permit_mynetworks
- si le client est dans mynetworks, on autorise la transaction. dans ce
cas, les tests suivants ne seront pas executés (c'est comme un "break"
dans une boucle for/while).

reject_sender_login_mismatch
- si l'adresse de l'expediteur a un "owner", il faut que la transaction
soit authentifiée avec le bon login.

permit_sasl_authenticated
- si l'utilisateur s'est authentifié, on autorise. sinon, on continue
avec les tests suivants.

reject_unauth_destination
- on jette si le destinataire n'est pas dans un de nos domaines. c'est
le test le plus important, car sans lui, on ouvre un trou (open relay).
il faut faire attention à ne pas retourner un "OK" accidentel avant ce
test. (donc, evite les check_sender_access et compagnie avant ce test.
si necessaire, les mettre dans smtpd_sender_restrictions ou autres).

reject_unknown_sender_domain
- si on ne peut pas resoudre le domaine de l'expediteur, alors on ne
pourra pas lui répondre, et peut-etre n'existe-t-il pas. on rejette (si
l'echec est temporaire, le code de retour le sera aussi. et par defaut,
le code sera toujours temporaire, même si on a un NXDOMAIN. à ne changer
que si on sait pourquoi).

#check_sender_mx_access cidr:/etc/postfix/mx_access
- on verifie que le domaine de l'expediteur n'a pas un MX "pourri". ce
test est generalement fait pour choper les domaines "martiens" (le mx
est une IP privée, principalement 127.0.0.1) ou les domaines
"inverifiables" (domaines avec des "wildcard". comme a fait verisign
pendant un moment avec son sitefinder. mais comme le font encore
quelques TLDs comme "museum". essaye host "*.museum" ou host
random_name.musuem. on peut même faire host _.museum, alors que _ n'est
pas un caractere valide. à part museum, il y a une dizaine de suffixes
de pays qui ont le même problème).

reject_invalid_hostname
- on jette si l'argument de HELO/EHLO contient des caracteres non
valables. par souci de compatibilité, le '_' est autorisé. si tu veut le
bloquer, il faut utiliser un check_helo_access.

reject_non_fqdn_hostname
- on jette si l'argument de helo/ehlo n'est pas une vraie "literal IP"
ni un domaine avec un point '.' dedans. (ça jettera donc "10.1.2.3",
"[900.1.2.3]", "mycomputer3", mais pas "tata.toto"). ça jettera aussi
"localhost", même si un puriste peut dire que c'est un fqdn (ça remonte
jusqu'au root du tld, qui est lui même), mais compte tenu de la
tradition des resolvers qui rajoute les domaines listés dans
/etc/resolv.conf en cas d'absence de '.', les puriste n'ont plus rien à
dire:).

#reject_rbl_client zen.spamhaus.org
- on jette si l'IP du client est dans zen.spamhaus.org. liste conseillée
vivement.

#reject_rbl_client korea.services.net
- on jette si l'IP est dans la liste sus-nommée. liste créee par John
Levine, qui est quelqu'un de respectable, et on peut lui faire
confiance. de toute façon, ça ne concerne que des IPs corréennes.
sachant qu'il y des gens qui bloquent tout le pays, ...

check_policy_service inet:127.0.0.1:60000
- on passe au "policy server"...

j'espère que ça clarifie des choses.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Sylvain

25/09/2007 à 09:20

> [Plein de trucs super intéressants]

j'espère que ça clarifie des choses.

Oui, très nettement ;-)
Merci beaucoup en tout cas !

--
Sylvain

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Postfix et envoi de mails

10 réponses

Veuillez sélectionner un problème