adrian ilarion ciobanu:
> No matter how hard I try not to, I keep seeing similarities between
> ETRN and ATRN.
In both clases the client connects to the standard SMTP port. The
biggest difference is that ETRN creates new SMTP connections for
delivery, whereas ATRN delivers over the existing connection.
> revisiting (3.), I picture this postfix setup that may be a classic
> for ETRN/ATRN: ETRN-enabled domains (if any) would have a normal
> transport definition and ATRN-enabled domains would have a transport
> of atrn:[localhost]:DOMAIN_PORT. When ODMR service accepts the
> ATRN request it will hookup a listener on localhost:DOMAIN_PORT
> and call flush for the requested domain. The listener will simply
> proxy the data to the client's connection (without QUITs until
> last domain requested gets to be fully processed).
This requires reserving one DOMAIN_PORT for each customer, and a
Postfix SMTP client concurrency of exactly 1. Since you're using
TCP, that would limit the setup to ports 1024..65535, or 64512
different customers.
But there are plenty other applications that want to bind to the
localhost interface, such as SMTP-based content filters, HTTP-based
servers such as CUPS printer management, and so on. UNIX-domain
sockets would provide a more private name space.
It is to be expected that the customer will log in over a TLS
session, so the SMTP server needs to open a socket to an ATRN server
and tell it what customer to receive mail for. The ATRN server then
does all the SMTP-specific stuff, like sending "220 servername" to
the Postfix SMTP client, and dropping QUIT commands from the Postfix
SMTP client so that the connection is not closed too early. The
Postfix SMTP server just reads/writes bytes between ATRN daemon
and customer until both parties close a connection, or until some
error or timeout (while respecting the built-in watchdog timer and
other safety mechanisms).
Customer <--> Postfix SMTPD <--> ATRND <--> Postfix SMTP client
I would not duplicate (or somehow turn into a library) parts of
the Postfix SMTP server (welcome, ehlo, auth, starttls, etc.).
Duplication complicates code maintenance, and librarification
involves a great deal of change to mature code that requires a huge
amount of testing for which I do not have the time. Instead, I
would just add a few lines of code to the Postfix SMTP server to
connect to the ATRN daemon and to shuttles bytes between the ATRN
daemon and the customer; this code would be completely encapsulated
so it would not interfere with the operation of the Postfix SMTP
server proper.
> And second, is the idea of reusing flush(8) in ATRN (as described
> above) having some flaws that I failed to see?
The flush(8) service is the only way to go, because the Postfix
design does not allow for multiple queue managers. The alternative
would be to deliver all ATRN customers to a holding area outside
of Postfix and roll your own SMTP client (as with qmail's ODMR).
With a single queue manager, there may be a delay between the ATRN
command and mail coming out.
Wietse
