5. JSON OBJECTS

​

"Stamp" Object:

​

The system returns the result of the campaign submission request in the "buffer" section. The "rfmailno" field represents the internal campaign reference number through which all subsequent operations can be performed: request for report, statistics, rescheduling, suspension and resume, etc.

​

"Job" Object:

​

For transactional messages :

The "timeout" parameter indicates the maximum time in seconds that the system retries transmission before returning a 451 9.X.Y error.

The "maxhop" parameter specifies the maximum number of routes that the system is likely to use to perform its transmissions.

​

For campaigns :
If "datestart" is not specified, immediate start.

If "datestop" is not specified, the campaign will stop after the last retry cycle.

​

"Header" Object:

Depending on forced_from_addr, granted_from_addr and default_from_addr parameters, defined in the configuration of the user account, the sender email address ( { "from" : { "addr" : <email>... ) is likely to be altered according to the following rules:

​

- if forced_from_addr is set, it overrides "addr". Note that the address supports wildcards for the username part of the address, for example:

​

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

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

     =>  From: <info@mysender.com>

​

- if granted_from_addr is defined and contains one or more patterns, the system verifies that the email address matches at least one of the patterns, otherwise, rejects the request.

​

"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@*"

​

- if default_from_addr is defined and "addr" isn't, it overrides it. Note that the address supports wildcards for the username part of the address, for example:

​

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

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

     =>  From: <info@mysender.com>

​

Two reserved domain names, "@rdns" and "@def", allow to indicate to the system to use respectively the ReverseDNS of the sending IP, or the default domain name associated with the sending IP in the configuration, for example:

​

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

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

     =>  From: <info@example.com>

​

​

The "unlst" field generates a 'List-Unsubsribe:' header in the headers of sent emails, which can contain two types of links: an smtp mailto for asynchronous unsubscriptions (value "smtp"), or http for a synchronous unsubscription ( "http" value), or both, chosen by the receiving system ("both" value).

The character set indicated in "charset" specifies the destination encoding of the messages (def: "utf-8"). Reminder: character strings in a JSON file must be in native utf-8 format.

​

"XXXbody" Object:

 

It is necessary to have at least one of the three valid bodies, txt, htm or amp.

Bodyparts of undeclared sections are not inserted, and any valid combination is allowed: raw txt only, htm only, txt/htm, htm/amp, txt/htm/amp.

​

"Recipients" Object:

​

For transactional messages, only the "toaddr" key is used to define the email address of the recipient of the message.

​

In the context of a campaign, the system uses the list of recipients specified by the "path" variable, and . To customize the "to" field for each recipient, indicate a single entry in the "header":

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

If "testaddr" contains at least one valid email address, the system considers that it is a test sending, for validation on internal emails before sending to the real final recipients list.

 

In order to ensure that the customizations are perfectly rendered, the system merges the emails with the original data from the recipients list (in particular the custom fields), but delivers them only to the test email addresses. In this configuration, the subject of the email is prefixed with "[TEST]", and all unsubscribe functions are disabled.

 

If "checkaddr" indicates at least one valid email address, the system considers it to be an IP status check mailing. Its operation is identical to test emails, except that the system sends the message to each recipient from each outbound ressource.

 

In the list of campaigns, the "type" field indicates the type of entry, with the values:

• ‘T’ : Test

• ‘S’ : Campaign (multi recipients job)

• ‘P’ : Transactionnal m essage (single recipient job)

"Tracking" Object:

 

The parameters of this object are likely to be set at the user account configuration level, and therefore cannot be modified at the routing order level.

If "domain" is not specified, the system uses the default one configured in the user account (if not specified, the system uses the ReverseDNS of the sending IP. If a domain is specified, an 'A' type record in its DNS zone must point to one of the IP addresses listening on port 80 of the server.

​

The "open" field, for opening tracking options, can have three values: 'disable': no tracking is performed; 'pixel': the link to a white 1x1 image is inserted in the body html code; 'image': the system performs a URL redirection on the first <img…> tag found in the body html code.

​

The "mirror" field is optional, it can specify an external URL for the mirror page of the email sent, the system natively generating personalized and tracked mirror pages on the fly from the body html.

​

The "unsub" and "uncfm" fields can specify external URLs for the unsubscribe and unsubscribe confirmation pages, but are usually set in the user account configuration. URLs can also be local, with a path relative to the application's \wwws directory.

​

"Routing" Object:

​

The parameters of this object are likely to be set at the user account configuration level, and therefore cannot be modified at the routing order level.

 

The "envelopefrom" field can contain three specific values:

• "@verp" (Variable Envelope Return Path), which generates a unique bounce email address for each recipient with the RDNS of the sending IP as the domain, used in 'MAILFROM:' of the SMTP session.

• "@from", i.e. the value given in "header": { "from": "addr" }.

• "@mailfrom", in case of SMTP relay only, the original value of MAIL FROM:<> in the session

​

The "outbound" field is used to indicate the outbound resources authorized for sending: ranges of public IP addresses registered locally on the server, Cloud IP addresses (Azure / EC2), static or dynamic, or even an SMTP relay third party, such as that of an ISP.

​

Note that it is just as possible, for Cloud IPs, to directly specify the IP addresses if they are known, as well as the name of the @gateway configured on the system to be used. In this case, all the virtualized IPs associated with the @gateway will be used.

 

If "outbound" is not specified, the system uses all the resources declared as authorized in the user account.

​

Depending on the forced_outbound, granted_outbound and default_outbound parameters, defined in the configuration of the user account, the configured route is likely to be altered according to the following rules:

​

- if forced_outbound is defined, it ovverides "outbound" :

​

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

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

     =>  "outbound" = "@azure"

​

- if granted_outbound is defined and contains one or more IP ranges or @gateway names, the system checks that all the routes specified in "outbound" are present.

​

"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

​

- if default_outbound is defined and that "outbound" isn't, it overrides it.

​

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

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

     =>  "outbound" = "192.168.0.6"

​

The "Routing" object can be suffixed with a domain group name to specify that delivery settings are specific to that group.

​