From: Dustin D. Trammell
Sent: Wednesday, May 19, 2004 2:21 PM
<...>
Hrm... this active forwarding rather than store-and-forward doesn't
sound like a half bad idea to discuss... What if a forwarder received
envelope information from a client, then opened a new connection to the
forwarding address's recipient mail server with a new envelope. If for
some reason that fails, a temporary failure or reject (depends on the
case) could be generated for the client. If that connection succeeds,
the forwarding mail server gives the client the OK in response to the
envelope info and the client goes ahead with DATA. The forwarder would
then send that data through to the recipient server. The only problem
with this that I can see is some potential latency which would grow
exponentially with every forwarding hop, and the possible ability to
detect which addresses are forwarded based on this latency. In this
scenario, if the recipient server rejects, there is no bounce, the
forwarding server immediately rejects the sending client. If the
recipient server accepts the message, and then it must bounce later, the
forwarding server would still have to handle it based on it's new,
proper envelope it used with the recipient server. Can anyone think of
a way that an 'active forwarding' scenario like this could handle this
condition? How often would a final destination recipient server accept
a message and then bounce it?
Aside from the fact that this changes the intent of MAIL FROM: in RFC2821,
you have just provided the reason that envelopes are not rewritten this way
upon forwarding. Unless the forwarder kept some kind of database or
implemented something like SRS, it would have no place to send DSN's that
came back later. It could forward them to the address in the Reply-To:
header, assuming that was preserved in the DSN, which isn't always the case.
On the other hand, mailing lists _must_ provide new envelopes per RFC2821,
as they are considered to be redistributing mail as opposed to forwarding
it. In a way, it's too bad that the older format:
MAIL FROM: @d, @c, @b, local-part(_at_)a
is deprecated, as that would solve this particular problem.
The idea of on-the-fly forwarding is pretty interesting, but it does present
some challenges. In a multi-hop path, all MTA's must be available at the
same time. This could lead to more frequent temporary failures and delayed
delivery. It also would make mail loop detection an interesting problem, as
all the connections have to be established before anything is transferred,
so you have very little information to work with.
--
Seth Goodman