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: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.
Reply to: