API d’envoi et de réception d’emails

Pour un projet sur lequel je travaille actuellement (dont j’espère vous parler un de ces jours), j’ai été amené à rechercher des services permettant d’envoyer et de recevoir des emails à travers une interface de programmation déportée. Je vais vous résumer cela, ça pourrait vous être utile.

La problématique

L’envoi de courriers électronique est quelque chose de simple, à la base. En PHP, la fonction mail() est là pour ça. Pour peu que vous utilisiez un hébergement ou un serveur dédié offrant un serveur SMTP (ou une passerelle vers un serveur SMTP), ça fonctionne à peu près bien.

Quand on commence à faire des envois massifs, on tombe rapidement sur deux écueils : On veut s’assurer que les messages sont bien reçus, et on veut des fonctionnalités de gestion des envois.
Concernant la « délivrabilité » (barbarisme dérivé du mot anglais deliverability), il existe des techniques à appliquer côté serveur pour réduire le risque d’être vu comme un spammeur : SPF, DKIM. Mais elles ne sont pas forcément simples à mettre en place ; SPF est accessible tant qu’on sait modifier son DNS, mais DKIM repose sur de l’encryption et est plus délicat à mettre en œuvre. Dans tous les cas, il est important de pouvoir récupérer des statistiques détaillées concernant le nombre de messages qui ont été rejetés par le serveur de destination, ceux qui ont occasionné un retour à l’expéditeur (le fameux NPAI), et idéalement les plaintes déposées suite à un envoi.
Les fonctionnalités supplémentaires sont habituellement des outils de gestion de newsletters (usage premier des envois massifs d’emails), permettant de programmer des campagnes de mailing en ciblant les destinataires à partir de critères. Les services qui intègrent ces outils permettent d’éviter l’installation d’un équivalent côté client.

Pour la réception d’emails, c’est légèrement plus compliqué. Il faut installer un serveur SMTP et y ajouter un serveur POP ou IMAP pour accéder aux messages reçus. Pour peu que vous passiez par un hébergeur, il n’y a plus aucune difficulté technique. Par contre, il faut ensuite coder les programmes qui vont parcourir les boîtes aux lettres électroniques, à la recherche de nouveaux messages. Ce n’est pas forcément le plus évident à mettre en place.
Les services qui proposent des API de réception offrent un fonctionnement évènementiel. Dès qu’un message est reçu, son contenu est transmis par HTTP sur une URL vous appartenant.

Les services d’envoi

Il existe pléthore de services d’envois d’emails : Amazon SES (Simple Email Service), MailChimp, SendGrid, Postmark, ConstantContact, CampaignMonitor, letterPOP, SynergyMail, EmailBrain, Mailigen, BenchmarkEmail, DirectIQ, MailgunActiveCampaign, EmailVision, …

À vous de voir en fonction de vos besoins. Mon expérience est que les services qui intègrent beaucoup de fonctionnalités de gestion (comme EmailVision par exemple) sont très appréciés des marketeux, alors que les informaticiens ont tendance à préférer les outils plus légers et directs comme Amazon SES. Si vous hésitez entre ces deux approches, jetez un œil à MailChimp.

Les services de réception

Il existe beaucoup moins de services de réception : SendGridMailgun, Cloudmailin, APInbox, Context.IO, EmailYak.

Ce sont les seuls que j’ai trouvé ; peut-être en existe-t-il d’autres, signalez-moi ceux que vous connaissez en commentaire. SendGrid, Mailgun et EmailYak sont des services hybrides, qui proposent aussi bien l’envoi que la réception d’emails ; dans le cas de SendGrid, le service de réception ne vient qu’en complément à leur service d’envoi (il est possible d’avoir l’envoi sans la réception, mais pas l’inverse).

Les services proposés se ressemblent énormément dans leur fonctionnement. Il faut par contre faire attention aux détails : Possibilité d’utiliser un nom domaine personnel (et à quel prix), nombre de messages traités, mise en place de SPF et DKIM personnalisés, …

Tous ces services proposent une offre gratuite, là encore avec de grandes disparités : certains traitent 200 messages par mois, là où d’autres en traitent 200 par jour ; certains fonctionnent par redirection, alors que d’autres nécessitent que vous modifiiez vos enregistrements DNS ; certains ne gèrent pas les pièces-jointes dans leur offre gratuite.

APInbox semble sympa, mais il est toujours en beta (et impossible de s’y inscrire en ce moment).

Mon avis

Pour le moment, j’expérimente Mailgun, qui semble pas mal pour l’expédition aussi bien que pour la réception. Pour un service brut d’expédition, j’avoue être assez séduit par Amazon SES.

Avez-vous déjà essayé ces services ? Je suis ouvert aux retours d’expérience à ce sujet.

15 commentaires pour “API d’envoi et de réception d’emails

  1. Ce n’est pas à proprement parlé une API mais Google Apps permet d’envoyer et de recevoir des emails assez efficacement.

  2. Bonjour,

    J’ai une petite question :

    Le problème de l’envoie des mails, c’est qu’on ne peux jamais être sur que son correspondant l’a bien reçu. C’est bien beau de savoir que le serveur à répondu « non », mais quand est-il si le courrier passe directement dans les spams de l’utilisateur ?

    Est-ce que SPF et DKIM permettent d’éviter ce problème ?

    > L’envoi de courriers électronique est quelque chose de simple, à la base.

    Pour avoir pas mal bossé dessus, je peux te dire que c’est quelque chose de très complexe 🙂

  3. Bonjour
    J’ai personnellement regardé du côté de MailJet qui est une société française dont on entend beaucoup parlé ces derniers temps … pour l’envoi. Ca à l’air assez simple.
    Merci en tout cas pour cette liste plus complète.
    K.

  4. @desfrenes : Oui, mais il n’y a pas d’API (à ce que je sache), et c’est justement ce dont j’ai besoin. Si c’est pour parcourir une boîte IMAP pour trouver les nouveaux messages…

    @Eric : SPF et DKIM servent à réduire le risque de tomber dans les spams, en prouvant qu’on est bien l’expéditeur légitime du message. Mais ensuite, on peut toujours se heurter aux filtres bayésiens, qui peuvent considérer qu’un message est un spam à partir de son contenu.

    Je sais bien que la messagerie électronique est un sujet qui est devenu complexe (notamment à cause des spammeurs). Mais si tu regardes le protocole SMTP, c’est censé être simple. Si tu utilises la fonction mail() de PHP pour faire de l’envoi de texte brut, sans faire de l’envoi massif, à des destinataires légitimes, ça reste simple.

  5. @amaury: ce n’est sans doute pas exactement ce que tu cherches mais toutes les boites gmail (et google apps) ont un feed atom sur la boite de réception (auth basic sur ssl) : https://mail.google.com/mail/feed/atom
    Il est donc très simple de connaitre les nouveaux messages.

    Ici on utilise GApps pour les envois de mails « normaux » et Mailchimp (dont l’API est bien faite et relativement transparente grâce au client PHP fourni) pour les envois massifs (mail marketing, etc.). Ça fonctionne pas mal comme ça et on évite les problèmes de spam sans aucun effort.

  6. @kalooni : Effectivement, j’avais vu passer MailJet sur mon radar, mais je ne sais pas pourquoi je l’ai zappé. Je vais regarder ça.

    @desfrenes : Intéressant. Merci pour ce retour. 🙂
    Bon, le problème avec un flux RSS, c’est qu’il faut se souvenir des messages qui ont déjà été traités (sauf s’ils sont effacés de la boîte au fur et à mesure qu’ils sont traités, c’est aussi une possibilité). J’ai quand même tendance à préférer un traitement évènementiel. Mais c’est à étudier.

  7. @David : Parce que la question n’est pas là. Qu’il s’agisse de la fonction mail(), de Zend_Mail, ou d’autres solutions du même type, cela ne répond qu’à une fraction du problème. En amont, il y a la création des newsletters et la gestion des utilisateurs (abonnements aux newsletters, désabonnement), et la préparation serveur pour améliorer la déliverabilité (SPF, DKIM). En aval, il y a la réception et le traitement des erreurs (NPAI, serveur destinataire indisponible), les statistiques sur le taux d’ouverture des messages, la gestion des liens «si vous n’arrivez pas à lire ce message, cliquez ici», …

    Donc ce n’est pas si simple. Il suffit d’aller voir les fonctionnalités proposées par MailChimp et les autres, pour se rendre compte qu’il ne s’agit pas simplement de balancer du texte sur un serveur SMTP.

  8. Merci pour toutes ces recherches des différents outils, je me demandais
    lequels utiliser mais « mailchimp » revient souvent ,faudra que j’aille faire un tour du côté de Gapps et amazonSES aussi.
    Effectivmeent je trouve que envoyer un courrier életronique avec la fonction mail() de php reste simple . J’ai été amené à developper un sytème de newsletter + tracking mais il est vrai que la parti configuration du serveur n’est pas forcément évidente . Lorsque l’on a la main sur le serveur de mail , on peux voir la file d’attente de nos mails en direct, ceux qui partent et ceux qui nous reviennent en pleine figure (les bounces) . Zend Framework permet par exemple de tester un mail avant l’envoi pour voir si celui-ci existe (ça ne marche pas très bien d’ailleurs) . Je pense également que derrière ces appli web d’envoi de mail ce n’est pas 1 serveur mais un cluster (ou grappes de serveurs) car je me suis déjà vu mettre plusieurs heures pour envoyer entre 10 000 et 15 000 mails et vu le nombre de personne qui l’utilise ces services, si tu fais une campagne d’emailing et que ça arrive 2 jours plus tard,
    c’est quand même déroutant.

  9. En ce qui concerne un service à réception de messages, pourquoi ne pas mettre en place son propre service ?

    Je ne sais pas si j’ai bien compris l’objectif, mais configurer une nouvelle méthode dans Postfix se fait plutôt aisément et permet de gérer de manière assez souple – et gratuite – ce qu’on veut, dont les pièces jointes.

  10. @Adrien : Même en étant un développeur efficace, combien de temps ça peut prendre de développer un truc comme ça ? Extraire correctement les pièces-jointes, par exemple, peut sembler simple mais peut se révéler être un casse-tête quand on commence à tester des messages envoyés par des logiciels de messagerie exotiques. En plus, pour être certain de ne pas perdre de messages, il faut préparer plusieurs serveurs et les administrer. Et si tu veux gérer le spam, il faut avoir un serveur SMTP qui vérifie le SPF et/ou le DKIM de l’expéditeur. Ou encore installer SpamAssassin (et l’administrer).

    Bref, ça commence quand même à ne pas être une si mince affaire. Alors si tu compares ça avec un service qui coûte moins cher que la location de serveurs, sans compter le temps de développement (là, tu t’inscris, tu l’utilises)… le choix est vite fait.

  11. Il y a de bonnes bibliothèques (Perl, Python…) qui se chargent d’extraire efficacement les PJ : prise en compte de l’encodage, etc. Cela doit même fonctionner avec le comportement exotique d’Exchange (si tu pensais à lui).

    En terme de développement pur, je pense qu’il ne faut guère plus d’une journée (c’est le temps qu’il a fallu à un collègue non-développeur pour réaliser un outil correct de ce genre en Python, avec logging et configuration).

    L’effort se situe ensuite sur l’administration des serveurs Postfix (failover, stratégies, etc.) qui peut se retrouver redoutable.

  12. Bonjour,

    Dans le cadre de notre nouveau projet, nous utilisons les services Amazon SES. Notre application tournant sur leurs services Cloud, cela facilite pas mal de chose.

    Il faut s’avoir que le service d’Amazon SES ne sert que de point de relais. Il ne s’agit donc pas d’une solution complète d’envois de mail. Nous avons lié le serveur postfix à nos instances, afin d’envoyer le mail via SES.

    Il y a plusieurs limitations pour l’instant.
    • Il faut valider chaque adresse émettrice (accessible depuis l’interface web depuis peu).
    • L’envoi de mail est limité à 1/secondes au lancement de son compte
    • L’envoi est dans un premier temps limiter à 1000/jours (extensible progressivement ou après accord)
    • Certaines pièces jointes ne sont pas encore prise en charge (rar,zip,…)

    Les statistiques fournies restent communes aux stats de serveurs SMTP (Bounce, Delivries, Rejects, Complaints)

    Le but d’ Amazon SES n’est donc pas de servir « d’application » d’envoi de mail, mais bien de relais, robuste est « scalable ». Une sorte de mega serveur SMTP.
    On est bien loin des solutions toutes intégrées dont vous parlez dans cet article.
    Mais comme une partie de notre application est basée sur l’envois de communications personnalisées par sms, fax, pdf ou email ce service nous satisfait entièrement. Comme l’ensemble des services Amazon.

    Cordialement,

    Arnaud

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Notifiez-moi des commentaires à venir via email. Vous pouvez aussi vous abonner sans commenter.