Mark Martinec:
> For the last couple of days I'm now experimenting with the
> 2.7-20091105-nonprod with the new speed_adjust experimental feature
> turned on at the MX port, along with the postscreen. Seems to work
> as advertised: timing reports by a pre-queue proxy content filter confirm
> that the content filter is invoked only after data has been received.
> Current mail load on our server is not high, so I haven't yet seen
> what happens under high mail rate conditions.
Thanks. 20091105-nonprod has a known problem when the temp file
can't be written for some reason (fixed in 20091109).
I speculate that under load, clients will experience delays at a
different point in the conversation.
Assume that the maximal number of filter processes is tuned such
that the machine does not collapse under that load.
Without speed-match, there is exactly one smtpd process for each
filter. As soon as all smtpd processes are busy (whether or not
these sessions rejecting mail early), new tcp connections will get
queued, and clients experience a delay before the 220 welcome
greeting.
With speed-match, there can be more smtpd processes than filters,
Once all filters are busy, clients that complete an SMTP delivery
will experience a delay after sending ".". When the load increases
to the point that all smtpd processes are busy, which should happen
later than in the "no speed-match" scenario, new tcp connections
will get queued and clients experience a delay before the 220
welcome greeting.
As for the second problem, it would help if you could add a missing
sanity check here:
*** ./smtpd_proxy.c- Thu Nov 5 16:48:53 2009
--- ./smtpd_proxy.c Fri Nov 13 08:27:37 2009
***************
*** 1027,1032 ****
--- 1027,1038 ----
(p)->a10, (p)->a11, (p))
/*
+ * Sanity check.
+ */
+ if (state->proxy != 0)
+ msg_panic("smtpd_proxy_create: handle still exists");
+
+ /*
* Connect to the before-queue filter immediately.
*/
if ((flags & SMTPD_PROXY_FLAG_SPEED_ADJUST) == 0) {
It will help to get closer to the root cause. Meanwhile, I can set
up a null-filter measurement on my tiny site and see if this triggers
something. I thought that every mail transaction ends with truncating
the temporary file, even when the transaction is aborted early.
> Two things are on my mind:
>
> 1. I'm dearly missing in the postfix log the SMTP response from a
> pre-queue content filter (or better, a response that was sent back to a SMTP
> client), at least in case of a 5xx or 4xx response. With a post-queue filter
> setup the response is clearly logged, unlike in the pre-queue setup where it
> is not. It makes it hard to correlate a spartanic postfix log of a rejected
> transaction (due to a proxy filter rejection) with a log from a content
> filter. Even if the correlation were somehow available, seeing a confirmation
> of what was really sent back to the client in a postfix log would contribute
> to the confidence in the correctness of operation.
I assumed that the filter will already log the rejects (possible with the
client name/address from xforward), and therefore Postfix would
not need to add to the noise, but this can be changed.
Wietse
