5. OBJETS JSON

​

Objet "Stamp" :
 

Le système retourne le résultat du traitement de la requête d’envoi de la campagne dans la section "stamp". Le champ "rfmailno" représente le numéro de référence interne de la campagne par lequel peuvent être effectuées toutes les opérations ultérieures : demande de rapport, de statistiques, reprogrammation, suspension et redémarrage, etc.

​

Objet "Job" :

Pour les messages transactionnels :

Le paramètre "timeout" indique la durée en secondes maximale pendant laquelle le système effectue des essais de transmission, avant de retourner une erreur  451 9.X.Y.
Le paramètre "maxhop" précise de nombre maximal de routes que le système est susceptible d'utiliser pour effectuer ses essais de transmission.

​

Pour les campagnes :

Si "datestart" est non précisée, départ immédiat.
Si "datestop" est non précisée, arrêt de la campagne automatique après le dernier cycle de réessais.

​

Objet "Header" :

Selon les paramètres forced_from_addr, granted_from_addr et default_from_addr, définis dans la configuration du compte utilisateur, l'adresse email d'expéditeur ( { "from" : { "addr" : <email>... ) est susceptible d'être altérée selon les règles suivantes :

​

- si forced_from_addr est défini, il remplace "addr". A noter que l'adresse supporte les wildcards pour la partie nom d'utilisateur de l'adresse, par exemple :

​

"header"  : {  "from" : { "addr" : "info@example.com",… },

"config" : {  "forced_from_addr" : "*@mysender.com",… },…

     =>  From: <info@mysender.com>

​

- si granted_from_addr est défini et contient un ou plusieurs patterns, le système vérifie que l'adresse email matche au moins un des patterns, sinon, rejette la requête.

​

"header"  : {  "from" : { "addr" : "info@example.com",… },

"config" : {  "granted_from_addr" : "*@example.com",… },…

     =>  Ok, "info@example.com" matches "*@example.com"

​

"header"  : {  "from" : { "addr" : "info@example.com",… },

"config" : {  "granted_from_addr" : "*@mysender.com info@*",… },…

     =>  Ok, "info@example.com" matches "info@*"

​

- si default_from_addr est défini et que "addr" n'est pas défini, alors il le remplace. A noter que l'adresse supporte les wildcards pour la partie nom d'utilisateur de l'adresse, par exemple :

​

"header"  : {  "from" : { "addr" : "info",… },

"config" : {  "default_from_addr" : "*@mysender.com",… },…

     =>  From: <info@mysender.com>

​

Deux noms de domaine spéciaux, "@rdns" et "@def", permettent d'indiquer au système d'utiliser respectivement le ReverseDNS de l'IP d'émission, ou le nom de domaine par défaut associé à l'IP d'émission dans la configuration, par exemple :

​

"header"  : {  "from" : { "addr" : "info@rdns",… },

"config" : {  { "ip" : "*@mysender.com", "rdns" : "example.com",… },…

     =>  From: <info@example.com>

​

​

Le champ "unlst" génère un header ‘List-Unsubsribe :’ dans les entêtes des emails envoyés, qui peut contenir deux types de liens : un mailto smtp pour des désabonneents asynchrones (valeur "smtp"), ou http pour un désabonnement synchrone (valeur "http"), ou les deux, à la discrétion du système de réception (valeur "both").

Le jeu de caractère indiqué dans "charset" précise l’encodage de destination des messages (def : "utf-8"). Rappel : les chaines de caractères dans un fichier JSON doivent être au format natif utf-8.
 

Objet "XXXbody" :

Il est nécessaire d’avoir au moins un des trois bodys valides, txt, htm ou amp.

Les bodyparts des sections non déclarées ne sont pas insérées, et n’importe quelle combinaison valide est autorisée : txt brut seul, htm seul, txt/htm, htm/amp, txt/htm/amp.
 

Objet "Recipients" :
 

Pour les messages transactionnels, seule a clef "toaddr" permet de définir l'adresse email du destinataire du message.

​

Dans le contexte d’une campagne, le système utilise la liste des destinataires précisée par la variable "path", et .Pour personnaliser le champ "to" pour chaque destinataire, indiquer une seule entrée dans le "header" :

"to" : [ { "addr" : "$$[record]email$$", "name" : "$$[record]name$$" } ]
 

Si "testaddr" indique au moins une adresse email valide, le système considère que c’est un envoi de test, pour validation sur des emails internes avant envoi aux véritables destinataires finaux.

Afin de s’assurer d’un parfait rendu des personnalisations, le système fusionne les emails avec les données originales de la liste des destinataires (en particulier les champs custom), mais effectue leur remise uniquement sur les adresses email de test. Dans cette configuration, le sujet de l’email est préfixé de "[TEST] ", et les toutes fonctions de désabonnements sont désactivées.

Si "checkaddr" indique au moins une adresse email valide, le système considère que c’est un envoi de vérification du statut des IPs. Son fonctionnement est identique aux emails de test, à la différence près que système effectue l’envoi du message sur chaque destinataire depuis chaque IP spécifiée dans "routing" : "outbound".

Dans la liste des campagnes, le champ "type" indique le type de l'entrée, avec les valeurs :

• ‘T’ : Test

• ‘S’ : Campagne (job multi destinaitaires)

• ‘P’ : Message Transactionnel (job mono destinaitaire)

Objet "Tracking" :

Les paramètres de cet objet sont susceptibles d’être fixés au niveau de la configuration du compte utilisateur, et donc non modifiables au niveau de l’ordre de routage.

Si "domain" n’est pas précisé, le système utilise celui par défaut configuré dans le compte utilisateur (si ce dernier n’est pas précisé, le système utilise le ReverseDNS de l’IP d’émission. Si un domaine est indiqué, un enregistrement de type ‘A’ de sa zone DNS doit pointer vers une des adresses IP en écoute sur le port 80 du serveur.
 

Le champ "open", pour les options de tracking d’ouverture, peut avoir trois valeurs : ‘disable’ : aucun tracking n’est effectué ; ‘pixel’ : le lien vers une image d’1x1 blanche est insérée dans le code body html; ‘image’ : le système effectue une redirection d’URL sur le premier tag <img…> trouvé dans le code du body html.
 

Le champ "mirror" est facultatif, il peut préciser une URL externe pour la page mirroir de l’email envoyé, le système générant nativement des pages mirroirs personnalisées et trackées à la volée à partir du body html.
 

Les champs "unsub" et "uncfm" peuvent préciser des URLs externes pour les pages de désabonnement et de confirmation de désabonnement, mais sont en général fixées dans la configuration du compte utilisateur. Les URLs peuvent également être locale, avec un chemin d’accès relatif au répertoire \wwws de l’application.
 

Objet "Routing" :

 

Les paramètres de cet objet sont susceptibles d’être fixés au niveau de la configuration du compte utilisateur, et donc non modifiables au niveau de l’ordre de routage.

Le champ "envelopefrom" peut contenir trois valeurs spécifiques :

• "@verp" (Variable Envelope Return Path), qui génère une adresse email de bounce unique pour chaque destinataire avec comme domaine le RDNS de l’IP d’émission, utilisée en ‘MAILFROM :’ de la session SMTP

• "@from", c’est-à-dire la valeur indiquée dans "header" : { "from" : "addr" }.

• "@mailfrom", dans le cas du relai SMTP uniquement, la valeur originale de MAIL FROM:<> dans la session

​

Le champ "outbound" permet d’indiquer les ressources d'expédition autorisées pour l'envoi : plages d'adresses IPs publiques enregistrées localement sur le serveur, adresses IPs Cloud (Azure / EC2), statiques ou dynamiques, ou encore un relai SMTP tiers, tel que celui d'un ISP.

 

A noter qu'il est aussi bien possible, pour les IPs Cloud, de spécifier directement les adresses IPs si elles sont connues, que le nom de la @passerelle configurée sur le système à utiliser. Dans ce cas, toutes les IPs virtualisées associées à la @passerelle seront exploitées. 

 

Si "outbound" n’est pas précisé, le système utilise toutes les ressources déclarées comme autorisées dans le compte utilisateur.

​

Selon les paramètres forced_outbound, granted_outbound et default_outbound, définis dans la configuration du compte utilisateur, la route configurée est susceptible d'être altérée selon les règles suivantes :

​

- si forced_outbound est défini, il remplace "outbound" :

​

"routing"  : {  "outbound" : "192.168.0.1-5" },…

"config" : {  "forced_outbound" : "@azure" },…

     =>  "outbound" = "@azure"

​

- si granted_outbound est défini et contient une ou plusieurs plages d'adresses IPs ou nom de @passerelles, le système vérifie que toutes les routes spécifiées dans "outbound" y sont listées.

​

"routing"  : {  "outbound" : "192.168.0.1-5" },…

"config" : {  "granted_outbound" : "192.168.0.1-10 @azure @ec2" },…

     =>  Ok, "192.168.0.1-5" matches "192.168.0.1-10"

​

"routing"  : {  "outbound" : "@ec2" },…

"config" : {  "granted_outbound" : "192.168.0.1-10 @azure @ec2" },…

     =>  Ok, "@ec2" listed

​

- si default_outbound est défini et que "outbound" n'est pas défini, alors il le remplace.

​

"routing"  : {  "envelopefrom" : "@verp",… },

"config" : {  "default_outbound" : "192.168.0.6" },…

     =>  "outbound" = "192.168.0.6"

​

L'objet "Routing" peut être suffixé par un nom de groupe de domaines pour spécifier que les paramètres de remise sont spécifiques à ce groupe.

​