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 -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
