Claus Assmann via Postfix-users:
> > SMFIP_NOQUIT would
> > be a good protocol extension in general
>
> "Use the source, Luke."
>
> You mean something like
> SMFIC_QUIT_NC
> ?
And... Postfix 'knows' that constant since postfix-2.5.0, but there
is no code to negotiate or send it.
What would it take?
- If the MTA sends SMFIC_QUIT_NC instead of SMFIC_QUIT, the MTA
will have to carefully revert the Milter connection state back to
what is was before the last time the MTA sent SMFIC_CONNECT, instead
of simply discarding that state like it does now.
- The MTA then needs to keep the Milter connection open while watting
for new work. Once there is work, the MTA sends SMFIC_CONNECT and
so on.
- This sounds like the MTA needs a Milter connection cache that
keeps a connection open for up to $max_idle seconds, because it
seems to make no sense to cache such state inside individual smtpd
(or cleanup) processes.
- To avoid cross-contamination, the Milter connection cache needs
to be indexed by a combination of the Postfix server ID (first two
fields in master.cf), and by Milter configuration settings.
- There need to be safety limits on how many times a cached Milter
connection can be reused.
That looks like an awful lot of complexity. A simpler solution may
be to insert a Milter proxy between MTA and Milters (kind of like
how proxymap works for Postfix tables). The MTA makes only new
connections to the Milter proxy, which proxies those connections
over a pool of reusable connections.
Wietse
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
