I got this task of implementing ODMR in postfix. Although I tried playing the
"why-not-instead" game,
1. no one wants to hear about uucp probably because they thought we will also
switch the fiber links to 9600baud modems.
2. ETRN was a good choice until ISP decided that ETRN is not a good choice
anymore.
3. The existing ODMR implementations for postfix are "don't"s.
Before proceeding, I'd like to ask few questions since I seem to have multiple
implementation choices:
No matter how hard I try not to, I keep seeing similarities between ETRN and
ATRN. That is, dead people:
1.ATRN requires AUTH by specification but no sane sysadmin would do
ETRN without AUTH by implementation
2.both ETRN and ATRN can share the same service_policy_check (by
matching the requested domain(s) against
authenticated user) and (if it doesn't sound forced) same
configuration parameter, smtpd_etrn_restrictions - and
this should (not must) always be the case when supporting both
same time.
3.both ETRN and ATRN can be flush(8)-based services without increased
code complexity and I'll get back to this soon.
4.at this point i see ATRN as a "silent" ETRN upgrade so postfix would
transparently provide both services. The only
weird thing that I can't get rid of because others did it is
ETRN being available on smtp port and ATRN requiring
port 366. Why? Beats me. I'll call it "incomplete security
measures". RFC is missing a chapter that would make ETRN either
obsolete or confirming to the new security considerations if
one cares so about security more than about keeping protocol
upgrades inline. I can hardly wait to read about YTRN and XTRN.
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). Transactions in progress may be spotted by a failed bind(),
assuming no other bugs. Disabling resends until explicitly
requested may be done with defer_transports same as with etrn.
This is for now the cleanest ATRN implementation while willing to reuse
everything that I can from postfix code.
Because of the (4) and also the way we can reuse flush, a patch on smtpd
service is undesirable.
BUT i can still reuse great pieces of code from smtpd service to implement an
"odmrd" service. I can think AUTH and EHLO and that
would be enough. So I will go with defining a trimmed-down version of smtpd
automata and reuse some state handlers.
But some of the functions registered with SMTPD automata that I would reuse in
"odmrd" are static. Same for odmr client if one
wants to reuse smtp functions.
My question is, is this just an isolated case when one can successfully reuse
postfix code or can it be taken in consideration
for a wider audience and eventually make it through at least as a chance for
anyone to define some family of functions as
exportable at compile time (preprocessed (non-)static declarations) ?
And second, is the idea of reusing flush(8) in ATRN (as described above) having
some flaws that I failed to see?
Thank you,
--
adrian ilarion ciobanu
[email protected]
http://pub.mud.ro/~cia
+40 788 319 497
