Synchronized Forwarding in Ibex Mail

Messages to be forwarded to another server are never enqueued locally; instead, Ibex Mail acts as an intelligent proxy between the inbound SMTP connection and a new connection to the remote server, rewriting message headers “on the fly”. An earlier reference to this idea appears here.

Because Ibex Mail never assumes responsibility for delivering these messages it never needs to generate bounce messages for nonlocal users. This means that an Ibex Mail server can never be a source of any amount of backscatter; bounce messages are only sent to users who use the Ibex Mail server as their own outbound MTA.

Example

Here is an example, where user user@sender.com is sending mail to user@forwarded.com (running Ibex Mail), who has forwarded his mail to user@destination.com:

1. MTA for sender.com makes an SMTP connection to forwarded.com attempting to deliver a message.

2. After sender.com completes the SMTP DATA command, but before returning a positive response, forwarded.com makes an outbound connection to user@destination.com and attempts to deliver the message (with headers appropriately updated).

   • If the delivery to user@destination.com fails with an SMTP error code from destination.com, forwarded.com will repeat the same SMTP error back to sender.com via the still-open connection.

   • If the delivery to user@destination.com fails without an SMTP error code (for example, if destination.com is unreachable), forwarded.com will report an appropriately descriptive SMTP 4xx (“try again later”) error code to sender.com.

   • If the delivery to user@destination.com succeeds, the SMTP success code is reported back to sender.com.

Disadvantages

The only (minor) drawback of this approach is that the sending MTA, the forwarding MTA (Ibex Mail), and the receiving MTA must all be reachable simultaneously in order for delivery to occur. With a scheme in which the forwarding machine accepts responsibility for a message it is possible for delivery to occur in a scenario where the sending and receiving MTAs are never online simultaneously (but each is occasionally online at the same time as the forwarding MTA).

In today's modern Internet, situations such as the above are vanishingly rare, and almost always symptomatic of a malfunction which ought to be fixed.

rendered from WIX