> > Should ODMR support be in the primary MTA queue? Or should mail > for ODMR destinations be batched up onto disk out of the MTA's > queue, and served by dedicated servers as in: > > http://www.plonk.de/sw/odmr/ odmr is mail relaying. if one chooses this solution then one probably wants to do the same thing for any type of relaying. > > It is far from clear that one wants to gum-up the active and deferred > queues of a real MTA with ODMR mail. If we can deliver envelope + message > to suitable stable storage, and use a standalone ODMR server to make > said storage available to ODMR clients, that is likely a better solution > and is much less intrusive. > > You just a need a delivery agent that records the envelope in detail and > delivers to a maildir or similar associated with the owner of the domain. > Then a non-Postfix server that supports retrieval. No pointless retries > or gumming up the deferred/active queue unless the user connects, though > your probably need a daily scan to bounce over-age messages.
What you describe sounds like day-by-day mail relaying, practically for me there's no "ODMR mail", just mail waiting to be relayed. Maybe I'm wrong and ODMR must be seen as delivery or something else since it must be hooked up everywhere in the process, it seems. The only difference is how the relaying process is finalized. Normal smtp, etrn or atrn. So i think that no matter what the transport is, the queueing rules should be the same for every email that needs to be relayed. The "pointless retries or gumming up the deferred/active queue" may also refer to mail waiting to be relayed in a normal fashion (e.g. smtp/lmtp transport) but with destination being down. I mean, we will succeed to gumup the queue no matter what transport. Thats one point I can't agree with for having the atrn totally decoupled from postfix queue and related configurations. And there are at least 2 kilotons of logic in postfix that can and should be reused . So i wont duplicate authentication, queueing and other pieces of code. When i was thinking "exporting more functionality via a library" - `that can be made in a very spartan way, e.g. smtpd.c: EXT_SMTPD_LIB int etrn_cmd(...) user_compiletime_config.h: #define EXPORT_SMTPD_LIB 1 build_exports.h #ifndef EXPORT_SMTPD_LIB #define EXT_SMTPD_LIB static #endif and have in fact no library/extraheaders built, the developer can use directly the .o via externs, its not very hard to build your own stuff in a postfix source tree instead of using a well defined exported api. no bells and whistles. by default no exports, if enduser knows what he wants he defines his exports (SMTPD_LIB,SMTPD_SASL_LIB) at compiletime. i can't tell what security considerations must be applied when doing this but I understand it's complicated, it may break things and in the end its work with possible no payback in time. i'm not thinking only atrnd, but other services that can successfully reuse pieces of code. as a normal postfix user i vote for this and against patching smtpd, assuming more extensions needing to be added in the future. > > -- > 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. -- adrian ilarion ciobanu adria...@ciobanu.name http://pub.mud.ro/~cia +40 788 319 497
