Réseau - Web - GNU/Linux

2018 07 février

Relayage avec identification SMTP - Debian 9.0 Stretch

Rédigé par Marc GUILLAUME | 11 commentaires
Article précédent Mail façon FAI - Debian 9.0 Stretch Article suivant

Traduction de la page : https://workaround.org/ispmail/stretch/relaying-smtp-authentication

Relayage

Votre serveur de mail est presque prêt à l'utilisation. Mais il manque une pièce du puzzle. Vos utilisateurs peuvent déjà récupérer leur courrier, mais ils doivent également pouvoir en envoyer. Les serveurs de mail savent comment envoyer un mail vers un autre serveur, en utilisant les enregistrements MX. Les serveurs destinataires vont joyeusement accepter tout mail destiné à un destinataire existant. Mais cependant les clients de messagerie sont supposés envoyer les mails à leur serveur de mail qui lui va les acheminer sur Internet. Quand Postfix reçoit un mail d'un utilisateur et le transmet à un autre, cette opération est appelée « relayage ». Postfix agit en tant que « relais ».

Mais pourquoi les client de messagerie ne fonctionnent-t-ils pas sur le même mode ? Ne peuvent-ils pas se contenter de chercher l'enregistrement MX et envoyer le mail au serveur destinataire ? Techniquement ils pourraient, oui. Mais les utilisateurs sont souvent chez eux, derrière un ligne DSL. Et ces réseaux d'IP sont habituellement bloqués pour l'envoi de mails. Certains FAI bloquent le port SMTP sur leurs routeurs. Et la plupart des serveurs de réception utilisent des « real-time blacklists » (listes noires en temps réel) pour bloquer les IP DSL. La raison en est que de trop nombreux utilisateurs ont chez eux des PC sous Wind*ws infectés par des virus et envoyant du spam.

Je vais trop vite ? D'accord, passons les différents scénarios en revue un à un.

Les mails entrants

Quand quelqu'un envoit un mail à john@example.org un serveur quelque part sur Internet va envoyer, en utilisant SMTP, le mail à votre serveur. Postfix va regarder s'il est responsable de cette adresse dans le domaine example.org et accepter le mail. John peut alors utiliser POP3 ou IMAP pour récupérer le mail sur le serveur.

mail entrant

Les mails sortants (sans identification)

John est quelque part sur Internet et veut envoyer un mail à lisa@example.com. Votre serveur de mail n'est pas responsable du domaine example.com, il reçoit le mail et le transfère (relaye) vers le serveur qui est responsable des adresse de type …@example.com. Cela peut sembler un scénario sans danger, pourtant votre serveur doit interdire ça :

mail sans identification rejeté

Pourquoi ? Parce que n'importe qui peut se faire passer pour John et demander à votre serveur de relayer un mail. Si un attaquant (comme un spammer) voulait envoyer des millions de mails de spam au nom de John via votre serveur, alors les autres responsables de serveur vous accuseraient d'être vous même un spammeur en tant qu'opérateur du serveur ayant acheminé le spam. Votre serveur deviendrait ce qu'on appelle un relais ouvert (« open relay »). Ce n'est pas ce que vous voulez, parce qu'alors votre serveur se retrouverait sur toutes les listes noires et vous ne pourriez envoyer de mail à pratiquement plus aucun autre serveur. Donc sans preuve que John est réellement John votre serveur doit rejeter ses mails.

Courrier électronique sortant (avec identification)

Donc, comment John prouve-t-il son identité ? Il doit utiliser le SMTP identifié (« authenticated SMTP »). C'est semblable au cas précédent mais le programme de courrier électronique de John enverra aussi son nom d'utilisateur et son mot de passe.

mail avec identification accepté

Bien entendu il faut s'assurer que cette identification se fasse via une connexion chiffrée puisqu'elle transmet le mot de passe de John.

Configuration de “mynetworks” Dans Postfix

En plus de l'utilisation de l'identification SMTP vous pouvez dire à Postfix de toujours relayer les mails pour certaines adresses IP. L'option de configuration mynetworks contient la liste des réseaux IP ou des adresses auxquelles vous faites confiance. Généralement c'est là que vous déclarez votre propre réseau local. La raison pour laquelle John doit s'identifier dans l'exemple ci-dessus est parce qu'il n'envoit pas son mail depuis votre réseau local.

Si vos utilisateurs utilisent l'interface webmail tournant sur votre serveur de mail ils n'ont pas besoin de s'identifier. Roundcube envoit les mails à « localhost » qui est considéré comme étant de confiance dans la configuration de mynetworks.

Faites en sorte que Postfix utilise Dovecot pour l'identification

Activer l'identification SMTP dans Postfix est étonnamment facile. Vous avez déjà configuré Dovecot pour l'identification des utilisateurs. Il suffit donc de faire en sorte que Postfix l'utilise en lui disant de demander au serveur Dovecot de vérifier le nom d'utilisateur et le mot de passe. Postfix a juste besoin de quelques configurations supplémentaires. Lancez ces commandes dans le shell :

postconf smtpd_sasl_type=dovecot
postconf smtpd_sasl_path=private/auth
postconf smtpd_sasl_auth_enable=yes

Ceci active l'identification SMTP et dit à Postfix qu'il peut parler à Dovecot via un fichier de socket situé à /var/spool/postfix/private/auth. Vous souvenez-vous que Postfix tourne dans un répertoire transformé en bac à sable avec chroot ? C'est à dire /var/spool/postfix. Pour cela nous avons configuré Dovecot pour qu'il place un socket dans ce répertoire pour pouvoir communiquer avec Postfix.

Activez le chiffrement

La configuration qui suit active le chiffrement, définit la clé et le certificat et oblige à faire passer l'identification par une connexion chiffrée :

postconf smtpd_tls_security_level=may
postconf smtpd_tls_auth_only=yes
postconf smtpd_tls_cert_file=/etc/letsencrypt/live/webmail.example.org/fullchain.pem
postconf smtpd_tls_key_file=/etc/letsencrypt/live/webmail.example.org/privkey.pem

Note 1 : Dans le passé il se peut que vous ayez configuré smtpd_recipient_restrictions pour limiter le relayage aux utilisateurs identifiés. Postfix de nos jours possède une configuration appelée « smtpd_relay_restrictions » qui traite les demandes de relayage dans la phase « RCPT TO » du dialogue SMTP.
En gros il fonctionne comme la restriction smtpd_recipient_restrictions mais est vérifié avant. Et comme cette restriction smtpd_relay_restrictions a une configuration par défaut tout à fait raisonnable, nous n'avons rien à ajouter pour faire fonctionner l'identification pour le relayage.

Note 2 : Postfix 2.10 a modifié le comportement de toutes les restrictions smtpd_*_restrictions. Si une restriction oblige Postfix à rejeter un email, il attendra jusqu'après la ligne RCPT TO. Voyez la documentation de Postifx pour un exposé des raisons de ce changement.

Le paramètre smtpd_tls_security_level est défini à « may » (ndt : c'est à dire possible) pour permettre les connexions chiffrées quand Postfix reçoit un mail. Cela ne s'applique pas seulement aux utilisateurs envoyant des mails, mais aussi aux serveurs de mail distants quand ils vous envoient des mails. Il serait tentant de modifer cela pour mettre « encryt » ce qui forcerait le chiffrement et rejetterait toute tentative de création d'une connexion SMTP non chiffrée. Mais hélas il reste dans le monde des serveurs de mail qui ne peuvent chiffrer et qui, du coup, ne pourraient vous envoyer de mails. Donc « may » est la valeur appropriée.

Bien que des mails puissent toujours vous être envoyés non chiffrés depuis d'autres serveurs il nous faut nous assurer que les utilisateurs, que ce soit par accident ou par ignorance, ne puissent en aucun cas envoyer leurs mots de passe en clair sur Internet. C'est pourquoi nous forçons l'utilisation du chiffrement pour l'identification par smtpd_tls_auth_only=yes. Nous devrions maintenant être tranquilles.

Comment l'identification SMTP fonctionne-t-elle ?

Êtes-vous curieux de voir comment fonctionne l'identification SMTP dans le détail du protocole ? Regardons comment cela se passe. Dans les versions précédentes de ce guide nous utilisions telnet pour nous connecter au port 25 TCP et parler SMTP. Mais maintenant nous forçons l'utlisation du chiffrement et nous ne pouvons réaliser d'identification SMTP non chiffrée. Voyons déjà la première partie en clair :

telnet localhost smtp

Le serveur vous laisse vous connecter :

Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 mail ESMTP Postfix (Debian/GNU)

Envoyez-lui un « hello »

ehlo example.com

Postfix présente une liste des options disponibles durant le dialogue SMTP :

250-mailtest
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

Laissez-moi vous expliquer brièvement ce que signifient ces lignes :

PIPELINING
Il s'agit d'une fonctionnalité destinée à accélérer la connexion SMTP. Normalement un système distant doit attendre une réponse à chaque commande qu'il envoit. Le pipelining autorise le serveur distant à envoyer des paquets de commandes sans attendre la réponse. Postfix va juste mettre ces commandes en attente et les exécuter une à une. Si vous dites à Postfix d'interdire le pipelining il déconnectera le serveur distant quand il essayera d'envoyer des paquets de commandes sans attendre la réponse appropriée. C'est essentiellement une fonction orientée contre les programmes de spam qui ne se comportent pas comme le demande le protocole.
SIZE 10240000
Le serveur est autorisé à envoyer des mails jusqu'à une taille de 10 MB. Cette taille a été pendant longtemps une taille maximale courante. Cependant de nos jours 40 MB ou même davantage sont des tailles courantes parce que les tailles de mails n'ont cessé d'augmenter.
Note du traducteur : dans ce cas, pour par exemple une taille de 40 Mo, il faudrait taper la commande :
postconf -e message_size_limit=40960000
VRFY
Autorise les serveurs distants à vérifier un nom ou une adresse mail. Par exemple le serveur distant pourrait envoyer une commande VRFY john et votre serveur pourrait répondre 250 John Doe <john@example.org>”. Cela sert à vérifier si une adresse mail accepte du courrier.
ETRN
Une commande qu'un serveur distant peut envoyer pour vider la file d'attente de Postfix pour un domaine donné. Elle sert si le système distant a eu des problèmes techniques et n'a pas pu recevoir de mails pendant un assez long délais. A la remise en service il peut lancer une commande ETRN pour demander que votre serveur commence à envoyer les mails en attente pour les domaines qu'il gère. C'est une commande qui n'est pas couramment utilisée.
STARTTLS
Informe le serveur distant qu'il doit passer de sa connexion en clair à une connexion chiffrée lorsqu'il reçoit cette commande STARTTLS. Il commencera alors à négocier une connexion TLS chiffrée. Vous pouvez comparer cela à une connexion HTTP qui soudain bascule sur une connexion chiffrée HTTPS. L'avantage est que vous pouvez initier une connexion en SMTP sur le port 25 TCP et n'avez pas à ouvrir un deuxième port comme 465 qui est le port SSMTP (secure SMTP) qui n'accepte que les connexions chiffrées.
ENHANCEDSTATUSCODES
Ceci active davantage de codes de retour à trois chiffres liés à différentes situations. Voyez la RFC2034 si vous êtes curieux.
8BITMIME
Dans ses débuts SMTP ne traitait que des caractères codés sur 7 octets. Vous ne pouviez transmettre des caractères comme « Ä » ou « ß » sans utiliser un encodage spécial. 8BITMIME autorise la transmission de mails utilisant des caractères codés sur 8 octets. Encore de nos jours de nombreux mails sont spécifiquement encodés en ISO8859-1 ou en UTF-8.
DSN
Active les DSNs (delivery status notifications ou notifications de statut de distribution) qui permettent à l'envoyeur de contrôler les messages que Postfix crée quand un email ne peut être distribué comme prévu.

Cependant il manque ici une ligne importante qui nous autoriserait à envoyer notre nom d'utilisateur et notre mot de passe :

250-AUTH PLAIN LOGIN

Nous avons dit à Postfix de ne permettre l'identification que quand la connexion est chiffrée. C'est pourquoi nous ne proposons pas d'identification lors de cette connexion en clair.

Vous suivez toujours ? C'est bien. Maintenant nous avons besoin d'une connexion chiffrée utilisant TLS. Vous pouvez lancer STARTTLS :

STARTTLS

Et le serveur devrait répondre :

220 2.0.0 Ready to start TLS

Cependant à partir de maintenant les choses se compliquent car il faudrait parler en langage chiffré TLS, qui n'est pas un langage que peuvent parler les humains. Donc arrêtons là en utilisant la commande « QUIT ».

Mais nous pouvons utiliser OpenSSL pour nous aider dans le déchiffrement. Lancez la commande :

openssl s_client -connect localhost:25 -starttls smtp

Vous allez voir beaucoup de lignes s'afficher à l'écran. OpenSSL s'est connecté sur le port 25 TCP et a lancé une commande STARTTLS pour basculer dans une connexion chiffrée. Du coup, tout ce que vous taperez maintenant sera chiffré. Entrez :

ehlo example.com

Postfix va envoyer une liste d'options possibles qui va ressembler à ça :

250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-AUTH PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

Maintenant que nous utilisons une connexion chiffrée Postfix propose une méthode d'identification. Du coup envoyons une chaîne d'identification avec un mot de passe encodé en Base64 :

AUTH PLAIN am9obkBleGFtcGxlLm9yZwBqb2huQGV4YW1wbGUub3JnAHN1bW1lcnN1bg==

Le serveur devrait accepter cette identification :

235 2.7.0 Authentication successful

Parfait. Vous êtes identifié par SMTP. Déconnectez-vous de Postfix :

QUIT

Au revoir :

221 2.0.0 Bye

L'identification fonctionne. Bien joué.

Encodage en Base64 des mots de passe

Vous pouvez vous demander où j'ai pris cette longue chaîne incompréhensible qui apparemment contenait l'adresse mail de John et son mot de passe. C'est juste une version encodée (et non chiffrée) en Base64 de la chaîne :
« john@example.org<NULL-BYTE>john@example.org<NULL-BYTE>summersun ».

Une façon de créer cette chaîne est d'utiliser Perl :

perl -MMIME::Base64 -e \
'print encode_base64("john\@example.org\0john\@example.org\0summersun")';

Une façon plus simple est d'utiliser la commande base64 du shell :

$ echo -n 'john@example.org john@example.org summersun' | base64
am9obkBleGFtcGxlLm9yZyBqb2huQGV4YW1wbGUub3JnIHN1bW1lcnN1bg==

Le port d'envoi

Bien que j'aie toujours mentionné le port 25 comme port SMTP pour relayer les mails il existe une meilleure solution en utilisant le port d'envoi (submission port) sur le port 587 TCP (comme décrit dans la RFC4409). L'idée est d'utiliser le port 25 pour le transport des mails (MTA) de serveur à serveur et le port 587 pour l'envoi de mails (MSA) d'un utilisateur à un serveur. Comme de nombreux utilisateurs utilisent toujours le port SMTP par défaut, il y a de grandes chances pour que vous deviez utiliser les deux ports.

Éditez votre fichier /etc/postfix/master.cf et ajoutez un service pour le port d'envoi comme ceci (n'oubliez pas l'indentation à partir de la deuxième ligne). N'utilisez pas les commandes suggérées en commentaire dans le fichier master.cf, contentez vous de les ignorer.

submission inet n - - - - smtpd
 -o syslog_name=postfix/submission
 -o smtpd_tls_security_level=encrypt
 -o smtpd_sasl_auth_enable=yes
 -o smtpd_sasl_type=dovecot
 -o smtpd_sasl_path=private/auth
 -o smtpd_sasl_security_options=noanonymous
 -o smtpd_sender_login_maps=mysql:/etc/postfix/mysql-email2email.cf
 -o smtpd_sender_restrictions=reject_sender_login_mismatch
 -o smtpd_sasl_local_domain=$myhostname
 -o smtpd_client_restrictions=permit_sasl_authenticated,reject
 -o smtpd_recipient_restrictions=reject_non_fqdn_recipient,reject_unknown_recipient_domain,permit_sasl_authenticated,reject

Essentiellement ce nouveau service utilise le démon smtpd qui est la brique logicielle qui répond si vous ouvrez une connexion SMTP sur le port TCP 25. Mais avec quelques options supplémentaires…

  • Il indique dans le fichier /var/log/mail.log les connexions au port d'envoi sous l'appellation « postfix/submission/smtpd » (syslog) ;
  • rend obligatoire le chiffrement sur ce port (security level) ;
  • rend obligatoire l'authetification (sasl) ;
  • s'assure qu'un utilisateur identifié ne puisse envoyer de mails que sous son propre nom (sender_login_maps).

Redémarrez le serveur Postfix :

service postfix restart

Vos utilisateurs peuvent maintenant utiliser le port d'envoi (submission port) pour envoyer leurs mails.

Protection contre les adresses d'expéditeur contrefaites

Attendez une minute. Nous pouvons nous assurer qu'un utilisateur ne peut envoyer de mails qu'en utilisant sa propre adresse. C'est bien, mais comment cela fonctionne-t-il ? Jetons un oeil sur cette ligne que nous venons d'ajouter lorsque nous avons ajouté le port d'envoi :

smtpd_sender_login_maps=mysql:/etc/postfix/mysql-email2email.cf

L'option smtpd_sender_login_maps est un « mapping » Postfix avec deux colonnes :

  1. L'adresse email que l'utilisateur veut utiliser pour envoyer son mails ;
  2. Le nom d'utilisateur qu'il a utilisé lors de son identification auprès du serveur de mail.

La raison pour laquelle j'utilise le mapping /etc/postfix/mysql-email2email.cf est qu'il convient ici parfaitement. Ce mapping lie l'adresse à elle-même si elle existe. Cela vous trouble ? Regardez la requête SQL qu'utilise le mapping « email2email » :

SELECT email FROM virtual_users WHERE email='%s'

De la sorte, lorsqu'un utilisateur veut faire relayer un mail, Postfix interroge la table virtual_users à la recherche de l'adresse de l'utilisateur. Disons que John veut envoyer un mail depuis son adresse « john@example.org ». Postfix recherchera sans la table virtual_users pour voir si il y a une ligne avec un champ « email » qui contienne cette adresse. Il va en trouver une et récupérer la valeur du champ « email », qui n'est autre, rappelons-le, que l'adresse mail. Postfix s'attend à récupérer comme nom d'utilisateur celui qui a été utilisé pour la connexion. Comme nous utilisons l'adresse email en guise de nom d'utilisateur pour la connexion, ce mapping fonctionne. Si John voulait utiliser une autre adresse d'expéditeur, alors Postfix verrait qu'elle ne correspond pas à ce compte et rejetterait le mail. Votre fichier mail.log comporterait une ligne dans ce genre :

NOQUEUE: reject: RCPT from foo.bar[…]: 553 5.7.1 <forged@email.address>: Sender address rejected: not owned by user john@example.org; from=<forged@email.address> to=<…>

A vous de choisir si vous désirez utiliser l'option smtpd_sender_restrictions de cette façon.

11 commentaires

#1  - joel Denayer a dit :

Pour ma part, a ce stade, j'ai du commenter

# -o smtpd_client_restrictions=permit_sasl_authenticated,reject
# -o smtpd_recipient_restrictions=reject_non_fqdn_recipient,reject_unknown_recipient_domain,pe....

En effet, une fois activé, on ne sais plus envoyer un email d'un compte google sur un email du domaine.

Si quelqu'un a la solution avant moi .... hésitez pas

Répondre
#2  - Marc GUILLAUME a dit :

Ah ? Pourriez-vous donner quelques précisions, vous envoyez depuis l'interface web gmail ou depuis un client de mail ? Quel message d'erreur renvoit gmail ? Ça me semble étonnant.

Répondre
#3  - aimsai a dit :

Alors pour moi arrivé ici tout s'est bien passé, sauf qu'il est impossible de se connecter au SMTP pour envoyer les mails depuis roundcube.
Port 25 ou 587 c'est la même, il m'annonce que le serveur de prend pas en charge l'authentification
Si j'utilise tls:// Alors le message d'erreur est différent, j'ai "Authentication failure: STARTTLS failed"
Ca fonctionne très bien depuis le serveur avec openssl ...
Savez-vous ce qui peut bloquer à ce stade ?

Répondre
#4  - Marc GUILLAUME a dit :

Il faudrait un peu plus de renseignements, avez-vous installé Roundcube sur un autre serveur que celui faisant tourner Postfix ?
Si Roundcube est sur le serveur de mail lui-même, hypothèse prise dans ce document, alors vous devez avoir, dans le fichier /etc/roundcube/config.inc.php, les lignes suivantes :

$config['default_host'] = 'localhost';
$config['smtp_server'] = '';
et
$config['smtp_port'] = 587;
ou
$config['smtp_port'] = 25;

Est-ce bien le cas ?

Répondre
#5  - aimsai a dit :

Alors j'avais pas cette configuration de rouncube alors voilà tout ce que j'ai tenté :
J'ai entièrement réinstallé le serveur.

La configuration proposée dans votre commentaire donne ce message pour le SMTP :
Server localhost
Port 587 ou 25
Username (none)
Password (none)
Trying to send email...
SMTP send: NOT OK(Connection failed: Failed to connect socket: Connection refused)

et pour l'IMAP :
Server localhost
Port 143
Connecting to localhost...
IMAP connect: OK(SORT capability: yes)

J'ai essayé en le connectant comme s'il n'était pas sur le même serveur :
Server smtp.mondomaine.com
Port 587 ou 25
Username (none) ou email
Password (none) ou pass
Trying to send email...
SMTP send: NOT OK(Connection failed: Failed to connect socket: Connection refused)

et pour l'IMAP :
Server imap.mondomaine.com
Port 143
Connecting to imap.mondomaine.com...
IMAP connect: OK(SORT capability: yes)

Ensuite j'ai essayé comme s'il n'était pas sur le serveur, avec le préfixe tls://
Server tls://smtp.mondomaine.com
Port 587 ou 25
Username (none) ou email
Password (none) ou pass
Trying to send email...
SMTP send: NOT OK(Connection failed: Failed to connect socket: Connection refused)

et pour l'IMAP :
Server tls://imap.mondomaine.com
Port 143
Connecting to tls://imap.juprycode.com...
IMAP connect: NOT OK(Login failed for lucas@juprycode.com from X.X.X.X. Unable to negotiate TLS)

Le résultat est le même depuis d'autres clients de messagerie : Je reçois les mails d'où qu'il proviennent, mais impossible d'en envoyer ...

Répondre
#6  - aimsai a dit :

J'ai d'ailleurs consulté la liste des ports sur écoute, et je retrouve bien pop3, imap, pop3s; imaps, sieve mais pas de smtp

Répondre
#7  - AimSai a dit :

Olala, j'ai fais une erreur dans le dernier fichier, c'est pour ça que le smtp n'écoutait pas, donc maintenant j'ai bien le smtp dans netstat -l et les erreurs ont changé. J'ai fais une tonne de tests que voici :

Coté SMTP :
- Hote : localhost, sans authentification, vers email externe au domaine :
* port 25 : SMTP send: NOT OK(Failed to add recipient 'mail@externe.com'. 4.3.0 <mail@externe.com: Temporary lookup failure (Code: 451))
* port 587 : SMTP send: NOT OK(Failed to set sender 'mail@mondomaine.com'. 5.7.0 Must issue a STARTTLS command first (Code: 530))
- Hote : localhost, sans authentification, vers email interne au domaine :
* port 25 : SMTP send: NOT OK(Failed to add recipient 'mail_2@mondomaine.com'. 4.3.0 <mail_2@mondomaine.com>: Temporary lookup failure (Code: 451))
* port 587 : SMTP send: NOT OK(Failed to set sender 'mail@mondomaine.com'. 5.7.0 Must issue a STARTTLS command first (Code: 530))
-----
- Hote : localhost, avec authentification, vers email externe au domaine :
* port 25 : SMTP send: NOT OK(Authentication failure: SMTP server does not support authentication (Code: ))
* port 587 : SMTP send: NOT OK(Authentication failure: SMTP server does not support authentication (Code: ))
- Hote : localhost, avec authentification, vers email interne au domaine :
* port 25 : SMTP send: NOT OK(Authentication failure: SMTP server does not support authentication (Code: ))
* port 587 : SMTP send: NOT OK(Authentication failure: SMTP server does not support authentication (Code: ))
-----
- Hote : tls://localhost, sans authentification, vers email externe au domaine :
* port 25 : SMTP send: NOT OK(Failed to add recipient 'mail@externe.com'. 4.3.0 <mail@externe.com>: Temporary lookup failure (Code: 451))
* port 587 : SMTP send: NOT OK(Failed to set sender 'mail@mondomaine.com'. 5.7.0 Must issue a STARTTLS command first (Code: 530))
- Hote : tls://localhost, sans authentification, vers email interne au domaine :
* port 25 : SMTP send: NOT OK(Failed to add recipient 'mail_2@mondomaine.com'. 4.3.0 <mail_2@mondomaine.com>: Temporary lookup failure (Code: 451))
* port 587 : SMTP send: NOT OK(Failed to set sender 'mail@mondomaine.com'. 5.7.0 Must issue a STARTTLS command first (Code: 530))
-----
- Hote : tls://localhost, avec authentification, vers email externe au domaine :
* port 25 : SMTP send: NOT OK(Authentication failure: STARTTLS failed (Code: ))
* port 587 : SMTP send: NOT OK(Authentication failure: STARTTLS failed (Code: ))
- Hote : tls://localhost, avec authentification, vers email interne au domaine :
* port 25 : SMTP send: NOT OK(Authentication failure: STARTTLS failed (Code: ))
* port 587 : SMTP send: NOT OK(Authentication failure: STARTTLS failed (Code: ))
-----
- Hote : smtp.mondomaine.com, sans authentification, vers email externe au domaine :
* port 25 : SMTP send: NOT OK(Failed to add recipient 'mail@externe.com'. 4.3.0 <mail@externe.com>: Temporary lookup failure (Code: 451))
* port 587 : SMTP send: NOT OK(Failed to set sender 'mail@mondomaine.com'. 5.7.0 Must issue a STARTTLS command first (Code: 530))
- Hote : smtp.mondomaine.com, sans authentification, vers email interne au domaine :
* port 25 : SMTP send: NOT OK(Failed to add recipient 'mail_2@mondomaine.com'. 4.3.0 <mail_2@mondomaine.com>: Temporary lookup failure (Code: 451))
* port 587 : SMTP send: NOT OK(Failed to set sender 'mail@mondomaine.com'. 5.7.0 Must issue a STARTTLS command first (Code: 530))
-----
- Hote : smtp.mondomaine.com, avec authentification, vers email externe au domaine :
* port 25 : SMTP send: NOT OK(Authentication failure: SMTP server does not support authentication (Code: ))
* port 587 : SMTP send: NOT OK(Authentication failure: SMTP server does not support authentication (Code: ))
- Hote : smtp.mondomaine.com, avec authentification, vers email interne au domaine :
* port 25 : SMTP send: NOT OK(Authentication failure: SMTP server does not support authentication (Code: ))
* port 587 : SMTP send: NOT OK(Authentication failure: SMTP server does not support authentication (Code: ))
-----
- Hote : tls://smtp.mondomaine.com, sans authentification, vers email externe au domaine :
* port 25 : SMTP send: NOT OK(Failed to add recipient 'mail@externe.com'. 4.3.0 <mail@externe.com>: Temporary lookup failure (Code: 451))
* port 587 : SMTP send: NOT OK(Failed to set sender 'mail@mondomaine.com'. 5.7.0 Must issue a STARTTLS command first (Code: 530))
- Hote : tls://smtp.mondomaine.com, sans authentification, vers email interne au domaine :
* port 25 : SMTP send: NOT OK(Failed to add recipient 'mail_2@mondomaine.com'. 4.3.0 <mail_2@mondomaine.com>: Temporary lookup failure (Code: 451))
* port 587 : SMTP send: NOT OK(Failed to set sender 'mail@mondomaine.com'. 5.7.0 Must issue a STARTTLS command first (Code: 530))
-----
- Hote : tls://smtp.mondomaine.com, avec authentification, vers email externe au domaine :
* port 25 : SMTP send: NOT OK(Authentication failure: STARTTLS failed (Code: ))
* port 587 : SMTP send: NOT OK(Authentication failure: STARTTLS failed (Code: ))
- Hote : tls://smtp.mondomaine.com, avec authentification, vers email interne au domaine :
* port 25 : SMTP send: NOT OK(Authentication failure: STARTTLS failed (Code: ))
* port 587 : SMTP send: NOT OK(Authentication failure: STARTTLS failed (Code: ))


Coté IMAP :
- Hote : localhost, port 143 : IMAP connect: OK(SORT capability: yes)
- Hote : tls://localhost, port 143 : IMAP connect: NOT OK(Login failed for mail@mondomaine.com from X.X.X.X. Unable to negotiate TLS)
- Hote : imap.mondomaine.com, port 143 : IMAP connect: OK(SORT capability: yes)
- Hote : tls://imap.mondomaine.com, port 143 : IMAP connect: NOT OK(Login failed for mail@mondomaine.com from X.X.X.X. Unable to negotiate TLS)

(l'IP X.X.X.X ne correspond à rien chez moi)

En voyant ces codes erreur on pourrait croire à un problème d'authentification, mais avec openssl voici le résultat :

250 SMTPUTF8
ehlo mondomaine.com
250-vps.......net
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-AUTH PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250 SMTPUTF8
AUTH PLAIN (base64)
235 2.7.0 Authentication successful

J'ai essayé d'autres moyen que roundcube pour me connecter à l'adresse mail :
- Courrier dans Windows
- Mail sur iOS
Dans les deux cas, je reçois une alerte à propos du certificat, et sur iOS l'envoi d'un mail aboutit à un message : "L'adresse du destinataire a été rejetée par le serveur" ce qui correspondrait aux erreurs de Roudcube dans la configuration "sans authentification" port 25...

Répondre
#8  - AimSai a dit :

Bon, j'ai réinstallé encore une fois tout le serveur, et j'ai probablement trouvé ce qui coinçait.
J'utilise PostfixAdmin pour gérer les boites mail, pour ça j'ai adapté les requêtes SQL à la structure de base de données de ce logiciel (je ne peux du coup pas utiliser toutes les fonctions, mais le principal est là : domaines, boites mails, alias).
Les premiers coups j'ai installé PostfixAdmin APRES avoir installé Postfix et Dovecot, et je le soupçonne de modifier quelques réglages dans ces deux derniers logiciels, au moment de son installation. Cette fois, je l'ai installé AVANT. J'exploite toujours sa structure de BDD, mais il n'a pas pu modifier la config de Postfix et Dovecot, parcequ'ils n'étaient tout simplement pas installés. Résultat : je passe enfin cette page, après 3 serveurs complets, j'envoie et je reçois les mails

Répondre
#9  - Constant a dit :

J'ai remarqué les message envoyé à gmail passait en spam pour la raison d'envoi du message non crypté.

Voici la partie TLS de main.cf que j'ai modifié pour les messages envoyé soit encodé :
#TLS
smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3
smtpd_tls_security_level = may
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/letsencrypt/live/webmail.example.org/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/webmail.example.org/privkey.pem
smtpd_tls_CAfile = /etc/letsencrypt/live/webmail.example.org/cert.pem
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
# on active TLS pour les connexions sortantes
smtp_tls_security_level = may
# NB sur un postfix antérieur à 2.3, c'est smtp_use_tls = yes
smtp_tls_key_file = /etc/letsencrypt/live/webmail.example.org/privkey.pem
smtp_tls_cert_file = /etc/letsencrypt/live/webmail.example.org/fullchain.pem
smtp_tls_CAfile = /etc/letsencrypt/live/webmail.example.org/cert.pem
smtp_tls_note_starttls_offer = yes
smtp_tls_enforce_peername = no

Répondre
#10  - Skoll a dit :

Bonjour, tout d'abord bravo pour votre travail !

Après avoir changer le mot de passe, j'ai hasher en base64 avec la commande ci-dessous, mais la sortie n'est pas la même qu'avec la commande Perl.

$ echo -n 'john@example.org john@example.org summersun' | base64

Chez moi le hash ne fonctionne qu'avec Perl.

Répondre
#11  - Marc GUILLAUME a dit :

Bonjour,

d'abord toutes mes excuses pour la réponse tardive mais mon captcha est trop simpliste et je suis assailli de spam et je n'avais pas vu votre message.

Quelle version de Debian avez-vous ? Cette doc commence à être un peu ancienne, et pour l'instant je n'ai pas eu le temps de traduire la version pour Ubuntu 11, mais vous pouvez la trouver sur le site de Christoph Haas https://workaround.org/ispmail/bullseye/

Je n'ai pas votre adresse mail donc je ne sais pas si vous verrez cette réponse, mais on ne sait jamais...

Merci de votre visite.

Répondre

Écrire un commentaire

Quelle est la première lettre du mot rlmf ?

Fil RSS des commentaires de cet article

À propos

Yakati.com - Réseau - Web - GNU/Linux © 2017

Généré par PluXml en 0.054s  Compression GZIP activée - Administration

Mes coordonnées

Marc Guillaume
contact[at]yakati.com
79150 ÉTUSSON

Crédits

Pour la gestion du contenu

Généré par PluXml, le Blog ou Cms sans base de données

Pour le contenu

Licence Creative Commons
Ce(tte) œuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.

Pour le thème

Thème SOLID de blacktie.co adapté pour PluXml