Hello. I am currently writing my first ever milter, a yet postfix-only DKIM sign-only one.
I want to do "that" (well: actually DKIM, not milter) for years but could not because i had "no I-M-F aka RFC 822/2822/5322 parser of acceptable quality". That has changed (quite a bit), but i will not make it until February 1st when Google requires this for M-L drivers, mostly. I hope for an internal prototype to function, but the release will take at least a week more. I looked around into I-M-F parsers (for no good) and more for too long, actually. Anyhow, i also stumbled over your SMFIC_QUIT comment. And now my milter part (i do not use libmilter) is already doing so far, and i think i is a terrible thing, because the postfix server that "drives me" is the same, and there would be no SMFIC_QUIT if the same SMTP connection hammers thousands of successive emails. And i do see (at least the macros of, mind you) SMFIC_CONNECT etc, do i. And then, you know, i am so happy about your spawn(8), it drives my s-postgray for two years without just any problems, and given how long the specific postfix-daemon/spawn/s-postgray program tuple lives together before it is garbage-collected, the overhead of spawn(8) is near zero. And it saves me doing all the things that a real server has to do. With spawn(8), a user configures its postfix daemon, and hooks in my policy filter, given it user= etc identity, and that just scales alongside, just as necessary, and is garbage-collected alongside, just as configured via postfix. (My postgray "server" then goes home with the TERM upon system shutdown, that is true, i no longer recycle it via timeout per se. But could. Ie: postfix is "our driver". Period.) Now, with the milter, i am unfortunately forced to write a real server, i cannot even use spawn(8) in the release version in the same way as for postgray, where spawn(8) starts the client, which starts the server if there is none yet. A real server, with user- and group-, and session-, and "official" pid-file-handling, with start script and all those things. Users have to create a "system service" for this even, alongside postfix as such, totally unrelated it seems, but effectively: not. This is because of the non-neglectable overhead of SMFIC_QUIT, that enforces socket closings. Your in-code comment claims this SMFIC_QUIT is needed because of compatibility with sendmail. Therefore my question would be whether, and when not, why, you never have thought about adding a SMFIP_NOQUIT as part of the protocol handshake, that would drop this -- sorry -- stupid SMFIC_QUIT handling? Btw if Mr. Assmann of sendmail also reads this, SMFIP_NOQUIT would be a good protocol extension in general, i would think? Possibly a bit exaggerating, but MFILE / NFILE handling, resource limits and all that, the "noise" due to this frequent socket open / socket close is quite a lot, isn't it. And it is entirely unnecessary. And would allow lean postfix-spawn-specific milters be written, or existing milters to be modified accordingly, ie, preprocessor defining-out the entire server part handling of milters. 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
