// comment corriger
Postfix « 553 5.7.1 Sender address rejected: not owned by user » : la solution
Postfix refuse votre adresse From avec 553 5.7.1 not owned by user ou not logged in ? Corrigez smtpd_sender_login_maps ou envoyez avec le bon identifiant.
Ce que ça veut dire
Votre serveur Postfix vérifie que la personne connectée a le droit d'envoyer avec l'adresse d'expéditeur qu'elle utilise. Quand ce n'est pas le cas, il refuse le message :
553 5.7.1 <info@yourdomain.com>: Sender address rejected: not owned by user john@yourdomain.com
Un message voisin apparaît quand quelqu'un utilise l'une de vos adresses sans s'être connecté du tout :
553 5.7.1 <info@yourdomain.com>: Sender address rejected: not logged in
C'est une protection, pas un bug : elle empêche un utilisateur (ou un mot de passe volé) d'envoyer au nom d'une autre personne. La solution consiste à indiquer à Postfix qui peut utiliser quelle adresse, ou à envoyer avec le bon compte.
Pourquoi cela arrive
Le contrôle vient de la restriction reject_sender_login_mismatch (ou de ses variantes reject_authenticated_sender_login_mismatch et reject_known_sender_login_mismatch). Elle compare deux choses :
- l'expéditeur de l'enveloppe (l'adresse
MAIL FROMdonnée par le programme d'envoi, qui n'est pas toujours l'en-tête From visible), et - l'identifiant utilisé pour l'authentification SMTP.
Postfix cherche l'expéditeur dans la table définie par smtpd_sender_login_maps. Si l'identifiant n'y figure pas comme propriétaire, il refuse. Situations typiques :
- Un utilisateur envoie depuis une adresse partagée ou un alias (
info@,sales@) qui n'est pas associé à son identifiant. - Un site web, une imprimante ou un script se connecte avec un compte mais envoie avec une autre adresse.
- L'identifiant est
johnmais la table indiquejohn@yourdomain.com(ou l'inverse). - La table a été modifiée mais
postmapn'a pas été lancé : Postfix lit donc toujours l'ancienne version. - Une application définit un expéditeur d'enveloppe (adresse de retour) différent de l'adresse From.
Comment vérifier
- Lisez le journal du serveur mail pour voir l'expéditeur et l'identifiant exacts :
grep "not owned by user" /var/log/mail.log | tail
- Affichez les réglages actifs :
postconf smtpd_sender_login_maps smtpd_sender_restrictions postconf -M submission/inet
La seconde commande affiche les surcharges-odu service submission (port 587) dansmaster.cf, où cette restriction est souvent définie. - Interrogez directement la table :
postmap -q info@yourdomain.com hash:/etc/postfix/sender_login
La commande affiche les identifiants autorisés pour cette adresse, ou rien. - Reproduisez le problème avec swaks :
swaks --server mail.yourdomain.com:587 --tls \ --auth LOGIN --auth-user john@yourdomain.com \ --from info@yourdomain.com --to you@example.com
Comment corriger
Autorisez l'identifiant à utiliser l'adresse
Modifiez la table des identifiants d'expéditeur, avec un expéditeur par ligne suivi des identifiants autorisés, séparés par des virgules :
# /etc/postfix/sender_login john@yourdomain.com john@yourdomain.com info@yourdomain.com john@yourdomain.com, mary@yourdomain.com @yourdomain.com admin@yourdomain.com
La dernière ligne permet à admin@yourdomain.com d'envoyer avec n'importe quelle adresse du domaine ; utilisez-la avec prudence. Reconstruisez ensuite la table et rechargez :
postmap /etc/postfix/sender_login systemctl reload postfix
Vérifiez que main.cf pointe bien vers elle :
smtpd_sender_login_maps = hash:/etc/postfix/sender_login
Si vos utilisateurs sont dans une base de données (MySQL, PostgreSQL, LDAP), la table est une requête ; ajoutez plutôt l'autorisation d'alias à cet endroit. Les panneaux de contrôle et les solutions de serveur mail tout-en-un proposent généralement cela sous forme d'autorisation « send as » (envoyer en tant que) ou d'alias pour chaque boîte.
Ou connectez-vous avec le bon compte
Pour un site web ou un appareil, le plus simple est souvent de se connecter avec le compte propriétaire de l'adresse, ou de créer une boîte pour l'adresse utilisée comme expéditeur.
Corrigez l'expéditeur d'enveloppe des applications
Si le From visible est correct mais que le journal affiche un autre expéditeur, c'est que l'application définit un expéditeur d'enveloppe différent. Réglez-le sur une adresse dont l'identifiant est propriétaire (pour PHPMailer, $mail->Sender ; pour nodemailer, l'option envelope). Voir Return-Path, expéditeur d'enveloppe et From.
Ne supprimez pas simplement la restriction
Retirer reject_sender_login_mismatch fait disparaître l'erreur, mais permet à n'importe quel utilisateur d'envoyer au nom de n'importe qui. N'utilisez pas non plus l'adresse des visiteurs comme expéditeur dans les formulaires de contact (voir les emails de formulaire de contact envoyés « From » le visiteur). Si l'erreur est plutôt « Relay access denied », voir 554 5.7.1 Relay access denied.
Vérifiez que c'est corrigé
Relancez la même commande swaks : elle doit se terminer par 250 2.0.0 Ok: queued. Envoyez ensuite depuis la vraie application ou le vrai logiciel de messagerie vers l'adresse unique affichée sur la page d'accueil de Delivmail, et vérifiez dans le rapport que le SPF, le DKIM et le DMARC passent pour l'adresse d'expéditeur. Enfin, renvoyez le message qui avait été refusé.
Vérifiez que c'est corrigé
Une modification DNS peut prendre de quelques minutes à quelques heures. Ensuite, envoyez un nouvel email de test ou scannez à nouveau votre domaine.
Fiches liées
- Erreur Gmail « 550 5.7.26 » : email non authentifiéGmail a refusé votre email parce qu'il n'a pas pu confirmer qu'il vient de votre domaine. Le SPF, le DKIM ou le DMARC est absent ou en échec. Voici comment corriger.
- Erreur « 550 5.7.1 » : message refusé ou bloqué par une règleUne erreur 5.7.1 signifie que le serveur de réception a refusé votre email volontairement. Apprenez à lire les messages d'erreur, à trouver la vraie raison et à la corriger.
- Taux de rebond élevé : nettoyez votre liste de diffusionEnvoyer à des adresses qui n'existent plus abîme vite votre réputation. Apprenez la différence entre hard bounces et soft bounces, et retirez les mauvaises adresses après chaque envoi.
- Emails retardés : greylisting et erreurs temporaires 4xxCertains serveurs répondent « réessayez plus tard » volontairement. Un serveur de messagerie normal réessaie et l'email arrive quelques minutes en retard. Voici comment distinguer les retards normaux des vrais problèmes.
- Gérer votre propre serveur mail : la checklist de délivrabilitéUn serveur Postfix auto-hébergé peut très bien délivrer, mais seulement si toutes les bases sont en place : reverse DNS, SPF, DKIM, DMARC, TLS et aucun relais ouvert.