Added a comment about how to avioid the transport:DOMAIN_PORT kludge. Wietse Venema: > 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.
Instead of using a DOMAIN_PORT kludge which requires "reserving" a TCP port or UNIX-domain pathname per customer, it would make sense to use the existing Postfix connection caching mechanism. The idea is to push an open socket into the scache daemon (with a suitable time to live) under the name of the customer's domain. Then, the Postfix SMTP client would automatically find that open socket and start talking SMTP over it. > 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 > >
