API based
SYNCHRONOUS
SMTP RELAY
1. RELAI SMTP
Dans le contexte du relai SMTP, les emails sont relayés aux serveurs de messagerie distants tels qu'ils ont été reçus. Aucune altération du contenu original (en-têtes comme body parts) n'est effectué. Pour cette raison, le système ne prend pas en charge le tracking dans ce contexte (ouvertures/clics/pages miroir/désabonnements). Seules les signatures ARC et DKIM peuvent être ajoutées aux entêtes.
Il est en revanche possible d'en contrôler précisément les paramètres de routage, via d'entête "X-SMTP-R-API : { { "routing" .... }", cf chap 6.
Nb : cette entête est supprimée par défaut lors de l'acheminement.
Les paramètres d'accès au relai RafaleMTA sont précisées lors de la mise en place de la configuration technique (hôte, port, protocole, encryption, authentification, login/password), ainsi que les valeurs par défaut des paramètres de routage des messages.
Le fonctionnement synchrone du relai permet de délivrer, pendant la session SMTP, le code de retour final du serveur de messagerie distant, selon le schéma suivant :
Cependant, si le système n'a pas pu obtenir un code d'acquittement du serveur distant (ressources outbound insuffisantes dans le délai imparti, impossibilité de connexion au serveur,...) , une erreur spécifique "451 9.X.Y" en indique la raison, selon le tableau ci-dessous :
SMTP Status code
Description
451 9.1.x X-SMTP-R-API <description>
Paramètre JSON invalide
451 9.0.x X-SMTP-R-API <description>
Format de l'email invalide
451 9.2.x X-SMTP-R-API <description>
Adresse email refusée (filtres, blacklistes internes...)
451 9.4.x X-SMTP-R-API <description>
RFU
451 9.5.x X-SMTP-R-API <description>
RFU
451 9.3.x X-SMTP-R-API <description>
Timeout. Aucune route disponible dans le délai imparti.
451 9.6.x X-SMTP-R-API <description>
RFU
A noter que le système n'effectue de fallback de route qu'en cas d'échec de connexion au serveur distant ou de détection de blacklistage. Si les tentatives sont infructueuses ("maxhop" ou "timeout" atteints), le système remonte le message d'erreur de la dernière tentative. En revanche, si un acquittement ou un hardbounce qualifiés est détecté, le système remonte immédiatement le résultat de la transmission.
From: <test@example.com>
To: <example@gmail.com>
Subject: this is a transactionnal message
...
X-SMTP-R-API: {
"message" : {
"ref" : <référence du message (3-30 chars ‘a’-‘z’ ‘0’-‘9’ ‘-‘>,
"title" : <description du message>,
"tags" : [ <liste de mots clefs de recherche>,… ],
"timeout" : <délai maximum de transmission avant réponse 451>,
"maxhop" : <nombre maximum de routes testées pour transmission>
},
"routing" : {
"ehlo" : <nom de domaine utilisé dans le EHLO (@rdns)>,
"envelopefrom": <adresse utilisée dans l’email de MAIL FROM : @mailfrom/@verp/@from>,
"sign" : <flag de signature DKIM : from/envelope/both>,
"ssl" : <flag d’utilisation de STARTTLS : true/false>,
"outbound" : <liste d'IPs et/ou ressources d’émission>
}
}
...