Rafale.IO Configuration 10.9 (FR)

INTRODUCTION

Rafale.exe est l’unique programme exécutable du système. Il ne requiert aucun composant additionnel de type library, dll, package, services, etc, en dehors du système d’exploitation.


Il tourne sur toutes les versions bits de Microsoft Windows, client et serveur, à partir de Windows 7 et Windows Server 2003 (toutes éditions), et consomme 2Go de ram au maximum une fois lancé.


Il n’effectue aucune inscription dans la Registry, ce qui le rend très facilement sauvegardable et transposable d’une machine à une autre.


Le programme est conçu pour n’avoir besoin d’aucun outil tiers pour sa configuration et son administration, en dehors d’un simple éditeur de texte. C’est pourquoi les bases de données internes sont au format texte de longueur fixe, les logs au format .csv et les paramètres de configuration au format .ini, dont l’édition manuelle est plus souple que JSON, pour un gain de performance x2 en mémoire et 7x en vitesse de lecture/écriture. 


Dans le contexte de cette API, le niveau d’encapsulation des objets n’est pas d’une profondeur rédhibitoire à leur linéarisation.  L’API REST permet néanmoins la lecture et l’écriture de tous les paramètres au format JSON.


NB1 : ce document est complémentaire de « Rafale.IO – API 1.9 » dont la connaissance préalable est indispensable.


NB2 : les exemples de configurations dans ce document sont donnés pour une installation sur D:\Rafale\, répertoire de spool utilisateur D:\RfSpool, et utilisent 4 adresses IP (5.196.198.240-243) et 2 domaines de sender (newsletter.rafale.io et service.rafale.io).

1. INSTALLATION

Rafale est livré sous forme d’une archive, <Rafale.zip>, qui est à décompresser depuis la racine d’une partition (ici, pour l’exemple, <D:> ).

NB : le système est livré avec des exemples de groupes de domaines (Aol, Gmail, Hotmail et Yahoo), un compte de démonstration ‘demo’, et des pages standards de désinscription.


Quelques étapes de configuration sont nécessaires avant le premier lancement du logiciel :
(Rappel : données d’exemple = plage de 4 IP 5.196.198.240-243 et 2 senders newsletter.rafale.io et service.rafale.io)


1) Déclarer les adresses IP publiques du serveur dans sa configuration réseau. Cette opération peut s’effectuer soit depuis le Centre Réseau et partage, soit à l’aide de la commande Shell « FOR /L %%I IN (240,1,243) DO netsh interface ip add address "Ethernet" 5.196.198.%%I 255.255.255.255 »

2) Autoriser, dans le pare-feu Windows, le programme <D:\Rafale\rafale.exe> pour les connexions sortantes (sur le port 25, pour l’émission des emails), et les connexions entrantes (sur les ports 25 et 465 pour le relai SMTP, ainsi que 80 et 443, pour le tracking et les statistiques en ligne). 
 

3) Editer le fichier <D:\Rafale\rafale.key> avec Notepad et y copier le numéro de série du produit (32 caractères alphanumériques).

4) Configurer <D:\Rafale\rafale.ini> selon les spécifications des sections suivantes.


5) Enregistrer un raccourci de <D:\Rafale\rafale.exe> dans :
%ALLUSERSPROFILE%\Microsoft\Windows\Start Menu\Programs\Startup
 

2. CONFIGURATION GENERALE
 

2.1. Architecture
 

Rafale est composé de 5 modules principaux, qui communiquent entre eux via une file d’attente mémoire haute performance :

 

  • RfUser traite les commandes utilisateur (cf. document « Rafale – API 10.9 »), importe les jobs, et en exporte les rapports et statistiques.

  • RfMail injecte les jessages des jobs dans la file d’attente du MTA, et consolide les journaux de job et les statistiques temps réel.

  • RfMta assure la fusion/personnalisation et la signature des emails, et transmet les messages aux serveurs de destination en gérant la délivrabilité.

  • RfTrack répond aux requêtes HTTP de tracking des emails (ouvertures, clics, désabonnements…).

  • RfRelay gère les communications SMTP entrantes, pour la fonction relai ainsi que pour les messages de retour (réponses aux emails reçus, Challenge-Response, FeedBackLoop, etc).

2.2. Fichier de configuration <rafale.ini>


Une étape essentielle dans la configuration du système est la déclaration des adresses IP dédiées au routage.


A chaque adresse IP doit être obligatoirement associé un nom de domaine.


Si les adresses IP sont dédiées à un seul sender, indiquer directement le sender qui sera utilisé sur ces adresses IP. De cette façon, tous les emails qui seront émis depuis cette IP utiliseront automatiquement ce nom de domaine pour les adresses d’expéditeur et les liens de tracking du message.


Dans le cas contraire, indiquer un nom générique, par exemple, mtaXX.rafale.io. Les jobs routés depuis ces adresses IP devront dans ce cas spécifier un domaine de sender à utiliser).
 

Ci-dessous un exemple de fichier de configuration :
 

<rafale.ini>

[IP]
X.Y.Z.P           = Liste des IPs publiques à utiliser pour le routage, et leur ReverseDNS associé.

 

[rafale]    
mailsize          = Nombre maximum de jobs à router en simultané (10000)
mailage           = Durée en jour de bufferisation après fin du job (7)
qmsize            = Nombre d’enregistrements maximum de la file d’attente (100000)
qmmemo            = Taille en Ko des champs BLOB de la file d’attente (16)
apikey            = Apikey globale d’accès à l’API HTTP

 

[rfuser]
spool             = Répertoire principal de spool des utilisateurs (%:\RfSpool\)

 

[rfmail]
flush             = Délai (en seconde) de mise à jour des statistiques temps réel (300)

 

[rfmta]
threadnb          = Nombre maximum d’envois d’emails simultanés (128)

 

[rftrack]
threadnb          = Nombre maximum de sessions HTTP simultanées (64)
listen            = Liste des IP:ports d’écoute. Si le port n’est pas précisé, valeur :80

                    (0.0.0.0 0.0.0.0:443)
 

[rfrelay]
threadnb          = Nombre maximum de sessions SMTP simultanées (32)
listen            = Liste des IP:ports d’écoute. Si le port n’est pas précisé, valeur :25

                    (0.0.0.0 0.0.0.0:465)
dmarcaddr         = Liste des adresses email (sans domaine) affectées à la réception des

                    rapports DMARC (cf Sender : zones DNS)
fbladdr           = Liste des adresses email (sans domaine) affectées à la réception des

                    rapports de FeedBackLoop (cf Sender : zones DNS)
challengepattern  = Chaînes de caractères double-quotées, qui, si présentes dans l’email reçu,

                    qualifient le message en Challenge
softpattern       = Chaînes de caractères double-quotées, qui, si présentes dans l’email reçu,

                    qualifient le message en Soft Bounce 
hardpattern       = Chaînes de caractères double-quotées, qui, si présentes dans l’email reçu,

                    qualifient le message en Hard Bounce 

2.3. Exécution


Le programme rafale.exe doit être lancé en mode « Administrateur ». La fenêtre principale affiche les informations de démarrage, qui doivent être attentivement consultées pour s’assurer du bon fonctionnement du système.


Ci-dessous l’arborescence du répertoire D:\Rafale\ après lancement du programme <rafale.exe>, qui créé plusieurs sous-répertoires (\atom, \ctrls, \datas, \mail, \system, etc) s’ils n’existent pas déjà.
 

De la même façon, Rafale créé le répertoire général de spool des comptes utilisateur. Si aucun répertoire n’est indiqué dans la configuration, Rafale crée par défaut le répertoire \RfSpool\ sur la même partition que son répertoire d’installation.

2.4. Fichier de configuration <rafale.bat>

 

Ce fichier texte contient les paramètres généraux de démarrage du programme, qui peuvent être également édités depuis l’interface de configuration.

3. COMPTES UTILISATEUR
 

Le système est conçu pour être exploité par plusieurs utilisateurs, chacun disposant de son propre répertoire de travail dans le répertoire D:\RfSpool\, de ses propres paramètres de routage, rapports et logs de job.


Les comptes utilisateurs se définissent dans D:\Rafale\users\, sous la forme d’un fichier de paramètre .ini. Le nom de l’utilisateur est défini par le nom du fichier .ini.


NB1 : le nom d’un utilisateur est limité à 20 caractères alphanumériques (A’=>’Z’ + ‘0’=>’9’) et caractère tiret ‘-‘.


NB2 : les noms d’utilisateurs commençant par ‘rf’ sont réservés au système.


Au lancement du programme, Rafale parse D:\Rafale\users\*.ini et créé des sous-répertoires portant le nom du fichier .ini dans D:\RfSpool\, toute leur sous-arborescence de travail (\DATA, \LOG,…) ainsi que les sous-arborescences des senders rattachés au compte dans \REPLY\.

3.1. Fichier de configuration <%user%.ini>

 

Les paramètres définis dans le fichier de configuration de l’utilisateur viennent remplacer ceux indiqués dans les ordres du routage de l’utilisateur.

Un des éléments les plus importants de la configuration concerne les adresses IP auquel a droit l’utilisateur. En effet, l’utilisateur peut spécifier une liste d’adresses IP dans la section [smtp] de son ordre de routage (cf « Rafale.IO – Client API » section 2.6), sans restriction particulière.

Pour limiter l’accès de l’utilisateur à toutes les adresses IP du système, deux alternatives :

 

  • Spécifier dans [smp]ip une liste d’adresses IP obligatoires, à partir desquelles tous les jobs de l’utilisateur seront expédiées.

  • Pour donner plus de souplesse à l’utilisateur, renseigner dans [account]authorizedip la liste des adresses IP autorisées pour l’utilisateur. Les ordres de routage pourront ainsi indiquer des adresses IP à utiliser dans [smtp]ip, mais seulement dans le spectre de celles autorisées.
     

Si aucune de ces deux clefs n’est renseignée, l’utilisateur peut exploiter toutes les adresses IP configurées sur la plateforme.


Par défaut, le système utilise le ReverseDNS des adresses IP comme domaine de sender des jobs (champ [header]from et [smtp]verp).


Si la clef [account]authorizedsender est précisée, l’utilisateur doit obligatoirement indiquer dans son ordre de routage un des domaines de sender de la liste.


La clef [account]authorizedroute contient la liste des relais SMTP autorisés pour l’utilisateur dans les sections [smtp]route, et [smtp@...]route.


La clef [account]authorizedrouting contient la liste des groupes de domaines pour lesquels l’utilisateur peut spécifier des paramètres [routing@...] spécifiques (‘*’=tous).

<%user%.ini>

[account]
smtpssl           = Connexion SSL obligatoire [port 465] (1)
smtplogin         = Login d’accès au relai SMTP
smtppassw         = Mot de passe associé
apissl            = Connexion SSL obligatoire [port 443] (1)
apikey            = Clef API à utiliser dans les URLs API
authorizedip      = Liste des IPs autorisées pour l’utilisateur
authorizedsender  = Liste des domaines de sender autorisés pour l’utilisateur
authorizedroute   = Liste des relais SMTP autorisés pour l’utilisateur
authorizedrouting = Liste des groupes de domaines autorisés pour paramètres de routage

                    spécifiques
 

[job]
retrynb           = Nombre de réessais d’envois (3)
retrydelay        = Délai entre les réessais [en heures]  (12)
tags              = Liste des tags (32 caractères max)

 

[list]
testaddr          = Liste préenregistrée d’adresses email de test
filter            = Liste de blacklists associé à l’utilisateur. Par défaut, le fichier global

                    des hard bounces et la liste de désabonnés du compte (rfhard %user%)
 

[tracking]
host              = Nom de domaine spécifique pour les liens de tracking (def RDNS)
open              = Mode de tracking d’ouverture (image)
click             = Mode de tracking de liens (short)
image             = Option de tracking des images (disable)
bot               = Option de tracking de bot (disable)
unsub             = URL de la page de désabonnement (/unsub.htm)
uncfm             = URL de la page de confirmation de de désabonnement (/uncfm.htm)

 

[routing]
ip                = Liste des adresses IP depuis lesquelles router le job
sender            = Domaine de sender
envelopefrom      = Adresse d’expéditeur de session SMTP 
sign              = Option de signature DKIM (1)
ssl               = Option de chiffrement de la session SMTP (1)
route             = Hôte relai SMTP (*)

 

[routing@..]      = Paramètres spécifiques par domaine

A l’exception de la section [account], les clefs qui sont définies écrasent celles de l’ordre de routage, même si leur valeur est vide (ex : [tracking]domain= interdit à l’utilisateur de spécifier un nom de sender spécifique, et force l’utilisation du ReverseDNS de l’IP).


Si clefs ne sont présentes ni dans le fichier de configuration ni dans l’ordre de routage, les valeurs par défaut s’appliquent.


(*) Nécessite la déclaration préalable d’un hôte relai SMTP dans \hosts\ (ex : @myisprelay)


3.2. Blacklists
 

Lors de l’import de la liste des destinataires d’un job, les adresses email listées dans au moins une des blacklists définies dans [list]filter ne seront pas routées, mais flaggées comme ‘Filtered’ dans le rapport de job.


Les fichiers de blacklists, stockés dans le répertoire D:\Rafale\lists\, sont au format .CSV, et doivent comporter un champ « email ». 


Rafale gère la blacklist système <rfhard.csv>, enrichie automatiquement par les remontées de Hard Bounces du MTA et du serveur SMTP.


Rafale gère également une blacklist par utilisateur, contenant les adresses désabonnées (via le lien de désabonnement, ou par List-Unsubscribe) et les notifications de plaintes (FeedBackLoop). Cette liste porte le nom du compte utilisateur.


Toutes les blacklists (.csv) du répertoire \lists\ sont réindexées une fois par jour en .idx à partir de 0h01, ce qui permet la prise en compte des nouvelles adresses à filtrer au maximum à J+1.


Les noms des blacklists déclarés dans [list]filter correspondent à leur nom de fichier sans extension (« rfhard » pour <rfhard.csv> etc).

3.3. Messages de retour
 

Rafale gère les messages de retour SMTP, qui peuvent être de plusieurs natures : FeedBackLoop, List-Unsubscribe par email, rapports DMARC, Hard et Soft Bounces, Challenge-Response, et réponses - automatiques ou non - aux messages envoyés.


Pour chaque sender utilisé, qu’il s’agisse des ReverseDNS associés aux adresses IP, ou de noms de domaines spécifiés dans les paramètres de job (ex : [smtp]domain), le système créé un sous-répertoire du sender dans D:\Rafale\relays\, ainsi qu’une sous-arborescence de tri, dans laquelle sont stockés les messages reçus en fonction de leur type, sous forme de fichiers horodatés :

 

  • @CHALLENGE contient les messages identifiés comme Challenge-Response par détection d’un pattern listé dans <rafale.ini>[rfrelay]challengepatrn.

  • @DMARC contient les messages reçus sur une des adresses email de l’enregistrement DMARC, spécifiées dans <rafale.ini>[rfrelay]dmarcaddr.

  • @FBL contient les messages de FeedBackLoop reçus sur une des adresses email spécifiée dans <rafale.ini>[rfrelay]fbladdr.

  • @HARD contient les messages identifiés comme Hard Bounce par détection d’un pattern listé dans  <rafale.ini>[rfrelay]hardptrn.

  • @SOFT contient les messages identifiés comme Soft Bounce par détection d’un pattern listé dans  <rafale.ini>[rfrelay]softptrn.

  • @UNLST contient les messages de désinscription automatique par email (Tag List-Unsubscribe) ainsi que les messages identifiés comme plaintes par détection d’un pattern listé dans  <rafale.ini>[rfrelay]complainptrn.

  • @VERP contient les messages reçus sur l’adresse de session SMTP (MAIL FROM) lorsque l’option [smtp]envelopefrom est fixée à verp (cf Rafale – Client API al. 2.2.1), et dont le contenu n’a pu être qualifié.

  • abuse et postmaster sont des adresses statiques associées au sender (abuse@newsletter.rafale.io et postmaster@newsletter.rafale.io), créés automatiquement par le système car souvent nécessaires à l’inscription aux programmes de FeedBackLoop.

Lors de l’injection d’un job, le système créé automatiquement un répertoire d’adresse statique correspondant à l’adresse de sender définie dans [header]fromaddr (cf Rafale – Client API al. 2.6).


Il est possible de créer manuellement un répertoire @CATCHALL qui acceptera tous les messages du domaine de sender sur des adresses inexistantes (il s’agira probablement de spam).


Le contenu des fichiers est le flux brut de données tel que reçu pendant la phase DATA de la session SMTP (message RFC822).


La sous-arborescence du sender et son contenu (les messages reçus), sont intégralement dupliqués dans le répertoire \REPLY\ de l’utilisateur à qui le sender est rattaché (le rattachement d’un sender à un utilisateur est déterminé par le système, en fonction des paramètres [account]authorizedip, [account]authorizedsender et [smtp]ip du compte utilisateur).

4. GROUPES DE DOMAINES

L’envoi des emails s’effectue par le protocole SMTP auprès les serveurs de messagerie qui hébergent les enregistrements MX DNS des domaines de destination. Il peut s’agir de FAIs (ex : Orange, Sfr, Free), de webmails (ex : Gmail, Hotmail, Yahoo, AOL), de Registars (ex : Gandi, OVH, 1&1), d’hébergeurs de services de messagerie ou encore de serveurs de messagerie d’entreprise.


La majorité des infrastructures de messagerie est protégée contre le spam par des outils sophistiqués, parmi lesquels la mesure de réputation basée sur la qualité du trafic (taux de bounces, d’ouvertures et de plaintes entre autres), qui régule le volume et le débit des messages acceptés, leur distribution en boite de réception ou en boîte à spam, et gère le blocage éventuel de l’IP d’expédition ou du sender pour une durée arbitraire.


Chaque hébergeur disposant de solutions techniques différentes, de plus paramétrées spécifiquement, la gestion de la délivrabilité doit s’effectuer au cas par cas.


C’est l’objet du répertoire D:\Rafale\domains\.

Ce répertoire contient une liste de groupe de domaines de destination, dont les paramètres et stratégies de routage sont configurables individuellement.


Chaque groupe de domaines est défini par un nom de fichier alphanumérique (‘a’=>’z’ + ‘0’=>’9’ + tiret ‘-‘), d’une longueur maximale de 30 caractères, et préfixé par le caractère ‘@’, et portant l’extension ‘.ini’.


Ce fichier contient le ou les patterns d’enregistrements MX du groupe de domaines, les paramètres de débit d’acheminement des messages ainsi que les patterns de retours SMTP et leur qualification/action associées.


A chaque groupe de domaines est associé un fichier d’alias, nommé ‘%DM%_alias.csv’, qui liste tous les noms de domaines qui matchent les même patterns MX DNS, un fichier nommé ‘%DM%_log.csv’ qui enregistre les messages d’erreur SMTP non répertoriés, ainsi qu’un fichier ‘%DM%_mx.csv’, qui recense les adresses IP correspondant aux MX.


Tous ces fichiers sont automatiquement mis à jour par le système pendant le routage, lors de la résolution MX de domaines de destination.


4.1. Fichiers \domains\%DM%.ini
 

Ci-dessous extrait du fichier <@yahoous.ini> :

4.1.1. Paramètres DNS
 

La section [dns] comporte les clefs suivantes :

 

  • ‘mx’, qui contient la liste des patterns des MX du groupe de domaines (nb : les wildcards ‘*’ sont autorisées, sauf pour les relais smtp – voir ci-dessous), séparés par des espaces.

  • ‘domain’, nom de domaine de l’hôte utilisé pour la résolution MX initiale

  • ‘cache’, qui indique si les noms de domaines des alias doivent être mis en cache DNS ou non. Valeur ‘0’ (défaut) ou ‘1’ (=oui). Réserver cette option pour les domaines de FAI, peu nombreux et peu sujet au changement, et éviter d’activer ce flag pour les hébergeurs de domaines professionnels (Gmail, Outlook, Registars…)

  • ‘relay’, qui précise si cet hôte est un relai SMTP intermédiaire auquel remettre les messages.

  • ‘port’, numéro de port IP sur lequel se connecter au serveur relai (465)

  • ‘ip’, liste les adresses IP autorisées pour contacter le serveur relai. Si non précisé, la connexion sera établie depuis les IPs autorisées du compte utilisateur.

  • ‘login’ et ‘passw’ : si non précisés, la session SMTP sautera la partie ‘AUTH’

  • ‘overwrite’ : ce flag force l’utilisation du champ login (qui doit être une adresse email en ce cas) pour les champs ‘envelopefrom’ et ‘from’ du message (voir API section [smtp]).

4.1.2. Paramètres de contrôle de flux

Les paramètres de configuration de la délivrabilité permettent de gérer automatiquement le cycle de vie d’une adresse IP ou d’un sender, de la phase de rodage jusqu’au débit optimal, en passant par la gestion d’éventuels blacklistages.


En effet, les paramètres de débits sont fonction de la « réputation » de l’IP et du sender d’émission, et doivent s’adapter aux problématiques suivantes :

 

  • A leur mise en service, les IPs/senders nécessitent une phase de rodage, ou encore « warmup », avec l’envoi régulier de faibles volumes de messages, avec un faible débit.

  • Ces volumes vont pouvoir progressivement augmenter avec le temps et le nombre total de messages délivrés, si toutefois les performances des envois (taux de hardbounce, taux d’ouverture, taux de désinscription, taux de plainte) le permettent.

  • En revanche, si des messages de retour (bounces) se manifestent pendant les transmissions, les envois doivent être suspendus pour une durée plus ou moins longue en fonction du niveau de gravité du blocage, puis reprendre le cas échéant à un rythme plus lent.

  • De la même façon, l’inutilisation d’IP/sender pendant une période prolongée doit conduire à la reprise du rodage.


Le système offre 8 sets de paramètres : « defcon3, defcon2, defcon1, warmup, low, mid, high, full », aux débits d’émission croissants.

 

  • « defcon3 » correspond au niveau de blocage le plus élevé, nécessitant une démarche auprès du postmaster du destinataire. Par défaut, dans ce mode, seul un message est émis chaque jour afin de vérifier la levée éventuelle du blocage.

  • « defcon2 » correspond à un blocage qui nécessite un traitement manuel pour sa levée (ex : formulaire CloudMark).

  • « defcon1 » correspond à un blocage temporaire, dû à un trop grand nombre de messages envoyés par unité de temps.

  • « warmup » représente l’état initial des IP/sender lors de leur mise en service, en mode rodage.

  • « low », « mid », « high » et « full » correspondent aux cadences d’émission au fur et à mesure de l’établissement de la réputation des IP/sender.

Le passage de l’un à autre de ses sets de paramètres s’effectue automatiquement en fonction de plusieurs conditions :

 

  • Lors de l’atteinte de seuil de volumes d’envois sur une période donnée (ex : « warmup » pendant 1 semaine et 5000 emails/jour avant de passer à « low », puis à « mid », etc.)

  • Lorsque le volume d’envois sur une période donnée est en dessous d’un certain seuil (ex : reprise du « warmup » si moins de 100 emails émis dans le dernier mois)

  • Lorsque des messages de bounce sont reçus lors des transmissions SMTP (ex : message de blacklistage CloudMark qui bascule en « defcon2 »

l’API offre en outre la possibilité de piloter le switch à la demande.


Les sections [ipflow#XXX] et [sdflow#XXX] contiennent les sets de paramètres d’envoi, respectivement par IP et par sender, XXX représentant le set concerné (ex : [ipflow#warmup]).


Il est possible de définir des sets de paramètres pour des IP ou des senders spécifiques, en suffixant la section [ipflow#XXX] avec ‘@’ + adresse IP et [sdflow]  avec ‘@’ + nom de domaine de sender, soit [ipflow#XXX@IP] et [sdflow#XXX@sender].


Concernant le contrôle du flux instantané, le paramètre ‘threadmax’ limite le nombre maximum de sessions SMTP simultanées (0= illimité), ‘chainmax spécifie le nombre maximum de messages envoyés par session SMTP, et ‘waittime’ le nombre de secondes de pause entre deux sessions SMTP.


Concernant le contrôle des volumétries, deux intervalles de temps peuvent être paramétrés avec un nombre maximum d’envois de messages. ‘volttllow’ et ‘volttlhigh’ indiquent le nombre de seconde des intervalles de temps, tandis que ‘volmaxlow’ et ‘volmaxhigh’ indiquent le nombre maximum d’envois pendant l’intervalle de temps.


NB : les valeurs des clefs d’unité de temps sont par défaut exprimées en secondes, mais peuvent être suffixées par ‘m’ pour minutes, ‘h’ pour heures et ‘d’ pour jour (24h).
 

Par exemple,
 

[ipflow#warmup]
volttllow = 10m
volmaxlow = 60
volttlhigh = 24h
volmaxhigh = 3000


spécifie un maximum de 60 messages par tranche de 10 minutes ET un maximum de 3000 messages par jour (alors qu’appliqué seul, le premier paramètre donnerait un maximum de 60 x 6 x 24 = 8640 messages par 24h).


Typiquement, ces paramètres permettent d’assurer un débit optimal du flux tout en respectant des quotas journaliers.


Concernant le contrôle des sets de paramètres, ‘sleepttl’ indique le temps de pause avant le premier envoi lorsque le set de paramètre est initialement appliqué seulement suite à un message de FLOW().


Les paramètres { ‘flowttlup’ ‘flowvolup’ ‘flowup’ } et { ‘flowttldown’ ‘flowvoldown’ ‘flowdown’ } contrôlent le swtich automatique entre les sets de paramètres sur la base de volumes de messages délivrés par unité de temps.
 

Par exemple, 
 

[ipflow#warmup]
flowttlup = 7d
flowvolup = 10000
flowup = low

 

indique qu’en mode ‘warmup’, le système switchera sur le set de paramètres [ipflow#low] après 10000 messages envoyés au total sur une semaine.
 

De la même façon,
 

[ipflow#high]
flowttlup = 15d
flowvolup = 1000
flowup = mid

 

indique qu’en mode ‘high’, le système switchera sur le set de paramètres [ipflow#mid] si moins de 1000 messages sont délivrés dans les 2 dernières semaines.


NB :  si ‘flowup’ ou ‘flowdown’ ne sont pas spécifiés, les valeurs par défaut ‘up’ et ‘low’ s’appliquent, et indiquent de passer au set de paramètres de niveau immédiatement supérieur et inférieur (ex : ‘up‘ en ‘#low’ passe en ‘#mid’ et ‘down’ en ‘#low’ passe en ‘#warmup’), ‘#wamup’ et ‘#full’ constituant les bornes de l’intervalle.


NB : lors des switchs automatiques, le paramètre ‘sleepttl’ n’est pas appliqué.


4.1.3. Qualification de patterns SMTP
 

Par défaut, tout message d’erreur (hors « 220 Ok » ou « 250 Ok ») est considéré comme un soft bounce (erreur temporaire). A ce titre, le job est susceptible de faire l’objet d’un ré-essai de transmission.
En effet, les codes d’erreur SMTP et messages de retour sont variables d’un serveur de messagerie à l’autre, et nécessitent une qualification individuelle, objet de la section [pattern] 

Syntaxe : Nom_de_pattern=FONCTION(paramètres) SMTP_pattern


‘Nom_de_pattern’ : chaine alphanumérique de 16 caractères maximum (‘a’=>’z’ + ‘0’=>’9’ + tiret ‘-‘)


‘SMTP_pattern’ : message de réponse SMTP, pouvant comporter one ou plusieurs wildcards ‘*’, qui signifie « au moins un caractère et n’importe quel(s) caractère(s) ».


FONCTION(paramètres) :
SOFT(description) : qualifie le job en erreur temporaire (donc réessayable). 
HARD(description) : qualifie le job en NPAI (aucun réessai).
SPAM(description) : email rejeté car contenu identifié comme spam (aucun réessai)
GREY(description, X) : qualifie le pattern en grey listing, X étant de délai d’attente en secondes avant ré-essai (600s par défaut).
FLOW(description, #XXX, #YYY)) : qualifie le pattern comme une indication de blocage ou blacklistage. #XXX et #YYY, facultatifs, spécifient les nouveaux sets de paramètres IP et sender à appliquer en conséquence.
 

NB : les paramètres ‘Nom_de_pattern’ et ‘description’ (16 caractères) se retrouvent dans les logs et rapports de job au niveau des champs ‘rfpattern’ et ‘rfstr’.
 

4.1.4. Cas Particuliers

Le fichier ‘.defflow.ini’ contient les valeurs par défaut des paramètres de contrôle de flux pour tous les  groupes de domaines.
 

Le profil ‘@.ini’ représente le groupe des domaines qui n’appartiennent à aucun groupe nommé. A ce titre, les paramètres de quotas volumétriques s’appliquent au cumul du trafic de tous les domaines. En revanche, les paramètres ‘threadmax’ et ‘chainmax’ restent individuels à chaque domaine.
 

4.1.5. Fichier de configuration <%DM%.ini>

<%DM%.ini>

[dns]
mx           = Liste des patterns d’enregistrements MX du groupe de domaines (ou hôte du relai)
domain       = Nom de domaine utilisé pour résolution MX initiale (si Ø => premier alias)
cache        = Option de mise en cache DNS des domaines des alias (1=oui). A réserver aux

               domaines des FAIs. (0)
relay        = Indique s’il s’agit d’un relai smtp (1=oui) (0)
port         = Port IP des MX du relai smtp (465)
ip           = IP à utiliser pour connexion au relai
login        = Login du relai
passw        = Mot de passe du relai
overwrite    = Utilise le login comme ‘envelopefrom’ et ‘from’ (voir API section [smtp]) (0)

 

[ipflow#XXX]   ( XXX Ø Nom du set de paramètres (ex : ‘warmup’’, ‘mid’, ‘decfon1’, …) )
sleepttl     = Temps d’attente, en secondes, avant première prise de job lors du passage au set

               de paramètres suite à FLOW() (0)
threadmax    = Nombre maximum de sessions SMTP simultanées (1)
chainmax     = Nombre maximum de messages envoyés par session SMTP (0)
waittime     = Temps d’attente, en secondes, entre deux sessions SMTP (0)
errmax       = Nombre maximum de messages d’erreur SMTP inconnus consécutifs (0)
flowerr      = Set à l’atteinte d’errmax (0)
volttllow    = Unité de temps inférieure (0)
volmaxlow    = Nombre maximal de messages par unité de temps inférieure (0)
volttlhigh   = Unité de temps supérieure (0)
volmaxhigh   = Nombre maximal de messages par unité de temps supérieure (0)
flowttlup    = Durée du set avant UP (0)
flowvolup    = Volume de message du set avant UP (0)
flowup       = Set sur lequel switcher (UP) (0)
flowttldown  = Durée du set avant DOWN (0)
flowvoldown  = Volume de message du set avant DOWN (0)
flowdown     = Set sur lequel switcher (DOWN) (0)

 

[sdflow#XXX]        IDEM [ipflow], mais pour les senders au lieu des IP
[ipflow#XXX@IP]     Set de paramètres pour IP spécifique’
[sdflow#XXX@sender] Set de paramètres pour sender spécifique

 

[pattern] 
mnémonique   = FNCT(args)  pattern
               FLOW(desc, ipflow(X), sdflow(Y))
               GREY(desc, duration) / SPAM(desc)
               HARD(desc) / SOFT(desc)

4.2. Fichiers \domains\%DM%_alias.csv

Comme spécifié précédemment, à chaque grouope de domaines est associé un fichier d’alias, nommé ‘%DM%_alias.csv’, qui liste tous les noms de domaines qui lui sont associés.


Ce fichier, au format CSV, contient deux champs : 1/ ‘date’, au format YYMMDDhhmmss, indique la date d’inscription du domaine dans la liste d’alias, 2/ ‘domain’, qui contient le nom de domaine.


Ce fichier peut-être enrichi manuellement, bien que le système gère automatiquement la détection des nouveaux alias lors des résolutions MX des domaines de destination.

4.3. Fichiers \domains\%DM%_log.csv

 

Lorsque le système rencontre un message d’erreur non répertorié (qui ne matche aucun des patterns référencés), il l’ajoute dans le fichier @%DM%.log, pour qualification manuelle ultérieure.

‘rfsenddate’ indique la date d’enregistrement du pattern, ‘ref’ la référence utilisateur du job, ‘rfmailno’ la référence interne système du job, ‘rfrecno’ le numéro de destinataire dans la liste, ‘rfsendip’ l’adresse IP depuis laquelle la tentative d’envoi a eu lieu, ‘rfmxip’ l’adresse IP du serveur de messagerie distant, ‘rfstp’ l’étape du protocole lors duquel a été reçu le message, et enfin, ‘rfrcv’ contient la réponse SMTP telle que reçue.


5. LOGS
 

Chaque module enregistre des traces de fonctionnement dans le répertoire D:\Rafale\logs : %module%.txt et %module%.csv, et le programme principal dans D:\Rafale\logs\rafale.txt.


Le fichier .txt contient les messages d’informations et de debugging du module, tels qu’ils apparaissent dans les fenêtres du programme, tandis que le .csv logge chaque job traité.

6. INFORMATIONS SYSTEME
 

Rafale crée, lors de son lancement, plusieurs sous-répertoires et fichiers, destinés à son fonctionnement interne, qui ne doivent en aucun cas être modifiés ou altérés, tels que :

  • \mails\ : un sous-répertoire par job avec ses données associées

  • \queues\ : file d’attente des messages intermodule

  • \system\ : variables et compteurs internes du système

 

Le répertoire \wwws\ représente le répertoire racine du serveur http intégré. Il contient des pages d’exemple relatives au processus de désabonnement, et peut-être complété avec tout type de fichier (images, documents, pages html diverses) et sous-répertoires.

 

7. SENDERS

Rafale crée, lors de son lancement, plusieurs sous-répertoires et fichiers, destinés à son fonctionnement interne, qui ne doivent en aucun cas être modifiés ou altérés, tels que :

@                    A       5.196.198.240
@                    A       5.196.198.241
@                    MX      10 newsletter.rafale.io.
@                    TXT     ( "v=spf1 ip4: 5.196.198.240/31 -all" )
@                    TXT     ( "spf2.0/pra ip4: 5.196.198.240/31 -all" )
dkim._domainkey      TXT     ( "t=y; k=rsa; p=MIG…………………………………………………QAB;" )
_dmarc               TXT     ( "v=DMARC1; p=reject; pct=100; rua=mailto:

                                          dmarc@newsletter.rafale.io" )
 

Pour générer une paire de clefs privée/publique DKIM, utiliser par exemple Openssl :


openssl.exe genrsa -out newsletter.rafale.io-dkim-prv.pem 2048
 

openssl.exe rsa -in newsletter.rafale.io-dkim-prv.pem -out

                    newsletter.rafale.io-dkim-pub.pem -pubout
 

La clef publique, présente dans le fichier ‘newsletter.rafale.io-dkim-pub.pem’, doit être copiée dans l’enregistrement DNS dkim._domainkey.
 

Le fichier contenant la clef privée,  ‘newsletter.rafale.io-dkim-prv.pem’, doit être copié dans le répertoire D:\Rafale\keys\, et renommé avec la syntaxe suivante :


<domain> <espace> <selector> <espace> <id>. pem


‘domain’ représente le nom de domaine du sender, ‘selector’ le préfixe de ._domainkey dans la zone DNS (‘dkim’ ici en exemple), et ‘id’, de nom d’utilisateur dans l’adresse email associée avec la signature.


Pour définir une clef de signature par défaut, créer un nom de fichier commençant par un point ‘.’, par exemple <.def dkim id.pem>
 

Le nom d’utilisateur dans l’adresse email spécifiée dans l’enregistrement _dmarc, doit être déclaré dans [rfrelay]dmarcaddr.
 

Inscrire le domaine de sender aux différents programmes de FeedBackLoop, et enregistrer les adresses de notification dans [rfrelay]fbladdr.
 

AOL : https://postmaster.info.aol.com/fbl-request
Yahoo : https://help.yahoo.com/kb/SLN3438.html
SNDS Hotmail : https://postmaster.live.com/snds/
JMRP Hotmail : https://postmaster.live.com/snds/JMRP.aspx
LaPoste.net : https://fbl.postmaster.laposte.net/
 

Installer enfin les Certificats des domaines de sender dans le Certificates Store de Windows.