The large, fast milter may know that it has nothing left to do for any particular message, but since Sendmail doesn't call its close callback
until after the second milter has finished its processing (even if the
first milter returns 'SMFIS_ACCEPT' from the connect callback) it must
stick around doing nothing but waste resources until the second milter
has terminated.
G.W. Haywood wrote:
The large, fast milter may know that it has nothing left to do for any
particular message, but since Sendmail doesn't call its close callback
until after the second milter has finished its processing (even if the
first milter returns 'SMFIS_ACCEPT' from the connect callback) it must
stick around doing nothing but waste resources until the second milter
has terminated.
Why doesn't the "large" milter invoke its cleanup function as soon
as it "know[s] that it has nothing left to do"? The cleanup function
can set a flag in the milter context that it was called and did its
work (release all the memory), so further calls can just check that.
On Thu, 3 Jun 2021, Claus Assmann wrote:
Why doesn't the "large" milter invoke its cleanup function as soon
as it "know[s] that it has nothing left to do"? The cleanup function
can set a flag in the milter context that it was called and did its
work (release all the memory), so further calls can just check that.
Thanks, but it's not quite as simple as that.
Maybe someone else understands the problem because I don't.
! Ideally, I should like to be able to tell Sendmail to call the close
! callback for the first milter when the first milter knows it's done
Why does it make a difference between sendmail "call[ing] the close
callback" and your own milter doing that?
If your "milter returns 'SMFIS_ACCEPT' from the connect callback"
then why would it even allocate resources which it doesn't need?
If your milter returns SMFIS_ACCEPT from a transaction callback
then sendmail has no way to know that your milter doesn't even want
the subsequent transactions, i.e., you would have to come up with
another return code.
Anway, you got the source, so you can hack it to do what you
consider necessary for your special situation.
On Sat, 5 Jun 2021, Claus Assmann wrote:
Why does it make a difference between sendmail "call[ing] the close callback" and your own milter doing that?
Until I read your question above, I had the impression that callbacks
are for the MTA to call. It never occurred to me to call them myself
and I'd have expected doing that to break the communications between
Sendmail and the milter. Does Sendmail not care if I call the close
callback myself? If it's allowed by the milter protocol, then the
G.W. Haywood wrote:
On Sat, 5 Jun 2021, Claus Assmann wrote:
Why does it make a difference between sendmail "call[ing] the close
callback" and your own milter doing that?
Until I read your question above, I had the impression that callbacks
are for the MTA to call. It never occurred to me to call them myself
In C they are functions which are called by libmilter,
using a documented API and required return values.
and I'd have expected doing that to break the communications between
Sendmail and the milter. Does Sendmail not care if I call the close
callback myself? If it's allowed by the milter protocol, then the
In C the callbacks do not communicate with the MTA,
obviously that's only handled by libmilter.
I don't know anything about whatever "libmilter" perl uses,
so you would have to check its docs.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 296 |
Nodes: | 16 (2 / 14) |
Uptime: | 48:09:49 |
Calls: | 6,648 |
Files: | 12,198 |
Messages: | 5,329,985 |