How does SMTP Prevent ensure no emails are dropped in a worst case scenario?
What mechanisms are in place to ensure that no message is being dropped en route?
In general SMTP Prevent is designed in a failsafe manner, to ensure that no email is dropped.
Here, as reference, is the communication between the MTAs and Prevent:
At #9 the message count is increase.
If there is at any stage a message not fully sent to Prevent, eventually a timeout will occur and the connection to the next hop MTA dropped. The originating MTA will (due to the dropped connection) re-establish a connection and will resend the failed message. Ultimately , this results in an environment that only fully handed off messages count and failed messages will be resent from the MTA end. Thus it will be guaranteed that no email will be lost in transit.
As you can see, once an email is sent, it ends with a final ‘.’ (dot). Once the dot has been forwarded to the next hop MTA the message is concluded and delivered. At that point the next hop MTA responds with an acknowledgement and this will be responded back to the originating MTA.
On the originating site, per RFC the communication will be only considered fully concluded and the email delivered if the final reply has been received, which only will be sent back from Prevent, once the email has been acknowledged by the next hop MTA.
So if there is any disruption the originating MTA will consider the email not delivered and will resend it or will fail-open.
So the outlined mechanism always ensures that no email is being lost on our end.