Integrating Everything

https://slimta.github.io/en/latest/_static/reception-to-delivery.png

Diagram of an Envelope object’s path from reception to delivery.

Piecing together the building blocks described in previous section is the last crucial step in setting up your MTA. Nearly everything in slimta starts with an Edge service which receives messages. They hand messages off to a Queue service which talks to a QueueStorage object to persistently store messages. The queue initiates delivery attempts with a Relay object.

Types of MTA Servers

If you read the Terminology page, there are MTAs, MDAs, MSAs, as well as other special configurations like Smart hosts, SMTP proxies, or Mail hubs. Depending on how you sub-class the different building blocks of a slimta MTA, you can pretty much handle any of these configurations.

  • MSA: An MSA is all about taking a message from a mail client like Thunderbird and delivering it to its next hop on the Internet. Check out the Mail Submission Agent page.

  • MDA: An MDA takes messages from the Internet and delivers them localy to something like maildrop or dovecot. Check out the Mail Delivery Agent page.

  • Smart Host: A smart host takes messages and delivers them to a specific destination, rather then dynamically looking up the recipient’s destination. Use a StaticSmtpRelay object.

  • SMTP proxy: An SMTP proxy skips the Queue altogether, taking Envelope from the Edge and directly attempting delivery with a Relay and returning the success or failure back to the edge client. SMTP proxies are not yet supported by slimta, but they are on the radar.

  • Mail Hubs: A mail hub is a pretty generic term, but one particular use could be a dedicated spam scanner. It receives messages by any Edge, calls the SpamAssassin policy, and delivers the result to another MTA with a StaticSmtpRelay for further processing.