SMTP ou API e-mail : que choisir pour votre application ?

Tôt ou tard, tout produit doit envoyer des e-mails, et la première question est de savoir comment votre code va dialoguer avec le système de messagerie. Il existe deux réponses : parler directement SMTP, ou appeler une API e-mail en HTTPS.

Les deux fonctionnent. Mais elles imposent des contraintes très différentes à votre application, et le bon choix dépend de l’endroit où s’exécute votre code et de la part de plomberie e-mail que vous souhaitez gérer vous-même.

Les points forts de SMTP

SMTP (Simple Mail Transfer Protocol) est le protocole par lequel les serveurs de messagerie s’échangent des e-mails depuis le début des années 1980. Tous les fournisseurs de messagerie le prennent en charge, et presque tous les frameworks intègrent un module d’envoi SMTP : Nodemailer, send_mail de Django, Laravel Mail, Action Mailer de Rails.

Points forts :

• Universel. Tous les comptes e-mail et tous les langages le gèrent.
• Aucune dépendance à un fournisseur. Changez de fournisseur en modifiant un nom d’hôte et un mot de passe.
• Votre propre domaine et votre propre réputation. Les e-mails partent d’un serveur que vous contrôlez ou louez, depuis des adresses de votre domaine.

Les limites de SMTP dans une application

SMTP est un protocole bavard et à états. Pour envoyer un seul message, votre application ouvre une connexion TCP, salue le serveur, passe en TLS, s’authentifie, puis enchaîne une série de commandes et de réponses pour l’expéditeur, le destinataire et les données. Chaque étape est un aller-retour réseau.

En pratique, cela entraîne :

• Des requêtes lentes. La poignée de main avec un serveur éloigné peut prendre des centaines de millisecondes avant même que le message ne commence.
• Des ports bloqués. De nombreuses plateformes cloud et environnements serverless restreignent les ports sortants 25, 465 et 587 pour lutter contre le spam. Le HTTPS sur le port 443 n’est presque jamais bloqué.
• Des identifiants partout. Chaque service qui envoie des e-mails a besoin du mot de passe de la boîte mail. Le changer implique de redéployer tous ces services.
• Peu de visibilité. Quand quelque chose échoue, l’erreur se trouve dans les journaux d’un seul service, si elle a été journalisée.

Ce que change une API e-mail

Une API e-mail encapsule l’envoi dans une seule requête HTTPS avec un corps JSON. Votre code effectue un POST et reçoit un code de statut en retour. Le service d’API gère la connexion SMTP et les identifiants.

Points forts :

• Une seule requête rapide sur le port 443, depuis n’importe où : conteneurs, fonctions serverless, environnements edge, jobs de CI.
• Des clés plutôt que des mots de passe. Chaque service reçoit sa propre clé API aux permissions limitées, et vous pouvez en révoquer ou en renouveler une sans toucher aux autres.
• Une visibilité centralisée. Les appels d’API et les résultats de livraison sont suivis en un seul endroit.
• Des erreurs HTTP simples. Un 401 ou un 429 est bien plus facile à gérer qu’un code de réponse SMTP enfoui dans une stack trace.

Contrepartie : avec la plupart des API e-mail, les messages partent via leurs serveurs : vous adoptez leur configuration de domaine d’envoi et leur réputation d’IP, et en partir plus tard implique de tout revérifier ailleurs.

Inbixio : une API devant votre serveur SMTP

Inbixio repose sur une idée simple : conserver ce que SMTP a de précieux, votre propre serveur de messagerie et votre identité d’expéditeur, et remplacer ce qui pose problème dans les applications.

1. Vous connectez votre serveur SMTP une seule fois dans le tableau de bord : hôte, port, nom d’utilisateur et mot de passe.
2. Vos services appellent POST /api/send-email/ avec une clé API Inbixio.
3. Inbixio s’authentifie sur votre serveur SMTP via TLS et délivre le message depuis votre adresse.
4. Votre tableau de bord affiche le nombre d’envois, le taux d’échec de livraison et la latence de livraison, ainsi qu’un journal de chaque appel d’API.

curl -X POST https://backend.inbixio.com/api/send-email/ \
  -H "X-API-Key: $INBIXIO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"to_email":"user@example.com","subject":"Welcome!","message":"<h1>Hello</h1>"}'

Ce que cela vous apporte :

• Votre mot de passe SMTP est stocké à un seul endroit. Vos services ne voient jamais que des clés API.
• Les clés peuvent être rattachées à un serveur précis : le service de facturation envoie depuis billing@ et le service d’authentification depuis security@.
• Les permissions de chaque clé sont explicites, et une clé peut être renouvelée ou supprimée sans toucher au serveur de messagerie.
• Vous conservez votre domaine d’expédition, votre fournisseur et votre réputation. Si vous changez de fournisseur de messagerie, vous modifiez une seule entrée de serveur, sans changer une ligne de code.

Comparatif

Alors, que choisir ?

• Utilisez SMTP directement pour une petite application unique, sur un serveur où le SMTP sortant est autorisé et où gérer les identifiants ne vous dérange pas.
• Utilisez une API e-mail si vous exploitez plusieurs services, déployez sur des plateformes qui bloquent les ports SMTP, voulez des journaux centralisés, ou ne voulez plus faire circuler des mots de passe de boîte mail.
• Utilisez Inbixio si vous voulez les avantages d’une API tout en continuant à faire passer vos e-mails par votre propre serveur de messagerie et votre propre domaine.

Prêt à essayer ? Le guide de démarrage en cinq minutes vous mène de l’inscription à un e-mail délivré.