Thanks for bringing this to our attention, we'll review these findings and update the documentation accordingly. As to your questions on number 3, I'd like to provide some answers:

DNS Caching: This will speed up delivery of messages as SmarterMail will no longer need to initiate an external DNS lookup during delivery sessions if it already has the information cached in memory. The speed increase would be minimal I would expect, unless you handle a lot of external email. 

Enable Remote Bounces: This restricts the bounce messages to internal/external users, and enabling this depends on your specific environment. Remote bounces can be very beneficial, but can also be a source of spam issues as spammers will frequently use bounce functionality against mail server administrators. 

Hello,

The question about DNS caching was of our interest too. Can I ask how long the DNS caches last ? is there a configurable cache expiration value?

The thing is that if the DNS replies are cached, what happens if a service provider changes it's DNS entries for their mail service and therefore the local cache keep the old value ?

Is the cache used for MX lookups ?

Thanks a lot for your answers.

Hello Nicolas, and thank you for following up as these are definitely interesting questions. I was not sure on the duration of cached lookups so I checked with development and was advised that we cache DNS values based on the DNS value's TTL value. When adding MX records to DNS the Time To Live must also be configured, and SmarterMail follows this value in caching results. One way to avoid any DNS caching related issues, and allow yourself a little more control over caching and timing is this: 

- Set up an internal DNS server with caching functionality that you can control the timing on.

- Set up one of the two DNS server addresses in SmarterMail to use this internal mail server, and disable DNS caching. 

That would allow your DNS server to poll and cache MX lookup values, and would give you control over how long those caches exist and under what conditions to flush them and acquire a fresh value. 

As to your question on what happens if a provider changes their MX records, and SM is holding the cached value; in this case SM would first attempt delivery to the address it has cached in memory. If this fails it would either attempt delivery on the next priority MX record, and if there are none, would save the message in the spool for retry at a later time. Hopefully by that point the MX records would have updated as well.