On Mon, 5 Feb 2007, Claus Assmann wrote:
As I wrote before: it would be really nice to get some feedback
from people who are familiar with MTAs to comment about the (code)
complexity etc.
I've been thinking a little about how to add this to Exim.
There is a question related to a security consideration: if you do
per-recipient content scanning instead of per-message content scanning
then it's much easier for an attacker to use up your CPU. Because of that
I had been thinking that MTAs would continue to scan messages only once,
as at present, and that it would take negligible effort to make the
per-recipient accept/deny decisions. The model would then be that the MTA
scans, decides whether to accept for each recipient, commits if necessary,
then returns all the replies at once. This is why I had been arguing for
using exactly the LMTP style of final reply.
However it has become clear from the discussion that people are
considering per-recipient scanning. I'm not entirely convinced of the
wisdom of this, but Exim's experience of feature creep tells me that
postmasters will want it. The biggest use-cases I can see are
per-recipient statistical classifiers and SpamAssassin's per-user
configurability. If you are going to do time-consuming things after data,
especially in a way that increases with envelope size, then LMTP becomes
painful: you want to trickle out the replies as they become available, but
you don't want to have to repeatedly commit the same message. As Claus
pointed out, Eric's draft allows a single commit point after the
per-recipient replies and before an overall final reply, which fixes the
problem.
What do others think about the trade-off between the CPU usage security
issue and the desire for per-recipient scanning?
Tony.
--
f.a.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/
LUNDY FASTNET: NORTHEAST VEERING EAST 4 INCREASING 5 TO 7. SLIGHT OR MODERATE
BECOMING ROUGH OR VERY ROUGH. RAIN AT TIMES, OCCASIONALLY SLEET LATER.
MODERATE OR GOOD.