Re: Postfix et envoi de mails
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=2897, 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.
Reply to: