OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: ATRN, connection cacheing (was: ETRN too fast!)
From: Wietse Venema (wietseporcupine.org)
Date: Sat Sep 30 2000 - 16:36:25 CDT

Brad Knowles:
> At 10:03 AM -0400 2000/9/30, Wietse Venema wrote:
>
> > With a distributed MTA, one would maintain a pool of outbound
> > connections, and when sending mail, one would grab an available
> > connection rather than creating one, like Postfix currently
> > does.
>
> This is good for ensuring that you make maximum use of connection
> caching, but I don't think it solves the ATRN problem. I also don't
> see how it solves the problem of handling multiple mail servers.

One thing at a time.

If someone connects to the SMTP server, authenticates, and sends
ATRN foo.org, the SMTP server would pass the open connection to a
session manager daemon, and would trigger the "fast ETRN" feature
which by now almost works (*). Unless the incoming queue is congested
by other mail, ETRN or ATRN will cause immediate delivery of mail.

(*) Other people might say: approaches perfection.

By the time an SMTP client process wants to deliver mail to foo.org,
it asks the session manager if it still has an open connection
suitable for delivery for foo.org; if so, the SMTP client re-uses
that connection.

Now, if inbound mail is handled by different systems than outbound
mail, then ATRN won't do much good, because you're talking to the
wrong MTA instance. ETRN would have problems, too.

In the case of ETRN one could somehow forward the request to the
mail sending machines. ATRN just would not work.

        Wietse