> 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 adria...@ciobanu.name http://pub.mud.ro/~cia +40 788 319 497
