Re: [exim] Feature Suggestion - headers acl?

On 2007-12-27 at 20:52 -0800, Marc Perkel wrote:
> In addition to all the standard ACLs I'd like to suggest a headers acl
> that would run at the blank line between the headers and the message.
> That way I can take action without having to wait for all the data to be
> transfered.

What action? To achieve what, precisely?

You can't reject or the like, since that will just trigger senders to
resend; you could silently discard but that's almost always a dubious
plan. There would be lots of special cases for interactions of
post_header actions with DATA actions and confusion about which rules
take precedence.

Hypothesising based on what I consider reasonable assumptions of what
would happen (ie: measurement might prove me wrong):

I suppose if it were limited to the "warn" action and the evaluation of
the DATA ACL were to block on the completion of a post_headers ACL if
such an ACL exists, then it might be plausible, but that would just be a
_possible_ (unverified) throughput optimisation in exchange for a major
special case in the code (read: complexity and opportunity for
mistakes). It's _possible_ that some ACL condition checks done
post_header to complete by the end of DATA would streamline things, but
then there would be all sorts of synchronisation issues to deal with in
waiting, there would be less cache consistency as the cache would keep
getting blown out by the DATA content passing through and generally
you're not likely to get much speed-up, in what is a store-and-forward
system. So an email takes 0.3 seconds to process instead of 0.25
seconds. Wow. The reshuffling isn't going to significantly affect
actual total system throughput.

And that's assuming that the lookups happen in parallel to receiving the
body, when in fact given Exim's design (single-threaded, not
select+state but actions in discrete stages) they'd have to happen
before receiving the rest of the body, right when the sender is trying
to shove large packets and grow the TCP receive window; the process
would have a delay in reading data, would be filling the in-kernel TCP
receive buffers and the sender would be slowed down. So you've just
increased the amount of time that data stays in the more scarce kernel
memory and decreased throughput. This wouldn't happen if the delay were
"very short" (as is the case for the sorts of things already done after
receiving headers and before receiving body) but if that's the case then
why move the processing from after-end-of-DATA?

So, what exactly is the use-case which you have in mind? Without
knowing what you're trying to achieve, I don't know if any of what I've
just pointed out is applicable.

-Phil