↓ Aller au contenu
Ixonae on Security
  1. Articles/

Comment utiliser Postfix pour envoyer des e-mails via Amazon SES

·6 mins
Ixonae
Administration système
Ixonae
Auteur
Ixonae
Sommaire

Avertissement : Cet article a été traduit de l’anglais par un LLM. La précision n’est pas garantie. Vous pouvez lire l’article original en anglais.

Si vous avez déjà géré votre propre serveur de messagerie, vous savez à quel point il peut être pénible de bien configurer le SMTP. Outre la configuration impliquée, beaucoup de choses peuvent mal tourner, comme le fait que votre adresse IP soit mise sur liste noire, que les principaux fournisseurs de messagerie refusent vos e-mails, etc.

Un moyen simple de s’assurer que votre serveur peut envoyer des e-mails sans trop de difficultés ni de maintenance est de configurer Postfix pour router les e-mails via Amazon SES (Simple Email Service). Dans cet article, nous verrons comment configurer ces deux systèmes.

Configuration de SES
#

La première étape est de configurer Amazon SES car nous avons besoin de l’adresse du serveur SMTP et des identifiants. Nous configurerons également les permissions appropriées pour nous assurer que notre utilisateur SMTP n’a pas plus de permissions que nécessaire.

Créer des identités
#

La première étape est d’ajouter le domaine que nous utiliserons pour envoyer des e-mails en tant que nouvelle identité SES. Notez qu’il est aussi possible de simplement ajouter une identité d’adresse e-mail, mais dans ce cas, Amazon ne fournit pas de configuration DKIM, ce qui n’est pas bon pour l’acceptation des e-mails.

  • Allez dans le tableau de bord SES et cliquez sur Verified Identities puis sur Create Identity (assurez-vous de vérifier la région en haut à droite de l’écran si c’est important pour vous)
  • Sélectionnez Domain comme Identity Type et entrez le domaine depuis lequel vous voulez envoyer des e-mails
  • Dans Advanced DKIM Settings, sélectionnez Easy DKIM, RSA_2048_BIT et désactivez Publish DNS records to Route53 si votre domaine n’est pas enregistré avec Route53
  • Vous devriez alors voir le même écran que la capture d’écran suivante. Modifiez vos enregistrements DNS avec les CNAME fournis. N’oubliez pas non plus d’ajouter include:amazonses.com dans votre configuration SPF pour permettre une meilleure livraison (voir mon article précédent sur SPF et DKIM)
Amazon SES -> Configuration: Verified Identities
Amazon SES -> Configuration: Verified Identities -> test.ixonae.com

Une fois toutes les étapes complétées, nous devrions pouvoir envoyer des e-mails en utilisant le domaine.

Identifiants SMTP, utilisateur IAM et permissions
#

Maintenant, créons les identifiants SMTP. Allez dans Amazon SES -> SMTP Settings et notez le SMTP endpoint qui est fourni. Ensuite, cliquez sur Create SMTP Credentials. On vous demandera de choisir un nom pour l’utilisateur IAM qui sera créé. Choisissez quelque chose qui vous aidera à comprendre ce qu’est l’utilisateur, comme ses-noreply-test-domain. Puis, sauvegardez les identifiants SMTP.

Ensuite, nous nous assurerons que notre nouvel utilisateur IAM ne peut envoyer des e-mails que depuis notre domaine (par défaut, l’utilisateur IAM a le droit d’envoyer des e-mails en utilisant n’importe quelle identité de votre compte). Dans les paramètres de l’utilisateur IAM, vous devriez voir une politique inline comme suit :

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "ses:SendRawEmail",
            "Resource": "*"
        }
    ]
}

Nous remplacerons le * par le Amazon Resource Name (ARN) que vous pouvez trouver dans les détails de votre domaine dans Amazon SES/Verified identities. Il devrait ressembler à ceci arn:aws:ses:us-east-1:123455:identity/test.domain.com.

Maintenant, notre utilisateur IAM n’a la permission d’envoyer des e-mails que pour notre domaine nouvellement ajouté. Nous pouvons aller plus loin et ne lui permettre d’envoyer des e-mails qu’en utilisant une adresse spécifique. Dans le panneau Verified Identities de notre domaine (dans SES), allez dans l’onglet Authorization et utilisez le générateur de politique. À partir de là, nous pouvons par exemple dire que nous voulons refuser SendRawEmail pour l’ARN de notre utilisateur IAM si le ses:FromAddress est StringNotEquals à une adresse spécifique.

Notez que plutôt que d’utiliser le générateur de politique dans l’identité du domaine, vous pourriez très bien simplement créer une identité e-mail et donner l’ARN de cette identité comme ressource autorisée dans la politique d’accès de votre utilisateur IAM.

Configuration de Postfix
#

Maintenant que tout est prêt côté AWS, nous pouvons nous connecter en SSH à notre serveur et faire la configuration nécessaire. Notez que ce qui suit fonctionne pour les systèmes de type Debian. Je suppose également que vous n’utilisez pas Postfix pour quoi que ce soit en ce moment. Si c’est le cas, les modifications suivantes pourraient (ou non) casser votre configuration.

Après nous être assurés que sendmail n’est pas installé sur notre système, installons tous les paquets nécessaires.

sudo apt install postfix libsasl2-modules

Ensuite, nous ajouterons la configuration nécessaire avec les commandes suivantes (en tant que root). Vous devrez remplacer email-smtp.us-east-1.amazonaws.com, SMTPUSERNAME et SMTPPASSWORD par les valeurs fournies par SES dans la partie précédente.

postconf -e "relayhost = [email-smtp.us-east-1.amazonaws.com]:587" \
"smtp_sasl_auth_enable = yes" \
"smtp_sasl_security_options = noanonymous" \
"smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd" \
"smtp_use_tls = yes" \
"smtp_tls_security_level = encrypt" \
"smtp_tls_note_starttls_offer = yes"


# Nous configurons les identifiants, compilons la base de données des identifiants, et donnons les bonnes permissions
echo "[email-smtp.us-east-1.amazonaws.com]:587 SMTPUSERNAME:SMTPPASSWORD" > /etc/postfix/sasl_passwd
postmap hash:/etc/postfix/sasl_passwd
chown root: /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.db
chmod 0600 /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.db

# Pour que Postfix puisse valider le certificat du serveur Amazon SES
postconf -e 'smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt'

systemctl restart postfix

Notez que vous pourriez rencontrer les problèmes suivants lors de cette configuration :

  • /etc/postfix/main.cf n’existe pas -> cp /etc/postfix/main.cf.proto /etc/postfix/main.cf
  • postmap: fatal: bad string length 0 < 1: setgid_group = -> commentez la ligne setgid_group dans /etc/postfix/main.cf

Une fois tout cela fait, nous devrions pouvoir tester que les envois se font correctement :

echo "Test Message"| mail -s "Subject" -a "From:me@test.domain.tld" recipient@domain.tld

Si le mail n’est pas livré, vous pouvez consulter /var/log/mail.log. Dans le cas où vous avez un problème avec un enregistrement AAAA non trouvé, vous pouvez ajouter inet_protocols = ipv4 au fichier de configuration main.cf.

Relais multiples et problèmes potentiels de livraison de courrier local
#

La configuration suivante vous permet de router plusieurs domaines à travers différents relais.

Si vous avez suivi les étapes précédentes, il est aussi possible que le système ne soit pas capable de livrer les e-mails locaux à votre système (par exemple à root@myhostname.localdomain lorsqu’un problème de cron survient). La configuration suivante permettra également de corriger cela.

Modifions légèrement notre configuration pour corriger cela. Dans le fichier de configuration main.cf, nous commenterons la ligne commençant par relayhost = et ajouterons les deux lignes suivantes :

sender_dependent_relayhost_maps = hash:/etc/postfix/relayhost_map
smtp_sender_dependent_authentication = yes

Ensuite, nous éditerons relayhost_map et ajouterons les informations suivantes (que nous avons commentées dans main.cf). Cela permettra à Postfix de savoir quels domaines il doit router à travers les relais.

@my-domain.tld [email-smtp.us-east-1.amazonaws.com]:587
# N'était pas dans le fichier précédent, mais nous pouvons faire cela
@my-domain2.tld [email-smtp.us-east-1.amazonaws.com]:587

Nous exécutons ensuite les commandes suivantes pour mettre à jour la base de données, et le problème ne devrait plus se poser.

# Nous mettons à jour la base de données avec la configuration précédente
postmap hash:/etc/postfix/relayhost_map
# Au cas où les logs se plaignent de l'absence de /etc/aliases.db
newaliases
# C'est terminé
systemctl restart postfix

Ressources
#

Crédits
#