> 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.
So I should understand that RFC specifying port 366 as the ODMR port is just a "should" and not a "must"? And the odmr client is supposed to try ATRN on smtp port? The rfc is exactly not so clear on if this is a requirement or ... plus i see odmr ports poisoning my etc/services file. Now I don't know what the smtp client expectations are, but I assume windows will use port 366 :) > > UNIX-domain > sockets would provide a more private name space. I agree. And somehow faster, by dropping the tcp stack. But in this case one should use lmtp service for honoring flushes and that would involve some more headache on proxying the data to client (lmtp to smtp translations). Or is it possible to use unix addresses with smtp (manpage says no)? If not, no one stops me to alias the loopback interface (127.0.0.2, 0.0.3, ... ). Although it sounds like a windows hotfix. > > 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 understand, you would rather have some operations (like data proxying) duplicated instead of risking more bugs in the core and thats why there's a new ATRND service. The less code added to SMTPD, the less the chance of new bugs. The only problem i see with this is it only gets more complicated. If I would really want to free smtpd from ATRN code then after a successfull authentication the ATRN specific talk should be totally routed to ATRND service and forgotten, by passing the socket descriptor. I think i already picture VERY unexpected bugs only from data proxying if ATRND starts acting up and SMTPD is respectful. This is why I wanted to reuse some SMTPD code in a totally decoupled ATRN service :) my scenario, now that I'm talking SMTPD patching: smtpd: if client_auth OK && request_policy_check OK then: smtpd: listen(transport_socket) #be prepared for local smtp deliveries smtpd: begin_foreach_domain_loop smtpd: send_flush_request(domain) #this is just etrn flush request multiplied smtpd: end_foreach_domain_loop #this is where the time gets spent smtpd: proxy from transport_socket to client_socket (filter quits, additional helos,etc) everybody_ends_conversations yours (did I get it right?): #request_policy_check sits here pretty neat, still (can reuse etrn policy check service) smtpd: if client_auth OK && request_policy_check OK then: smtpd: connect(ATRN service) smtpd: send userinfo atrnd: listen(transport_socket) atrnd: begin_foreach_domain_loop atrnd: send_flush_request(domain) atrnd: end_foreach_domain_loop #this is where the time gets spent, 2 ops atrnd: proxy from transport_socket to smtpd_atrnd_socket (filter quits, additional helos,etc) smtpd: proxy from smtpd_atrnd_socket to client_socket everybody_ends_conversations #passing the fd smtpd: if client_auth OK && request_policy_check OK then: smtpd: connect(ATRN service) smtpd: pass fd atrnd: do flush and proxying, smtpd not involved Honestly I have no idea what security considerations fd passing may raise. #initial scenario was: atrnd:totally decoupled service listening on port 366 #I only had the code reuse problem #given by the morbid desire of integrating as much as i can with existent postfix logic #as i really dont want to copy or reimplement auth,sasl,tls,ehlo,etc So passing the fd after some SMTPD setup seems fine, i believe. > I would not duplicate Exactly duplication is what i dont want to do, hence wondering about code reuse, etc - in the case smtpd-alike services with small protocol differences are needed. >(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 I understand. > 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. Hello, mail prioritization :) > > Wietse Thank you very much -- adrian ilarion ciobanu adria...@ciobanu.name http://pub.mud.ro/~cia +40 788 319 497
