Postfix et envoi de mails

Le
Sylvain
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 ? 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 ?

Mon main.cf :

# Debian specific: Specifying a file name will cause the first
# line of that file to be used as the name. The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
# delay_warning_time = 4h

# TLS parameters
smtpd_use_tls=yes
smtpd_tls_auth_only = yes
smtpd_tls_cert_file=/etc/postfix/ssl/certificat.cert
smtpd_tls_key_file=/etc/postfix/ssl/clef.rsa.key
smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.

myhostname =
mydomain = ..
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
sender_canonical_maps = hash:/etc/postfix/canonical
myorigin = $mydomain
mydestination = $myhostname, $mydomain, localhost.$mydomain, localhost
relayhost =
mynetworks = 127.0.0.0/8
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
home_mailbox = Mail/
recipient_delimiter = +
inet_interfaces = all

# SASL auth
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous,noplaintext
smtpd_sasl_application_name = smtpd
smtpd_sasl_local_domain = $mydomain
broken_sasl_auth_clients = yes

smtpd_delay_reject = yes
smtpd_helo_required = yes
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

smtpd_recipient_restrictions =
permit_mynetworks,
reject_unlisted_recipient
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
permit_sasl_authenticated,
reject_unauth_destination,
reject_unauth_pipelining,
check_policy_service inet:127.0.0.1:60000,
permit


et mon /etc/postfix/sasl/smtpd.conf :

pwcheck_method: saslauthd
auxprop_plugin: sasldb
saslauthd_path: /var/run/saslauthd/mux
mech_list: PLAIN LOGIN CRAM-MD5 DIGEST-MD5


Merci de votre aide !

--
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
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
mouss
Le #9608261
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
Le #9608241
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
Le #9608251
> 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
Le #9608231
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
Le #9608221
On Sun, Sep 23, 2007 at 04:09:00PM +0200,
Sylvain 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
Le #9608211
> 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 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
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
Sep 23 20:11:35 kimsufi spamd[26474]: prefork: child states: II
Sep 23 20:11:35 kimsufi postfix/local[10448]: 12AE1268F9:
to 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
Le #9608201
[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 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
Le #9608071
On Sun, Sep 23, 2007 at 08:34:52PM +0200,
Sylvain 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
Le #9608041
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


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
Le #9608021
> [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
Publicité
Poster une réponse
Anonyme