Victor Duchovni:
> On Tue, Jan 26, 2010 at 08:26:15PM -0500, Wietse Venema wrote:
>
> > Then the transport map would look like:
> >
> > example.com atrn:[example.com]
> > example.org atrn:[example.org]
>
> ATRN supports multi-domain requests either explicitly or implicitly,
> in which case the domain -> nexthop mapping is many to one...
>
> > - Each time smtpd(8) receives a valid ATRN command it connects to
> > atrnd(8), passes the customer domain name, and waits for atrnd(8)
> > to respond.
>
> The SASL user name and an optional list of domains, none are specified,
> the full list of domains for the SASL user is implied. Otherwise the
> provided domain list must be a subset of the list of authorized domains.
>
> Under the covers, all the domains must share the same next hop. Simplest
> is one nexthop per SASL user, hence my earlier proposal.
Aha. This of course complicates the user interface - now we need
to maintain a sasl authorization map, a transport map, and that
reduces usability.
If we can assume that one ATRN login can have one domain, no such
complication. If the customer has multiple domains use multiple
logins.
> > Other things to keep in mind:
> >
> > - There need to be generous timeouts before the first delivery, and
> > perhaps smaller timeouts between successive deliveries.
>
> Yes. Though use of a separate transport "atrn" means that "atrn"
> deliveries don't compete for process slots with normal "smtp" deliveries,
> and will only be delayed if the active queue is full, or other ATRN
> deliveries are using up all available "atrn" delivery agents.
>
> > [ATRN design document dated Jun 26, 2005]
> >
> > Below are some notes on what it would take to implement ATRN support
> > in Postfix. This is an updated version of notes that I made before
> > connection caching was added to Postfix.
> >
> > In summary:
> >
> > - Postfix can support ATRN requests with only one domain parameter,
>
> Multiple domains could be supported, if we require a mapping of ATRN
> domains to SASL user based nexthop, in fact the nexthop for this
> transport could simply be the SASL user id, as we never make outgoing
> connections, the connection is a channel with an authenticated user.
Note: this design document did not require a transport map. All it
used was a list of atrn domain names (with the sasl login name on
the right-hand side).
How important is the multi-domain requirement, and why not could
the customer arrange for multiple SASL logins if they really intend
to run a lot of domains in ATRN mode?
> This also solves the authorization problem, you can request a domain,
> if your user name is the domain's nexthop in the transport table:
>
> example.com atrn:[sasluser]
>
> Or something very much like that...
Using login names as next-hop destination? I am not sure I like
this user interface.
First of all we need to determine if multiple domains per login is
really necessary, before uglifying the interface and design.
Wietse
> > - Postfix ATRN support needs only one mandatory parameter that
> > specifies an (ATRN domain name -> SASL login name) mapping,
>
> Yes, which can also be an effective transport table for the ATRN
> domains, with the "atrn" transport always deferred, and traffic
> moving only the flush service...
>
> > One question: how much need is there for this functionality? Most
> > of the infrastructure exists, so it's not a terrible amount of work
> > to implement. ATRN Support adds another notch to the list of RFCs
> > that Postfix implements.
>
> I too am curious about this. Who still has this type of connectivity,
> and why ATRN and not other options? How widely would this get used?
>
> > 3 - Multi-domain ATRN requests
> > ==============================
> >
> > Changing this would introduce a great deal of complexity: Postfix
> > SMTP clients would have to block on a connection cache lookup
> > request, and the connection cache manager would have to know that
> > a client does not return a connection to the cache (perhaps the
> > client has crashed), so that the connection cache manager can inform
> > a blocked SMTP client that the request can no longer be satisfied.
> > All this for marginal benefit, because very few potential users of
> > ATRN are expected to run multiple domains on a dynamic IP address.
>
> I think that associating nexthop selecting with SASL credentials,
> rather than the domain, may solve this too.
>
> > Another limitation of this scheme is that if a customer makes
> > multiple overlapping SMTP connections with ATRN requests for the
> > same domain, only one connection will be used for mail delivery,
> > because Postfix will deliver mail to ATRN domains with an SMTP
> > destination concurrency of only one connection. There is no problem,
> > however, when the customer makes multiple overlapping connections
> > with ATRN requests for different domains.
>
> Yes, it is difficult to scale-up destination concurrency to match cache
> occupancy, there is not a good way to keep the queue manager informed
> of the number of ATRN cache entries for a given destination. This would
> introduce a race between the queue manager and recently spawned delivery
> agents, unless the queue manager could reserve a particular cache slot
> for a particular agent, but that is way too complex.
>
> > Because of this complication, the Postfix SMTP server process has
> > to act as a proxy between the remote customer and the local Postfix
> > SMTP client; instead of entering the SMTP server socket into the
> > connection cache, the SMTP server enters one endpoint of a local
> > socketpair with a large reuse count and expiration time. When the
> > Postfix SMTP client retrieves a connection from the cache it actually
> > gets that end of the local socketpair. All communication with the
> > customer is sent through the Postfix SMTP server process, which
> > also does the TLS encapsulation/decapsulation. After a mail
> > transaction, the Postfix SMTP client caches a good connection with
> > a large expiration time and decrements the connection reuse count.
> > This repeats until the connection expires from the cache, until the
> > customer disconnects, or until there is no more mail for the customer.
>
> The TLS could still be "half-duplex" if the protocol between the local
> SMTP client and the local SMTP server were RPC-like rather than streaming:
>
> WRITE length data
> READ length
>
> The SMTP server would then only read the remote socket at the request
> of the local SMTP client, and this would likely avoid the renegotiation
> issues. This however calls for more complex read/write glue between the
> SMTP server and the local SMTP client. May not be worth the effort...
>
> --
> Viktor.
>
> P.S. Morgan Stanley is looking for a New York City based, Senior Unix
> system/email administrator to architect and sustain our perimeter email
> environment. If you are interested, please drop me a note.
>
>
