Thanks to everybody who responded on this topic, both on the list and
privately.
First, some general comments:
1. Some people went off at a tangent, talking about rejecting viruses at
SMTP time. That is a red herring, I'm afraid. What I was discussing was
what Exim should do when it actually has a message in its hand that it
cannot deliver. This can happen, however clever you try to be at SMTP
time.
2. There were other comments about rejecting incoming bounce messages
that have attachments. For example,
On Sun, 7 Sep 2003, Patrick Starrenburg wrote:
> 1. Incoming bounce with attachment -> strip attachment
> (getting tough)
> 2. Incoming bounce with attachment -> reject SMTP connection
> (getting really tough and this is, as we know, strictly speaking against
> RFCs. But something has to happen to contain these virus induced email
> broadcast storms. The signal-to-noise ratio is getting smaller every
> day.)
This is not right, because some MTAs send perfectly normal bounces using
attachments. Indeed, this is documented as the "right" way to do it in
RFC 1892. An option to make Exim do this has been on the Wish List for a
long time, but nothing has been done about it - partly because I'm not
keen, and partly because it would be a rather large amount of work, I
think. Furthermore,
3. Exim has no current code for parsing bodies and sorting out the
different parts (for bounce messages or others). I suppose in the long
run it may be necessary to write such code, but I'd rather avoid it if I
can.
Reactions to the suggestions I made:
1. Nobody objected to reducing return_size_limit from 100K to 10K.
Several people said they do that already (one said 5K). There was one
caveat about making incompatible changes to a default setting.
2. Only one person didn't like the proposal for a bounce_return_body
option. Of the others, 3 said the default should be FALSE, one said it
should be TRUE, and one expressed no preference.
I do normally try to add features in such a way that the default
behaviour remains unchanged. However, there are precedents for making
changes. For example. originally Exim did not verify senders by
default; this was changed at some point when it became clear that *some*
default incoming policy control was necessary.
I think this may be one of those times when an incompatible change of
default is justified. I propose, therefore, to do the following:
A. Reduce the return_size_limit default to 10K.
B. Implement bounce_return_body, and default it FALSE.
C. It strikes me that "return_size_limit" is not a very helpful name any
more. I propose to rename it as bounce_return_size_limit, but keep the
old name as a deprecated synonym.
Philip
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book: http://www.uit.co.uk/exim-book
