Re: [Exim] hole in message_size_limit? (was: verify = heade…

On Thu, Jul 22, 2004 at 11:14:21AM +0100, Philip Hazel wrote:
> On Thu, 22 Jul 2004, Ron wrote:
>
> > It may also be worth noting that a client exceeding a timeout may
> > really just have timed out, but a client that ignores an advertised
> > size has to do so entirely of its own accord -- so these probably
> > should be examined according to different criteria when determining
> > local policy for a response.
>
> Not all clients recognize SIZE. There's an awful lot of legacy about.
> You don't know if the client looks at SIZE or not.

Yes, I feared this to be a reasonable assumption. Even if those
clients were just a small minority, that might still include someone
I'll correspond with -- people who talk proudly about the rate of
'internet time' aren't typically thinking about the propagation of
protocols ... ;)

It is one reason I think we need to permit non-trivial processing of
such mail though. The correct response may be arbitrarily complex for
any particular site's needs. What I was mainly trying to highlight
above was that one of these things is deterministic, a message that
fails for being oversize will fail again unless the configuration is
changed (irrespective of the client's intent), but a message that times
out _may_ succeed on a subsequent retry if 'legitimate' network
congestion (or a separate dos in progress) was a significant factor in
it timing out.

A timeout alone may not discriminate good mail from bad very well in
the event that an attacker is attempting to saturate both the bandwidth
and the majority of available connections.


I was wondering this morning, though it is probably not reasonable to do
exactly this in practice, whether a DATA overflow should just trip to
acl_check_data when message_size_limit bytes have been received, at
which point if some flag were set to indicate more data was still
waiting to be received, then the message might be conditionally
permitted to continue to completion based on the content already
received, or summarily dropped if it looks suspect.

Thinking through that a little differently though:

I like the idea of being able to check $message_size in acl_check_data
and decide based on the message's other attributes what the largest
message we should route will be.

What got me looking at message_size_limit was the hope that I could
avoid receiving a lot of data after it is known that it will be dropped.

Given what I (think I) know now, message_size_limit is probably useful
on a resource limited mail server, since it caps the memory usage of
exim and may save you from thrashing. Otherwise, checking $message_size
in acl_check_data is functionally equivalent in almost every way except
exim will make the entire body it received available to you, and you
can send any error message you please in place of the 552 if you choose
to reject it.

The missing element for me from this perspective, is a 'breakpoint' size
at which exim looks at the message data it has received so far before
deciding how to continue. I can use this to trap malware sending large
messages, and to try and tell the difference from friends well meaningly
sending us their (marginally more welcome) 30Mb baby tiffs, but it seems
quite flexible for other purposes too.

So put in this way, what I'm after sounds more like a(nother) local_scan
type hook. That would give more power to the user and I'd expect be
less intrusive to exim than an acl -- it should also place a natural
limit on the kind of user that will make a real mess out of getting this
rfc violating business horribly wrong too ;-)

Even on a site ordinarily prepared to accept arbitrarily large emails
there may be some value in allowing eg. spamassassin to hook in after
the first 250k have been received (since that is all it will process
by default anyway), instead of later.

So to steal a line from my optician, does this seem better or worse than
an acl for this task?

If it is better, then perhaps a generic 'exception' hook would suffice
which messages that violate certain conditions may be fed to. Then we
could just generate suitable timeout and size errors.

cheers,
Ron