Message Submission Service

The submission service is used by local users to send mails to either other local users, or to other domains on the internet. The service, in turn, transmits mails to the public SMTP server of the recipient domain, delivers them locally, relays them locally, etc. This service is specified by RFC 4409, Message Submission for Mail. It is a variant of SMTP.

If the transmission of a mail to a remote domain fails on the first attempt, then it retries the transmission several times. If it eventually decides that the mail is undeliverable, then it sends a delivery status notification message back to the sender.

A dedicated MSA is useful for people, who are working outside of the office, and whose internet service provider blocks port 25. The service usually runs on port 587. Its address is NOT published in a DNS MX record.

List of configuration files

Configuration files specific to the Message Submission service are located in the MIREKA_HOME/conf/submission directory.

File name	Function
`submission.js`	The primary configuration file of the Submission service. It configures the SMTP server, the filter chain, and most filter parameters. In turn, it imports all the other configuration files of the Submission service. Sections: SMTP server: accepts incoming connections, sends mail transactions to the filter chain filter chain: Filters are responsible for the processing of submitted mail transactions. recipient table: the recipient table used here simply specifies that the service delivers mail to local recipients according to the `local-recipients.js` configuration file, just like the SMTP service. Mails sent to non-local addresses are transmitted to the mail server of the recipient's domain.
`authorized-ip.js`	List of ip addresses or address ranges. Mails can be submitted from these ip addresses without any further authentication. This file is imported by `submission.js`.
`queues.js`	The submission service uses file system based queues to make sure no mails are lost. Until a mail is confirmed to be received by the recipient domain the mail stays in a queue. The queues are managed by transmitters. In the default configuration there are three transmitters and there are three correspongind queues. primaryTransmitter: all mails go into the queue of this transmitter. This transmitter is responsible for the first delivery attempt. dsnTransmitter: if it becomes clear that a mail cannot be transmitted then the transmitter responsible for the mail generates a Delivery Status Notification (DSN) message. This transmitter is responbible for transmitting the DSN messages back to the original sender. retryTransmitter: if the first attempt to transmit a mail (either a regular mail or a DSN message) is unsuccessful, but it seems that the problem is temporary, then the original transmitter handles the message to this transmitter. retryTransmitter retries the transmission several times. If it cannot transmit the mail after a predefined count of attempts, or if it becomes clear, that no further attempt will be successful, then it generates a DSN message and drops the original mail. You have to change the mailer daemon address at the top of the file, to reflect your own domain. Otherwise it is unlikely that you have to change other parts of this configuration file.