Re: Postfix et envoi de mails
[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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Postfix et envoi de mails
On Sun, Sep 23, 2007 at 08:34:52PM +0200, Sylvain [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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, [EMAIL PROTECTED] 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=[EMAIL PROTECTED] c'est rapport au même message (même queueid) Sep 23 20:26:12 kimsufi postfix/qmgr[27015]: 01555268E9: from=[EMAIL PROTECTED], 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 [EMAIL PROTECTED], mais ne jettera pas [EMAIL PROTECTED]). 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 [EMAIL PROTECTED]). 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
Re: Postfix et envoi de mails
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:6, 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:6 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 [EMAIL PROTECTED] sylvain alors il faut s'authentifier en tant que 'sylvain' si on veut utiliser [EMAIL PROTECTED] comme addresse d'expéditeur. si l'adresse n'est pas dans la table, n'importe qui peut l'utiliser. Attention: la
Re: Postfix et envoi de mails
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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Postfix et envoi de mails
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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Postfix et envoi de mails
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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Postfix et envoi de mails
On Sun, Sep 23, 2007 at 04:09:00PM +0200, Sylvain [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Postfix et envoi de mails
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, [EMAIL PROTECTED], [EMAIL PROTECTED] 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=[EMAIL PROTECTED] Sep 23 20:11:35 kimsufi postfix/qmgr[27015]: 12AE1268F9: from=[EMAIL PROTECTED], size=639, 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 [EMAIL PROTECTED] 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,size=764,user=sylar,uid=1000,required_score=5.0,rhost=localhost.localdomain,raddr=127.0.0.1,rport=3758,mid=[EMAIL PROTECTED],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=[EMAIL PROTECTED], 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Postfix et envoi de mails
[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, [EMAIL PROTECTED] Sep 23 20:26:12 kimsufi postfix/cleanup[11327]: 01555268E9: message-id=[EMAIL PROTECTED] Sep 23 20:26:12 kimsufi postfix/qmgr[27015]: 01555268E9: from=[EMAIL PROTECTED], size=2897, 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=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) 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
