Mail Gateway delivery
Mail queued for delivery are moved to the outbound queue. This queued processed by the mailqueued process which delivers messages according to their mail transport profiles. A mail transport (Mail Gateway → Domain → Outgoing) defines rules such as where to deliver the message, retry delays/counts etc.
Contents |
Send to server
The two most common scenarios for messages delivery is that either you know where to send the message (hostname or IP-address) or you would like to use what we call "lookup-mx".
Lookup MX
The lookup-mx directive will make the appliance resolve the MX (or A/AAAA) record and try to figure out where to deliver the message. It is primarily used outbound delivery. But It may be used in smoe incoming scenarios as well.
The lookup-mx has two additional advanced features. It can append a zone prefix and you may specify which DNS server to use for all DNS queries, if you for some reason don't want to use the system-wide default.
In eg. larger "point-your-mx-to-us-and-we-scan" hosting installations, instead of adding a transport for each customers real mail server. You may trick the lookup-mx command to do look ups against a DNS server storing this information and get the MX you want.
lookup-mx:zone=customer.example.org;query=ns1.example.org,ns2.example.org
Lookup MX by appending a ZONE
The SPG/VSP may automatically append a zone prefix to all DNS queries for a transport. This is useful if you want to store MX transport information in your existing DNS server. You should be aware of that anyone who knows your "system" may find your customers real mail server, therefore in bind you may restrict a zone to only the SPG/VSP.
lookup-mx:zone=customer.example.org
Lookup MX using alternative DNS servers
If you're using an alternative DNS server, there is no need to put the domain in a specific zone. You may use the example above as a reference but it is not a complete working configuration.
lookup-mx:query=ns1.example.org,ns2.example.org
Retry and Give Up
If the SPG/VSP failed to deliver a mail it will be queued (Mail Gateway → Activity → Outgoing) for a delivery at a later time depending on the "Retry Delay" and "Retry Count" settings. Once the Retry Count is exceeded the SPG/VSP can either Generate a DSN (see the "Generate DSN" setting on the mail transport profile) or just discard the mail and do no further actions. The RFC for SMTP propagates long delays and large retry counts; that is since the SMTP protocol is a very old protocol and back in the days of dial-up internet mail servers was not always online, so large values prevented mails from being lost and that they had to be resent all the time.
We think it's a good idea to lower these values to have at most 1-2 days before giving up. If you know your mail server will be down for more you can always pause the delivery process in the SPG/VSP; and once the server is back online you can continue like nothing happened.
Values are given in minutes. See calculations on table below
| Retry Count | Retry Delay | Example | Total time |
|---|---|---|---|
| 30 | 60,120,180 | 60,120,180,180,180,180... | 60+120+(180*28) = 87 Hours ~ 3.5 Days |
Prioritized Queue
By the mailqueued process, all messages are treated alike. That it normally not a problem (what so ever). But in the cases where you eg. are sending large outbound mailing lists you may want to eg. prioritize cooperate inbound and outbound messages.
If there are messages that matches a prioritized queue, they will be sent before any other message. That said, setting all queues as prioritized has the same effect as disabling the feature.
You should not use this feature if you do not have a problem which queue delays.
TLS Certificates
You may choose to trust and verify a receiving server. Do so by setting the TLS setting to "Verify" and install the public key according to the PKI documentation.
SASL Authentication
SASL may be used outbound. See the Mail Gateway SASL documentation.
