Product
Gérez les emails entrants comme un pro [API de Mailgun 2.0]
C’est comme un vieil album photo de famille en remontant si loin sur notre blog ! Cet article a été publié pour la première fois en 2011.
L’envoi d’emails était autrefois difficile, mais avec l’outil Mailgun API d’envoi d’emails nous sommes allés au-delà du SMTP et du MIME pour en faire une expérience simple, et j’oserais dire, agréable.

Mais si votre application doit engager des conversations par email, comme c’est souvent le cas avec les applications d’entreprise, l’envoi ne représente même pas la moitié du travail. Imaginons que vous souhaitiez créer un bot basé sur les emails qui s’intègre au flux de travail de votre application d’entreprise. Pensez aux obstacles que vous devriez surmonter :
Problèmes d’acheminement. Les messages entrants doivent d’une manière ou d’une autre atteindre votre application. Cela signifie qu’il doit y avoir un enregistrement MX quelque part qui pointe vers un serveur de messagerie, capable de transférer l’email entrant dans votre code. Il y a de nombreux pièges ici. L’un d’eux est que vous souhaitez probablement générer des rebonds « messagerie non valide » appropriés pour avertir les expéditeurs s’ils ont fait une erreur de frappe dans l’adresse.
Problèmes de gestion du spam. Une fois que vous commencez à accepter des emails pour un domaine MX donné, vous devez vous rendre compte qu’à terme, la plupart des emails entrants seront du spam. Et même si votre politique d’acceptation des emails est basée sur une liste d’autorisation, il n’est pas toujours souhaitable que votre application gère les attaques de spam.
Problèmes d’analyse MIME. Nous en avons déjà parlé, mais l’analyse du format MIME est un exercice douloureux dans la plupart des langages de programmation. Les bibliothèques d’analyse MIME ne sont pas nombreuses et beaucoup d’entre elles souffrent d’une faible tolérance au trafic réel.
Contenu des messages. Vos problèmes d’analyse vont bien au-delà de MIME. La plupart des emails entrants sont généralement des réponses à des messages envoyés précédemment et vous souhaitez généralement supprimer les énormes parties citées. Souvent, il est également souhaitable d’extraire la signature d’une personne du corps d’un message.
Cela semble assez intimidant pour quelque chose d’aussi simple que d’insérer un extrait de texte dans une application. Ne serait-il pas agréable d’avoir quelque chose de similaire à Sinatra ou Flask et de pouvoir dire simplement en Python :
@email_in(".*@myapp.com")rn def incoming_message(message_obj):rn # access various parts of the fully parsed incoming message:rn message_obj.bodyrn message_obj.body_without_quoted_textrn message_obj.sender_signaturern # stuff that matters:rn make_profit_from(message_obj)
Les adeptes de Ruby adorent les blocs. Les adeptes de Ruby adoreraient pouvoir dire :
email_in ".*@myapp.com" do |message_obj|rn # sweet profit-making code...rn end
L’idée derrière ces exemples de code est similaire au mécanisme de routage présent dans les frameworks MVC modernes, mais au lieu d’associer des URL à des actions de contrôleur, nous voulons définir des routes qui associent un modèle d’adresse de destinataire à une fonction de votre code.
Mais comment procédez-vous pour implémenter email_in() compte tenu des difficultés énumérées ci-dessus ?
Les routages Mailgun à la rescousse !
Nous les avons conçus spécifiquement avec ce cas d’utilisation à l’esprit et ils constituent, de loin, le moyen le plus agréable de créer une application de messagerie bidirectionnelle par email. Faites-nous confiance, nous sommes des docteurs en emails ! Mais trêve de bavardages, passons à l’action.
Tout d’abord, définissons une nouvelle route dans le panneau de contrôle Mailgun. Cette route associera l’adresse du destinataire à l’expression régulière « .*@myapp.com », et s’il y a une correspondance, elle fera deux choses :
- Elle analysera le message et l’enverra via POST à l’URL « /emailin » de votre application.
- Elle transférera également la copie du message à la messagerie d’un développeur, par exemple developer@myapp.com

Nous pouvons désormais gérer les messages envoyés à @myapp.com en ajoutant le code suivant dans l’application web :
@app.route("/mailin", methods=["POST"]) rndef mailin(): rn # see if the message is spam:rn is_spam = request.form['X-Mailgun-SFlag'] == 'Yes'rnrn # access some of the email parsed values:rn request.form['From']rn request.form['To']rn request.form['subject']rnrn # stripped text does not include the original (quoted) message, only whatrn # a user has typed:rn request.form['stripped-text']rn request.form['stripped-signature']rnrn # enumerate through all attachments in the message and savern # them to disk with their original filenames:rn for attachment in request.files.values():rn attachment.filenamern data = attachment.stream.read()rn with open(attachment.filename, "w") as f:rn f.write(data)
Gérez les emails entrants comme un pro [API de Mailgun 2.0]
Envoyons un message de test en utilisant Gmail à notre application web et voyons ce qui est envoyé.
Voici la capture d’écran du message tel qu’il apparaît dans GMail. Remarquez qu’il contient le corps réel de ce qui a été écrit (stripped-text), la signature et la partie citée qui, dans la plupart des cas, n’est pas pertinente :

Les données envoyées via POST sont affichées ci-dessous sous la forme d’une requête MultiDict Python extraite. Notez qu’en plus des paramètres synthétiques comme « recipient » ou « stripped-text », Mailgun publie également tous les en-têtes MIME dans l’application, vous avez donc un accès complet à tout :
Paramètres POST (extraits dans le journal sous forme de MultiDict Python)
('From', u'Ev Kontsevoy '),rn('sender', u'ev@mailgunhq.com'),rn('To', u'Awesome Bot '),rn('attachment-count', u'1'),rn('Subject', u'Re: Your application')])rn('stripped-text', u'My application is attached.nThanks.'),rn('stripped-html', u'HTML version of stripped-text'),rn('body-html', u'[full html version of the message]'),rn('body-plain', u'[full text version of the message]'),rn('stripped-signature', u'-- nEv Kontsevoy,nCo-founder and CEO of Mailgun.net - the emailnplatform for developers.'),rn('recipient', u'bot@hello.mailgun.org'),rn('subject', u'Re: Your application'),rn('timestamp', u'1320695889'),rn('signature', u'b8869291bd72f1ad38238429c370cb13a109eab01681a31b1f4a2751df1e3379'),rn('token', u'9ysf1gfmskxxsp1zqwpwrqf2qd4ctdmi5e$k-ajx$x0h846u88'),rn('In-Reply-To', u'Message-Id-of-original-message'),rn('Date', u'Mon, 7 Nov 2011 11:58:06 -0800'),rn('Message-Id', u'message-id-goes-here'),rn('X-Originating-Ip', u'[216.156.80.78]'),rnrn# NOTE: ALL message fields are parsed and pasted. If some fields (like "Cc") arern# missing here it only means they were absent from the message.
Fichiers envoyés via POST :
('attachment-1', FileStorage: 'application.pdg')
Faisons le point. Qu’avons-nous là ?
- Le trafic des emails entrants est comparé à une expression régulière appliquée au destinataire d’un message.
- Les messages correspondants sont analysés, vérifiés pour le spam et envoyés via HTTP POST à l’URL de votre application.
- Les parties citées du message sont séparées (supprimées), la signature est détectée.
- Si votre application est en panne et ne répond pas, les messages seront mis en file d’attente et des tentatives de livraison ultérieures seront effectuées pendant un maximum de 3 jours.
- De plus, les messages correspondants peuvent éventuellement être stockés dans une messagerie à des fins d’archivage, de sauvegarde ou de débogage.
- Aucune de ces complexités n’a plus d’importance pour vous. Vous êtes occupé à écrire du code qui génère de beaux profits.
Et au fait, la manipulation des routes d’emails peut se faire par programmation via une API. Cela vous permet de créer un décorateur magique @email_in() de type Flask/Sinatra qui lierait le tout.
Les routes de Mailgun peuvent faire bien plus qu’une simple correspondance d’adresse de destinataire. Elles prennent en charge les captures d’expressions régulières, le comportement par défaut si aucune autre correspondance n’est trouvée (match-if-nothing-else), elles ont une priorité d’exécution, il s’agit essentiellement d’un langage de programmation de routage d’emails simple.
Et voilà. Tout simplement génial. Maintenant, mettons-nous au travail et débarrassons le monde des stupides emails « no-reply@ ». Il est grand temps.
À bientôt !
—
Les Mailgunners
Mise à jour : n’hésitez pas à participer à la discussion sur HN