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 [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 ç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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]