ATRN reloaded
in [Postfix]
|
Prev: Preventing outgoing local mail being delivered to certain domains
Next: multiple IPs in and out
From: Wietse Venema on 26 Jan 2010 20:26 adrian ilarion ciobanu: > > > > You associate a fixed nexthop with each authenticated client, and their > > entire set of domains. You flush either all their domains, or the subset > > they requested. The scache entry is for the client-specific nexthop, not > > the recipient domain. > > > > example.com atrn:[client1.atrn.invalid] > > example.net atrn:[client1.atrn.invalid] > > example.org atrn:[client2.atrn.invalid] > > > > The scache slot is for "[client1.atrn.invalid]". > > Got it. I mixed scache manpage missreadings with flush records. If the architecture is like this: Customer <--> smtpd(8) <--> atrnd(8) <--> smtp(8) Then the transport map would look like: example.com atrn:[example.com] example.org atrn:[example.org] with in master.cf: atrnd unix - - n - - atrnd atrn unix - - n - - smtp -o smtp_connection_cache_destinations=static:all -o smtp_connection_reuse_time_limit=0 - smtpd(8) can rate-limit the ATRN command via the anvil(8) server. - 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. - atrnd(8) either rejects the request (perhaps because it's still proxying mail for that domain) or stores a socket with scache(8) under the customer domain name. - Once mail starts flowing, smtp(8) retrieves that socket from scache(8) and saves that socket to scache(8) upon each delivery completion. Other things to keep in mind: - There need to be generous timeouts before the first delivery, and perhaps smaller timeouts between successive deliveries. - smtpd(8) needs to reset its watchdog timer periodically otherwise bad things happen when the ATRN session lasts more than $daemon_timeout seconds. - smtpd(8) uses two atrn client APIs that encapsulate interaction with atrnd(8), namely, sending the customer domain information, and pushing bytes between customer and atrnd(8) without any understanding of the content. - By playing byte-pusher-in-the-middle, smtpd(8) processes TLS messages as soon as they become available, so there is a possibility of enabling the TLS session renegotation bug. For background on this see http://www.postfix.org/wip.html. Below is a preliminary design document about implementing ATRN in Postfix. In this document I try to minimize the number of parameters that need to be changed from their defaults. To achieve that goal I introduce a new address class with its own main.cf settings. Before a line of code gets written, I would like to see an updated version of that design document. It needs to consider the choices that need to be made. Finally I have introduced earlier in this thread the requirement that smtpd(8) be changed only minimally, and that most of the ATRN smarts are implemented outside smtpd(8), by a separate daemon. This principle has worked well in Postfix. Whenever a major feature is added, don't mess up the existing programs. Instead, write a new daemon process and a client library module that implements a narrow protocol. This effectively guarantees that the new feature will have zero impact on Postfix performance and reliability except when a site decides to use that feature. Wietse [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, - Postfix can support ATRN over TLS encrypted sessions, - Postfix ATRN support needs only one mandatory parameter that specifies an (ATRN domain name -> SASL login name) mapping, - Postfix ATRN support needs one optional but recommended parameter that specifies a table for recipient address validation. - ATRN configuration is kept to the minimum by introducing a new "atrn" mail delivery transport with its own address class (in addition to the local, virtual alias, virtual mailbox, and relay address classes) with its own default configuration parameters. - Migration from ETRN <=> ATRN is not transparent. 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. Wietse Table of contents: 1 - ATRN Protocol basics 2 - Implementing ATRN with the Postfix connection cache 3 - Multi-domain ATRN requests 4 - Interactions with TLS 5 - ATRN User interface 6 - Migration between ETRN and ATRN 1 - ATRN Protocol basics ======================== ATRN is described in RFC 2645 as: ON-DEMAND MAIL RELAY (ODMR), SMTP with Dynamic IP Addresses. The basic operation is easily explained with the following quote: RFC 2645 section 5.2.1. ATRN (Authenticated TURN) Unlike the TURN command in [SMTP], the ATRN command optionally takes one or more domains as a parameter. The ATRN command MUST be rejected if the session has not been authenticated. Response code 530 [AUTH] is used for this. The timeout for this command MUST be at least 10 minutes to allow the provider time to process its mail queue. The protocol looks like this (P = provider, C = customer). P: 220 EXAMPLE.NET on-demand mail relay server ready C: EHLO example.org P: 250-EXAMPLE.NET P: 250-AUTH CRAM-MD5 EXTERNAL P: 250 ATRN Once the client has authenticated, the conversation proceeds: C: ATRN example.org,example.com P: 250 OK now reversing the connection At this point, the customer becomes the server, and the provider becomes the client: C: 220 example.org ready to receive email P: EHLO EXAMPLE.NET C: 250-example.org C: 250 SIZE P: MAIL FROM: <Lester.Tester(a)dot.foo.bar> C: 250 OK P: RCPT TO: <l.eva.msg(a)example.com> C: 250 OK, recipient accepted ... P: QUIT C: 221 example.org closing connection All this makes sense only after the client has authenticated, otherwise ATRN could be used to steal mail. 2 - Implementing ATRN with the Postfix connection cache ======================================================= Postfix is a modular mail systen. Different processes implement the SMTP server function, the queue manager/scheduler function, and the SMTP client function. ATRN is in apparent conflict with this division of concerns. ATRN provides one customer-initiated TCP connection between customer and provider, over which mail is to be delivered to the customer. This was not possible with Postfix before connection caching was implemented. The reason is a conflict in connection management: the Postfix SMTP clients always attempted to make their own connection to the addresses listed for the recipient domain, and were unable to (re)use an existing connection. This is where SMTP connection caching comes to the rescue. If the SMTP server makes an SMTP connection cache entry for the connection that was initiated by the customer's domain, and if Postfix is configured so that at most one SMTP client process tries to deliver mail to the customer domain, then this Postfix SMTP client process can use the connection that the SMTP server entered into the connection cache. The cached connection can be used multiple times; it is not tied to any particular SMTP client process. Postfix ATRN can build on the code that already implements support for ETRN; this avoids the need to search a potentially large number of queue files. Why not implement a dedicated ATRN queue, or even one queue per domain? One message can have multiple recipients, and Postfix does not support queue file splitting. 3 - Multi-domain ATRN requests ============================== The first complication is that ATRN allows the client to specify multiple domains in the ATRN command. This is a problem for Postfix. Suppose that the client sends two domain names with the command "ATRN X,Y". Once the cache manager gives the connection to a Postfix SMTP client that has mail for domain X, that connection is no longer in the cache. The Postfix SMTP client with mail for domain Y receives a "not found" reply from the cache manager. Although the Postfix SMTP client could be configured not to make SMTP connections by itself, it would have no way to find out when, if ever, a cached connection becomes available. 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. 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. 4 - Interactions with TLS ========================= The TLS implementation introduces one additional complication. TLS is implemented inside Postfix SMTP server and client processes; it is not possible to transfer TLS state from one process to another without closing the connection. Note that this complication would not exist had Postfix TLS support been implemented outside the SMTP client and sever processes; in that case we would simply pass around a local socket that connects to the TLS proxy process. 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. 5 - ATRN User interface ======================= Setting up ETRN is as simple as listing the domain in relay_domains, and providing a valid recipient list. It would be nice if ATRN setup is just as easy. Setting up ATRN requires: - Authorization table with (ATRN domain name -> SASL login name) mapping. Without this table any SASL user could invoke ATRN and steal mail. - Postfix needs the list of ATRN domains to disable spontaneous creation of connections for ATRN domains, and to defer delivery if no connection is cached for such a domain. - Postfix needs a dedicated "atrn" transport in master.cf, with a main.cf destination concurrency of 1. This transport can be installed as a default entry in future master.cf files (the alternative is to add a completely new scheduling mechanism in the form of a per-domain concurrency map). - If we use a dedicated "atrn" mail delivery transport, then we either need transport map entries for all ATRN domains (ugly), or we need to introduce an "atrn" address class. The latter is preferable, but implies that ATRN domains are in a different address class than ETRN domains (which are in the relay domains class). See also the section on migration issues below. In conclusion, ATRN support can be configured with one configuration paramater, and with a bunch of defaults that never need to be changed: Non-default entries: this is the only thing that you must specify: main.cf: atrn_domain_login_maps = type:table (this provides the ATRN domain name -> SASL login name mapping) Optional, but highly recommended: atrn_recipient_maps = type:table (this provides the list of valid recipients) Default entries, never to be changed: main.cf: atrn_destination_concurrency_limit=1 atrn_domains = $atrn_domain_login_maps (this uses the authorization table as a list of ATRN domains) atrn_transport = atrn fast_flush_domains = $relay_domains $atrn_domains master.cf: atrn unix - - n - - smtp -o smtp_session_cache_only=yes So, the upshot is that ATRN can be done with one configuration parameter that specifies the (ATRN domain name -> SASL login name) mapping, and an optional table for recipient address validation. With ATRN sesions proxied by the Postfix SMTP server process, Postfix can handle ATRN requests that specify a single domain, even over STARTTLS sessions. This will work well as long as the active queue is not saturated, so that ATRN connections won't expire from the connection cache before Postfix finishes delivering mail for the domain. 6 - Migration between ETRN and ATRN =================================== The above implementation is elegant but has one down-side: a given domain cannot use both ETRN and ATRN, which complicates migration. Migration from ETRN to ATRN, or vice versa, requires that customer and provider make the transition at the same time. On the provider's end, the following steps are taken when migrating a customer from ETRN to ATRN: 1 - Copy the customer's valid recipient list from relay_recipient_maps to atrn_recipient_maps. Do not update relay_recipient_maps. 2 - Populate the atrn_domain_login_maps table with (domain->login) mapping to prevent theft of mail. 3 - Remove the customer domain from relay_domains, to stop nagging warnings from Postfix that the domain is listed in multiple address classes. 4 - Remove the customer's valid recipient list from relay_recipient_maps. The migration from ATRN to ETRN is as follows: 1 - Copy the customer's valid recipient list from atrn_recipient_maps to relay_recipient_maps. Do not update atrn_recipient_maps. 2 - List the customer domain in relay_domains. 3 - Remove the customer domain from atrn_domain_login_maps, to stop nagging warnings from Postfix that the domain is listed in multiple address classes. 4 - Remove the customer's valid recipient list from atrn_recipient_maps. Wietse
From: Victor Duchovni on 26 Jan 2010 22:25 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.
From: Wietse Venema on 27 Jan 2010 07:21 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. > >
From: adrian ilarion ciobanu on 27 Jan 2010 13:54 > 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. I'd say the sasl authorization map IS the transport map. The sasl authorization (not the authentication that is ofcourse outside atrnd) can be resolved when atrnd does the lookup domain<->user transport looks like: domainA atrn:user1 domainB atrn:user1 domainX atrn:userN my 2 cents is the administrator only needs to properly define the atrn transports and no other maps. the one to one map adds headache on the customer side which i find it to be undesirable. one would need to do extra handshakes with the customers to cheat the specification. i smell problems with windows exchange and some sysadmin bloodshed. smtpd does normal sasl auth and forwad atrn chats to atrnd which will handle atrnd parameters , doing lookups in transport file to map the sasl user (or not). where's the extra sasl authorization map? > > Using login names as next-hop destination? I am not sure I like > this user interface. well the next hop in the case of atrn IS the connection authenticated for the user more than anythin else. i believe there's nothing else that fits better as a next hop than the username. the transports atrn entries management does not scratch the brain. as a sysadmin, i map the domain to be delivered by atrn to the authenticated user userN. i like Victor's idea. > > First of all we need to determine if multiple domains per login is > really necessary, before uglifying the interface and design. I can't say something gets uglified but I dont have enough postfix development-level knowledge to clearly state the opposite of your affirmation. > > 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? ETRN is more than ok but there's the case of users having incoming connections filtered by the ISP for various reasons. I can't say this is an everyday problem or that there are many users praying for atrn capable MTAs. another case against ETRN is the dynamic ip addressing which one would say that it could be solved with dynamic dns but dynamic dns is not exactly implemented by some specification. it totally depends on dns caches not respecting ttls, dyndns provider's free will and some butterfly getting stoned in cairo. ofcourse, there are many ways to implement fixes external to postfix but other things gets complicated (maintaining tunnels, cursing dynamic dns providers, etc). I dont know if i would vote for atrn inclusion in the main tree. -- adrian ilarion ciobanu adrian.i(a)ciobanu.name http://pub.mud.ro/~cia +40 788 319 497
From: Victor Duchovni on 27 Jan 2010 14:00 On Wed, Jan 27, 2010 at 12:54:25PM -0600, adrian ilarion ciobanu wrote: > > Using login names as next-hop destination? I am not sure I like > > this user interface. > > well the next hop in the case of atrn IS the connection authenticated > for the user more than anythin else. i believe there's nothing else that fits > better as a next hop than the username. the transports atrn entries management > does not scratch the brain. as a sysadmin, i map the domain to be > delivered by atrn to the authenticated user userN. i like Victor's idea. Thanks. If multiple domains for the same user or more importantly over a single ATRN session need to be supported: connect; ATRN request all domains; disconnect NOT foreach-domain X; connect; ATRN request X; disconnect; done then a single transport mapping that is simultaneously the authorization table for ATRN (aka ODMR) would do the job. In the "atrn" address-class, the authorization table is also the relayhost table: domain authorized_login example.com user1 domain nexthop example.com user1 The RHS could instead have a full transport:nexthop syntax if that were more advantageous. > > > > 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? > > ETRN is more than ok but there's the case of users having incoming > connections filtered by the ISP for various reasons. I can't say this > is an everyday problem or that there are many users praying for atrn > capable MTAs. I am not looking for an ATRN vs ETRN comparison, I know all the issues with ETRN. Rather, the question is who are the potential users of ATRN? How much real demand is there for this, and why? Does any Edge MTA other than Microsoft Exchange support the client-side of ATRN? Are there enough ATRN-dependent Exchange shops with part-time or dynamic Internet connections to justify this architecture? Does Postfix also need an ATRN client? Is supporting ATRN worth the effort? It is an interesting problem to solve, a cute intellectual puzzle, but perhaps our energies are best directed elsewhere? > ofcourse, there are many ways to implement fixes external to postfix > but other things gets complicated (maintaining tunnels, cursing dynamic > dns providers, etc). I dont know if i would vote for atrn inclusion in > the main tree. Well, this would not be a simple outside the main tree add-on: - New address class required. - Some tweaks to the connection cache service. - Some tweaks to the SMTP delivery agent (when running in the "atrn" personality, defer when no cached connection is available, never try to connect to the nexthop directly). - Tweaks to the SMTP server to support a proxy mode after the ATRN command is accepted. One could clone and customize smtpd, but then the body of code that is common with smtpd would be maintained twice, this worked poorly with smpt(8) and lmtp(8), and things are better now that the two are one. So I think that either this is mainstream Postfix, or you are completely on your own with private patches that are unlikely to be suitable for use anywhere else. -- 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.
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: Preventing outgoing local mail being delivered to certain domains Next: multiple IPs in and out |