Wietse Venema via Postfix-users wrote in
<4tqfyk4qzqzj...@spike.porcupine.org>:
|Steffen Nurpmeso via Postfix-users:
|> Wietse Venema via Postfix-users wrote in
|> <4tqc213rcwzj...@spike.porcupine.org>:
|>|So you're suggesting that as long as an MTA-to Milter connection
|>|is not in an error state, sending
|>|
|>| SMFIC_QUIT_NC
|>|
|>|and later sending
|>|
|>| SMTIC_CONNECT
|>|
|>|are sufficient to make a Milter fully forget a past SMTP session and
|>|to make it ready to handle events from a new SMTP session?
|>|
|>|I'd like to see some documentation for that.
|>
|> Well. That is how QUIT_NC is documented i would say,
|
|Documentation? there is a partial comment in a Sendmail header file.
|
| #define SMFIC_QUIT_NC 'K' /* QUIT but new connection \
| follows */
|
|That's all there is. Not even text that is based on observing real
|code at work (like Vierling's writeup).
|
|Here's some hard info from libmilter/engine.c:
|
| /* commands received by milter */
| static cmdfct cmds[] =
| {
| /* command, arguments, next state, what to do, macros, function */
| {SMFIC_ABORT, CM_ARG0, ST_ABRT, CT_CONT, CI_NONE, st_abortfct \
| }
| ...
| , {SMFIC_QUIT, CM_ARG0, ST_QUIT, CT_END, CI_NONE, st_quit \
| }
| ...
| , {SMFIC_QUIT_NC, CM_ARG0, ST_Q_NC, CT_CONT, CI_NONE, st_quit \
| }
|};
|
|This reveals that with both QUIT like commands, libmilter invokes
|the same function (st_quit). The two commands differ in their "next
|state" (ST_QUIT versus ST_Q_NC) and "what to do" (CT_END versus
|CT_CONT).
Together with Assmann's drop-in that seems sufficiently
informative for reverse engineering. :-)
But it really is sad. 20+ years ago there were really good HOWTOs
in the Linux world, not to talk about all those papers/ and the
historical BSD PSD and USD documentation series. And their manual
pages. (Today the Linux ones are pretty good, though.) And we
here had at times good journalism.
Today you find garbage in forums and nothing else. Beautiful
defunct webpages like [1]. And mails do not get transported, but
land in project archives, which at times are forked, and the
history being lost (Unicode, for example; just recently a thread
on IETF archives). Backward incompatible changes on such "basics"
like EVP_SignFinal() [2] (not posted but to internal archive) are
silently performed within some github issue.
[1] https://www.openssl.org/community/mailinglists.html
[2] https://mta.openssl.org/pipermail/openssl-users/2024-January/016947.html
Thanks for looking into this!!
Ciao and greetings!
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
