Rafale.IO Configuration 10.9 (EN)


Rafale.exe is the only executable program in the system. It does not require any additional component such as library, dll, package, services, etc., apart from the operating system.

It runs on all bit versions of Microsoft Windows, client and server, from Windows 7 and Windows Server 2003 (all editions), and consumes a maximum of 2GB of ram once started.

It does not make any entry in the Registry, which makes it very easily saveable and transferable from one machine to another.

The program is designed so that no third-party tools are needed for its configuration and administration, apart from a simple text editor. This is why internal databases are in fixed-length text format, logs in .csv format and configuration parameters in .ini format, which manual editing is more flexible than JSON, for a performance gain x2 in memory and 7x in read / write speed.

In the context of this API, the level of encapsulation of objects is not of a prohibitive depth to their linearization. The REST API nevertheless allows reading and writing of all parameters in JSON format.

NB1: this document is complementary to "Rafale.IO - API 1.9" whose prior knowledge is essential.

NB2: the configuration examples in this document are given for an installation on D:\Rafale\, user spool directory D:\RfSpool\, and use 4 IP addresses ( and 2 sender domains (newsletter. rafale.io and service.rafale.io).


Rafale is delivered in the form of an archive, <Rafale.zip>, which must be decompressed from the root of a partition (here, for the example, <D:>).

NB: the system is delivered with examples of domain groups (Aol, Gmail, Hotmail and Yahoo), a 'demo' demo account, and standard unsubscribe pages.

Some configuration steps are necessary before the first launch of the software:
(Reminder: example data = range of 4 IPs and 2 senders newsletter.rafale.io and service.rafale.io)

1) Declare the public IP addresses of the server in its network configuration. This can be done either from the Network and Sharing Center, or using the Shell command "FOR / L %% I IN (240,1,243) DO netsh interface ip add address" Ethernet "5.196.198.% % I "

2) Authorize, in the Windows firewall, the program <D:\Rafale\rafale.exe> for outgoing connections (on port 25, for sending emails), and incoming connections (on ports 25 and 465 for the SMTP relay, as well as 80 and 443, for online tracking and statistics).

3) Edit the file <D:\Rafale\rafale.key> with Notepad and copy the serial number of the product (32 alphanumeric characters).

4) Configure <D:\Rafale\rafale.ini> according to the specifications in the following sections.

5) Save a shortcut of <D:\Rafale\rafale.exe> in:

%ALLUSERSPROFILE%\Microsoft\Windows\Start Menu\Programs\Startup



2.1. Architecture


Rafale is made up of 5 main modules, which communicate with each other via a high performance memory queue:


  • RfUser processes user commands (see document “Rafale - API 10.9”), imports jobs, and exports reports and statistics.

  • RfMail injects job posts into the MTA queue, and consolidates job logs and real-time statistics.

  • RfMta ensures the fusion / personalization and the signature of the emails, and transmits the messages to the destination servers by managing the deliverability.

  • RfTrack responds to HTTP requests for tracking emails (opens, clicks, unsubscribes, etc.).

  • RfRelay manages incoming SMTP communications, for the relay function as well as for return messages (responses to received emails, Challenge-Response, FeedBackLoop, etc.).

2.2. Configuration file <rafale.ini>

An essential step in the configuration of the system is the declaration of the IP addresses dedicated to routing.

A domain name must be associated with each IP address.

If the IP addresses are dedicated to a single sender, directly indicate the sender that will be used on these IP addresses. In this way, all emails that will be sent from this IP will automatically use this domain name for the sender addresses and the tracking links of the message.

Otherwise, provide a generic name, for example, mtaXX.rafale.io. Jobs routed from these IP addresses must in this case specify a sender domain to use).

Below is an example of a configuration file:


X.Y.Z.P           = List of public IPs to use for routing, and their associated ReverseDNS.

mailsize          = Maximum number of jobs to route simultaneously (10000)
mailage           = Buffering time in days after end of the job (7)
qmsize            = Maximum number of records in the queue (100000)
qmmemo            = Size in KB of BLOB fields in the queue (16)
apikey            = Global API access apikey HTTP

spool             = Main user spool directory (%:\RfSpool\)

flush             = Real-time statistics update delay (in seconds) (300)


threadnb          = Maximum number of simultaneous outgoing SMTP threads (128)

threadnb          = Maximum number of simultaneous HTTP threads (64)
listen            = List of IPs: listening ports. If the port is not specified, value :80


threadnb          = Maximum number of simultaneous incoming SMTP threads (32)
listen            = List of IPs: listening ports. If the port is not specified, value :25

dmarcaddr         = List of email addresses (without domain) assigned to the reception

                    of DMARC reports (cf Senders : DNS zones)
fbladdr           =
List of email addresses (without domain) assigned to the reception

                    of FeedBackLoops (cf Senders : DNS zones)
challengepattern  = Double quoted character strings, which, if present in the received email,

                    qualify the message as a Challenge
softpattern       = Double quoted character strings, which, if present in the received email,

                    qualify the message as a Soft Bounce 
hardpattern       = Double quoted character strings, which, if present in the received email,

                    qualify the message as a Hard Bounce 

2.3. Execution

The rafale.exe program must be started in "Administrator" mode. The main window displays the startup information, which should be carefully reviewed to ensure proper system operation.

Below is the tree structure of the D:\Rafale\ directory after launching the <rafale.exe> program, which creates several sub-directories (\atom, \ctrls, \data, \mails, \system, etc.) if they do not already exist.

Likewise, Rafale creates the general spool directory for user accounts. If no directory is specified in the configuration, Rafale creates by default the \RfSpool\ directory on the same partition as its installation directory.

2.4. Configuration file <rafale.bat>


This text file contains the general parameters for starting the program, which can also be edited from the configuration interface.



The system is designed to be operated by multiple users, each with their own working directory in the D:\RfSpool\directory, their own routing settings, reports and job logs.

User accounts are defined in D:\Rafale\users\, in the form of an .ini parameter file. The name of the user is defined by the name of the .ini file.

NB1: the name of a user is limited to 20 alphanumeric characters (A '=>' Z '+' 0 '=>' 9 ') and dash character' - '.

NB2: Usernames starting with 'rf' are reserved for the system.

When the program is started, Rafale parses D:\Rafale\users\*. Ini and creates sub-directories bearing the name of the .ini file in D:\RfSpool\, their entire working sub-tree (\DATA, \LOG ,…) As well as the sub-trees of the senders attached to the account in \REPLY\.

3.1. Configuration file <%user%.ini>


The parameters defined in the user's configuration file replace those indicated in the user's routing orders.

One of the most important elements of the configuration concerns the IP addresses to which the user is entitled. In fact, the user can specify a list of IP addresses in the [smtp] section of his routing order (see “Rafale.IO - Client API” section 2.6), without any particular restriction.

To limit user access to all IP addresses on the system, two alternatives:


  • Specify in [smp] ip a list of mandatory IP addresses, from which all the user's jobs will be forwarded.

  • To give more flexibility to the user, enter in [account] authorizedip the list of IP addresses authorized for the user. The routing orders will thus be able to indicate IP addresses to be used in [smtp] ip, but only in the spectrum of those authorized.


If neither of these two keys is entered, the user can use all the IP addresses configured on the platform.

By default, the system uses the ReverseDNS of the IP addresses as the job sender domain ([header] from and [smtp] verp field).

If the [account] authorizedsender key is specified, the user must indicate in his routing order one of the sender domains in the list.

The [account] authorizedroute key contains the list of authorized SMTP relays for the user in the [smtp] route, and [smtp @ ...] route sections.

The [account] authorizedrouting key contains the list of domain groups for which the user can specify specific [routing @ ...] parameters ('*' = all).

<% user% .ini>

smtpssl           = SSL connection required [port 465] (1)
smtplogin         = Login to access the SMTP relay
smtppassw         = Associated password
apissl            = SSL connection mandatory [port 443] (1)
apikey            = API key to use in API URLs
authorizedip      = List of authorized IPs for the user
authorizedsender  = List of authorized sender domains for the user
authorizedroute   = List of authorized SMTP relays for the user
authorizedrouting = List of authorized domain groups for specific routing parameters 


retrynb           = Number of retries (3)
retrydelay        = Delay between retries [in hours] (12)
tags              = List of tags (32 characters max)

testaddr          = Pre-registered list of test email addresses
filter            = List of blacklists associated with the user. By default, the global file

                    hard bounces and the list of unsubscribed account (rfhard% user%)

host              = Specific domain name for tracking links (def RDNS)
open              = Opening tracking mode (image)
click             = Link tracking mode (short)
image             = Image tracking option (disable)
bot               = Bot tracking option (disable)
unsub             = URL of unsubscribe page (/unsub.htm)
uncfm             = URL of the unsubscribe confirmation page (/uncfm.htm)

ip                = List of IP addresses from which to route the job
sender            = Domain of sender
envelopefrom      = SMTP session sender address
sign              = DKIM signature option (1)
ssl               = SMTP session encryption option (1)
route             = SMTP relay host (*)


[routing @ ..] = Specific parameters by domain

With the exception of the [account] section, the keys which are defined overwrite those of the routing order, even if their value is empty (ex: [tracking] domain = forbids the user to specify a sender name specific, and forces the use of the IP's ReverseDNS).

If keys are not present in the configuration file or in the routing order, the default values ​​apply.

(*) Requires the prior declaration of an SMTP relay host in \hosts\ (ex: @myisprelay)

3.2. Blacklists


When importing the list of recipients of a job, the email addresses listed in at least one of the blacklists defined in [list] filter will not be routed, but flagged as 'Filtered' in the job report.

The blacklist files, stored in the D:\Rafale\lists\ directory, are in .CSV format, and must include an "email" field.

Rafale manages the <rfhard.csv> system blacklist, automatically enriched by the Hard Bounces feedback from the MTA and the SMTP server.

Rafale also manages a blacklist per user, containing unsubscribed addresses (via the unsubscribe link, or by List-Unsubscribe) and complaints notifications (FeedBackLoop). This list is named after the user account.

All the blacklists (.csv) in the \lists\ directory are reindexed once a day in .idx from 12:01 am, which allows new addresses to be taken into account to be filtered at most on D + 1.

The names of the blacklists declared in [list] filter correspond to their file name without extension ("rfhard" for <rfhard.csv> etc).

3.3. Incoming messages


Rafale manages SMTP return messages, which can be of several types: FeedBackLoop, List-Unsubscribe by email, DMARC reports, Hard and Soft Bounces, Challenge-Response, and responses - automatic or not - to sent messages.

For each sender used, whether it is the ReverseDNS associated with the IP addresses, or the domain names specified in the job parameters (eg: [smtp] domain), the system creates a sub-directory of the sender in D:\Rafale\relays\, as well as a sorting sub-tree, in which the messages received according to their type are stored, in the form of time-stamped files:


  • @CHALLENGE contains the messages identified as Challenge-Response by detection of a pattern listed in <rafale.ini> [rfrelay] challengepatrn.

  • @DMARC contains messages received on one of the email addresses in the DMARC record, specified in <rafale.ini> [rfrelay] dmarcaddr.

  • @FBL contains FeedBackLoop messages received on one of the email addresses specified in <rafale.ini> [rfrelay] fbladdr.

  • @HARD contains messages identified as Hard Bounce by detection of a pattern listed in <rafale.ini> [rfrelay] hardptrn.

  • @SOFT contains the messages identified as Soft Bounce by detection of a pattern listed in <rafale.ini> [rfrelay] softptrn.

  • @UNLST contains automatic unsubscribe messages by email (Tag List-Unsubscribe) as well as messages identified as complaints by detection of a pattern listed in <rafale.ini> [rfrelay] complainptrn.

  • @VERP contains the messages received on the SMTP session address (MAIL FROM) when the [smtp] envelopefrom option is set to verp (see Rafale - Client API al. 2.2.1), and whose content could not be to be qualified.

  • abuse and postmaster are static addresses associated with the sender (abuse@newsletter.rafale.io and postmaster@newsletter.rafale.io), created automatically by the system as they are often necessary for subscribing to FeedBackLoop programs.

When injecting a job, the system automatically creates a static address directory corresponding to the sender address defined in [header] fromaddr (see Rafale - Client API al. 2.6).

It is possible to manually create a @CATCHALL directory that will accept all messages from the sender domain to non-existent addresses (it will probably be spam).

The contents of the files are the raw data stream as received during the DATA phase of the SMTP session (RFC822 message).

The sender sub-tree and its content (the messages received) are fully duplicated in the \REPLY\ directory of the user to whom the sender is attached (the attachment of a sender to a user is determined by the system, according to the [account] authorizedip, [account] authorizedsender and [smtp] ip parameters of the user account).


The emails are sent using the SMTP protocol to the mail servers that host the MX DNS records of the destination domains. They can be ISPs (ex: Orange, Sfr, Free), webmails (ex: Gmail, Hotmail, Yahoo, AOL), Registars (ex: Gandi, OVH, 1 & 1), email service hosts or even corporate mail servers.

The majority of messaging infrastructures are protected against spam by sophisticated tools, including the reputation measurement based on the quality of the traffic (rate of bounces, openings and complaints among others), which regulates the volume and the flow messages accepted, their distribution in inbox or in spam box, and manages the possible blocking of the sending IP or the sender for an arbitrary duration.

Each host has different technical solutions, moreover specifically configured, the management of deliverability must be done on a case-by-case basis.

This is the object of the D:\Rafale\domains\directory.

This directory contains a list of destination domain groups, whose routing parameters and policies are individually configurable.

Each domain group is defined by an alphanumeric file name ('a' => 'z' + '0' => '9' + dash '-'), with a maximum length of 30 characters, and prefixed by the character '@', and with the extension '.ini'.

This file contains the MX record pattern (s) of the domain group, the message routing rate parameters as well as the SMTP return patterns and their associated qualification / action.

With each group of domains is associated an alias file, named '% DM% _alias.csv', which lists all the domain names which match the same MX DNS patterns, a file named '% DM% _log.csv' which logs unlisted SMTP error messages, as well as a '% DM% _mx.csv' file, which lists the IP addresses corresponding to the MXs.

All of these files are automatically updated by the system during routing, during MX resolution of destination domains.

4.1. \Domains\%DM%.ini files


Below is an extract from the <@yahoous.ini> file:

4.1.1. DNS settings


The [dns] section contains the following keys:


  • 'mx', which contains the list of MX patterns of the domain group (nb: '*' wildcards are allowed, except for smtp relays - see below), separated by spaces.

  • 'domain', domain name of the host used for initial MX resolution

  • 'cache', which indicates whether the alias domain names should be DNS cached or not. Value '0' (default) or '1' (= yes). Reserve this option for ISP domains, which are few in number and not subject to change, and avoid activating this flag for professional domain hosts (Gmail, Outlook, Registars, etc.)

  • 'relay', which specifies whether this host is an intermediate SMTP relay to deliver messages to.

  • 'port', IP port number on which to connect to the relay server (465)

  • 'ip', lists the IP addresses authorized to contact the relay server. If not specified, the connection will be established from the authorized IPs of the user account.

  • 'login' and 'passw': if not specified, the SMTP session will skip the 'AUTH' part

  • 'overwrite': this flag forces the use of the login field (which must be an email address in this case) for the 'envelopefrom' and 'from' fields of the message (see API section [smtp]).

4.1.2. Flow control parameters

The deliverability configuration parameters are used to automatically manage the life cycle of an IP address or a sender, from the break-in phase to the optimal throughput, including the management of possible blacklists.

Indeed, the speed parameters depend on the "reputation" of the IP and the transmission sender, and must adapt to the following issues:


  • When they are put into service, the IPs / senders require a running-in phase, or even “warmup”, with the regular sending of low volumes of messages, with a low speed.

  • These volumes will be able to gradually increase over time and with the total number of messages delivered, if the sending performance (hardbounce rate, open rate, unsubscribe rate, complaint rate) allows it.

  • On the other hand, if return messages (bounces) appear during transmissions, the sendings must be suspended for a longer or shorter period depending on the severity level of the blockage, then resume, if necessary, at a slower pace.

  • Likewise, not using IP / sender for an extended period of time should result in resuming break-in.

The system offers 8 sets of parameters: "defcon3, defcon2, defcon1, warmup, low, mid, high, full", with increasing transmission rates.


  • "Defcon3" corresponds to the highest level of blocking, requiring an approach with the postmaster of the recipient. By default, in this mode, only one message is sent each day to check whether the block has been lifted.

  • "Defcon2" corresponds to a block that requires manual processing for its lifting (eg: CloudMark form).

  • "Defcon1" corresponds to a temporary blocking, due to too many messages sent per unit of time.

  • "Warmup" represents the initial state of the IP / sender when they are put into service, in running-in mode.

  • "Low", "mid", "high" and "full" correspond to the transmission rates as the reputation of the IP / sender is established.

Switching from one of its sets of parameters to another is done automatically according to several conditions:


  • When reaching a sending volume threshold over a given period (eg: “warmup” for 1 week and 5000 emails / day before going to “low”, then to “mid”, etc.)

  • When the volume of mailings over a given period is below a certain threshold (eg: resumption of the "warmup" if less than 100 emails sent in the last month)

  • When bounce messages are received during SMTP transmissions (ex: CloudMark blacklisting message which switches to "defcon2"

the API also offers the possibility of controlling the switch on demand.

The [ipflow # XXX] and [sdflow # XXX] sections contain the sets of sending parameters, respectively by IP and by sender, XXX representing the set concerned (eg: [ipflow # warmup]).

It is possible to define parameter sets for specific IPs or senders, by suffixing the [ipflow # XXX] section with '@' + IP address and [sdflow] with '@' + sender domain name, ie [ ipflow # XXX @ IP] and [sdflow # XXX @ sender].

Regarding instant flow control, the 'threadmax' parameter limits the maximum number of simultaneous SMTP sessions (0 = unlimited), 'chainmax specifies the maximum number of messages sent per SMTP session, and' waittime 'the number of seconds of pause between two SMTP sessions.

Regarding the volume control, two time intervals can be configured with a maximum number of messages sent. 'volttllow' and 'volttlhigh' indicate the number of seconds of the time intervals, while 'volmaxlow' and 'volmaxhigh' indicate the maximum number of sends during the time interval.

NB: the values ​​of the time unit keys are by default expressed in seconds, but can be suffixed by 'm' for minutes, 'h' for hours and 'd' for day (24h).


For example,

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

specifies a maximum of 60 messages per 10 minute period AND a maximum of 3000 messages per day (whereas applied alone, the first parameter would give a maximum of 60 x 6 x 24 = 8640 messages per 24h).

Typically, these parameters make it possible to ensure an optimal flow rate of the stream while respecting daily quotas.

Regarding the control of parameter sets, 'sleepttl' indicates the pause time before the first sending when the parameter set is initially applied only following a message from FLOW ().

The {'flowttlup' 'flowvolup' 'flowup'} and {'flowttldown' 'flowvoldown' 'flowdown'} parameters control the automatic switch between parameter sets based on the volume of messages delivered per unit of time.


For example,


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

indicates that in 'warmup' mode, the system will switch to the [ipflow # low] parameter set after 10,000 messages sent in total over a week.

In the same way,

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

indicates that in 'high' mode, the system will switch to the [ipflow # mid] parameter set if less than 1000 messages are delivered in the last 2 weeks.

NB: if 'flowup' or 'flowdown' are not specified, the default values ​​'up' and 'low' apply, and indicate to pass to the set of parameters of the level immediately higher and lower (ex: 'up' in '#low' changes to '#mid' and 'down' in '#low' changes to '#warmup'), '#wamup' and '#full' constituting the limits of the interval.

NB: during automatic switches, the 'sleepttl' parameter is not applied.

4.1.3. Qualifying SMTP patterns


By default, any error message (except "220 Ok" or "250 Ok") is considered as a soft bounce (temporary error). As such, the job is likely to be the subject of a transmission retry.
Indeed, the SMTP error codes and return messages vary from one mail server to another, and require individual qualification, subject of the [pattern] section.

Syntax: Name_of_pattern = FUNCTION (parameters) SMTP_pattern

'Pattern_name': alphanumeric string of 16 characters maximum ('a' => 'z' + '0' => '9' + dash '-')

'SMTP_pattern': SMTP response message, which can include one or more wildcards '*', which means "at least one character and any character (s)".

FUNCTION (parameters):
SOFT (description): qualifies the job as a temporary error (therefore retryable).
HARD (description): qualifies the job in NPAI (no retry).
SPAM (description): email rejected because content identified as spam (no retry)
GRAY (description, X): qualifies the pattern in gray listing, X being a timeout in seconds before retrying (600s by default).
FLOW (description, #XXX, #YYY)): qualifies the pattern as an indication of blocking or blacklisting. #XXX and #YYY, optional, specify the new IP and sender parameter sets to be applied accordingly.

NB: the parameters 'Nom_de_pattern' and 'description' (16 characters) can be found in the logs and job reports in the 'rfpattern' and 'rfstr' fields.

4.1.4. Special cases

The '.defflow.ini' file contains the default values ​​of the flow control settings for all domain groups.

The profile '@.ini' represents the group of domains that do not belong to any named group. As such, the volumetric quota settings apply to the aggregate of traffic from all domains. However, the 'threadmax' and 'chainmax' parameters remain individual to each domain.

4.1.5. Configuration file <% DM% .ini>

<% DM% .ini>

mx             = List of MX record patterns of the domain group (or relay host)
domain         = Domain name used for initial MX resolution (if Ø => first alias)
cache          = DNS caching option for alias domains (1 = yes). To be reserved for

                 ISP domains. (0)
relay          = Indicates if it is an smtp relay (1 = yes) (0)
port           = IP port of the smtp relay MX (465)
ip             = IP to use for connection to the relay
login          = Relay login
passw          = Relay password
overwrite      = Use login as 'envelopefrom' and 'from' (see API section [smtp]) (0)

[ipflow # XXX]   (XXX Ø Name of the parameter set (ex: 'warmup' ',' mid ',' decfon1 ',…))
sleepttl       = Waiting time, in seconds, before first taking a job when switching to the set

                 number of parameters following FLOW () (0)
threadmax      = Maximum number of simultaneous SMTP sessions (1)
chainmax       = Maximum number of messages sent per SMTP session (0)
waittime       = Waittime, in seconds, between two SMTP sessions (0)
errmax         = Maximum number of consecutive unknown SMTP error messages (0)
flowerr        = Set when reaching errmax (0)
volttllow      = Lower unit of time (0)
volmaxlow      = Maximum number of messages per lower time unit (0)
volttlhigh     = Upper unit of time (0)
volmaxhigh     = Maximum number of messages per higher unit of time (0)
flowttlup      = Duration of the set before UP (0)
flowvolup      = Message volume of the set before UP (0)
flowup         = Set on which to switch (UP) (0)
flowttldown    = Duration of the set before DOWN (0)
flowvoldown    = Message volume of the set before DOWN (0)
flowdown       = Set on which to switch (DOWN) (0)


[sdflow # XXX]          IDEM [ipflow], but for senders instead of IPs
[ipflow # XXX @ IP]     Parameter set for specific IP '
[sdflow # XXX @ sender] Parameter set for specific sender

mnemonic       = FNCT (args) pattern
                 FLOW (desc, ipflow (X), sdflow (Y))
                 GRAY (desc, duration) / SPAM (desc)
                 HARD (desc) / SOFT (desc)

4.2. \Domains\%DM%_alias.csv files

As specified previously, each domain group has an associated alias file, named '% DM% _alias.csv', which lists all the domain names associated with it.

This file, in CSV format, contains two fields: 1 / 'date', in YYMMDDhhmmss format, indicates the date of registration of the domain in the alias list, 2 / 'domain', which contains the domain name.

This file can be enriched manually, although the system automatically manages the detection of new aliases during MX resolutions of destination domains.

4.3. \Domains\%DM%_log.csv files


When the system encounters an unlisted error message (which does not match any of the referenced patterns), it adds it to the @% DM% .log file, for later manual qualification.

'rfsenddate' indicates the recording date of the pattern, 'ref' the user reference of the job, 'rfmailno' the internal system reference of the job, 'rfrecno' the recipient number in the list, 'rfsendip' the IP address from which the sending attempt took place, 'rfmxip' the IP address of the remote mail server, 'rfstp' the protocol step in which the message was received, and finally, 'rfrcv' contains the SMTP response as than received.



Each module records operation traces in the directory D:\Rafale\logs:%module%.txt and %module%.csv, and the main program in D:\Rafale\logs\rafale.txt.

The .txt file contains the module's information and debugging messages, as they appear in the program windows, while the .csv logs each job processed.



Rafale creates, when it is launched, several sub-directories and files, intended for its internal functioning, which must in no case be modified or altered, such as:

  • \mails\: one sub-directory per job with its associated data

  • \queues\: intermodule message queue

  • \system\: internal system variables and counters

The \wwws\ directory represents the root directory of the integrated http server. It contains example pages relating to the unsubscribe process, and can be completed with any type of file (images, documents, various html pages) and sub-directories.



Rafale creates, when it is launched, several sub-directories and files, intended for its internal functioning, which must in no case be modified or altered, such as:

@                A
@                A
@                MX  10 newsletter.rafale.io.
@                TXT ("v = spf1 ip4: -all")
@                TXT ("spf2.0 / pra ip4: -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 ")

To generate a DKIM private / public key pair, use for example 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

The public key, present in the file 'newsletter.rafale.io-dkim-pub.pem', must be copied into the DNS record dkim._domainkey.

The file containing the private key, 'newsletter.rafale.io-dkim-prv.pem', must be copied into the D:\Rafale\keys\ directory, and renamed with the following syntax:

<domain> <space> <selector> <space> <id>.pem

'domain' represents the domain name of the sender, 'selector' the prefix of ._domainkey in the DNS zone ('dkim' here as an example), and 'id', of username in the email address associated with the signature.

To define a default signing key, create a file name starting with a period '.', For example <.def dkim id.pem>

The username in the email address specified in the _dmarc record, must be declared in [rfrelay] dmarcaddr.

Register the sender domain in the various FeedBackLoop programs, and register the notification addresses in [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/

Finally install the Certificates of the sender domains in the Windows Certificates Store.


© 2020 SELF Development