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:

1. MTA tries connection to the Vontu Prevent
2. Vontu Prevent immediately opens up connection to next MTA (next hop or reflect mode)
3. If Prevent can't open a connection to MTA, it will fail to open up requested connection from MTA
4. Prevent responds to MTA with SMTP banner
5. MTA sends SMTP EHLO/HELO command
6. Prevent sends SMTP EHLO/HELO command to next MTA and send SMTP 200 code to initiating MTA
7. Repeat Steps 5 & 6 for MAIL FROM, RCPT TO, DATA SMTP commands
8. At this point, the MTA sends to Prevent the full message for analysis. Prevent buffers this message
   and waits for the MTA to send the '.' to close this message
9. Once the '.' command is received by Prevent, Prevent will start to process the message. If the message
   doesn't violate any policies. It will be relayed to the next MTA, by completing the SMTP connection and send
   the '.' command. If the message does violate a policy, Prevent hard closes the connection. If as a result a modified message is being generated, Prevent will reconnect to the next MTA and send the newly generated message.

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.