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.
