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.
> 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.
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...
> - 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.
