postfix-users@postfix.org wrote in <20240131155624.ga51...@veps.esmtp.org>: |> SMFIP_NOQUIT would |> be a good protocol extension in general | |"Use the source, Luke." | |You mean something like |SMFIC_QUIT_NC |?
I did, i have that symbol (like MDS256..), yes. So maybe, yes. This is one of those which do nothing in the FreeBSD variant of sendmail .. without not looking again right now, but i think so. If i understand you correctly, then, it means that the commercial variant of sendmail does exactly that, and leaves the socket connection to the (lib)milter alive in the QUIT_NC case? This would be exactly what i want, then! In this hindsight i have misunderstood the meaning of QUIT_NC, obviously. And the only problem is that postfix does not implement QUIT_NC. Wonderful! Let me change the subject! Hmmm, but SMFIP does not have anything to say, it is really only QUIT_NC alone (i have an internal comment with a milter-protocol.txt,v 1.6 copy, plus collected the constants from sendmail and postfix .. i do not use libmilter). So, it follows QUIT_NC is solely a decision of the MTA, looking into its internals. This .. is a good thing, too, but not exactly what i meant. For example, for postfix, if i use non_smtpd_milters and use sendmail(1) for a local mail delivery, it is pretty much unlikely that the QUIT_NC case occurs. (It is in general so on my currently single user system.) It could mean a thing on the server, at times, so it is a good thing if the server does not close the socket if QUIT_NC happens. But what i meant is that the server<>milter communication socket remains open per se; maybe until some garbage-collect timer triggers. For a blocking socket this blocks, for a non-blocking variant (as seems to happen) you have to select/poll anyway. So no problem if nothing happens. This reduces the noise quite a bit, and avoids possible NFILE/MFILE issues on very busy (and/or tightly configured) systems. It would be great for postfix in particular (i used sendmail only shortly on the internet, locally often as it is default in FreeBSD, but never really looked into its source, *except* for the wonderful documents that were in /usr/share if i recall correctly), it starts up a mail handling server when it needs one (and more as concurrent messages happen to happen), and this actually starts a new process chain with policy filters and milters, which all "belong" to this very server. And -- that is the fun of it -- that server is occasionally terminated if it has nothing more to do, or garbage collected after some interval / xy, together with its entire chain. But that is solely driven by postfix itself, all the mamas little helpers can be pretty dumb, and only do its thing. But until then, by the very definition of the postfix administrator, the entire chain is alive, and it seems so superfluous to have all those socket creation / shutdown cycles for nothing at all. But, maybe, if there would be a SMFIP_NOQUIT OPTNEG bit, QUIT_NC could happen exclusively and permanently, whether there would be a "NC", or not? What do you think of that? --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
