Thanks Philip, I think I've just found something I'd rather
see addressed before this one though...
message_size_limit is correctly advertised in reponse to EHLO,
and it does correctly 552 any message that exceeds that size,
but it does so only after all bytes up to the trailing . in
the (arbitrarily large) DATA section are received.
I'm not sure what the rfc's might mandate, but it would be really
nice if exim actually refused to receive more than that many bytes
before issuing an error and/or forcefully closing the connection
if neccessary.
Not that I think my telco really _would_ open a connection to
my mailserver and simply send random bytes to it for as long as
they could, but backwater legislation means it _could_ earn them
up to 35c/Mb to do so...
At the moment, unless I've missed something, exim will let this
happen, then log that it just /dev/null'd the bulk of the last
(say) 40Gb of my network traffic.
If it instead dropped them in $message_size_limit chunks I can
at least blackhole repeating offenders before too much damage
is done.
cheers,
Ron
(and if you're not sick of hearing it, then add my +1 to
exim4's accolades, this is a really nice piece of work
and in my experience so far, a clear and painless step
forward from exim3 ...)
On Mon, Jul 19, 2004 at 09:45:58AM +0100, Philip Hazel wrote:
> On Sun, 18 Jul 2004, Andreas Metzler wrote:
>
> > verify_check_header_address() currently simply does not support passing
> > or evaluation of callout modifiers (besides timeout).
>
> Noted.
>
> --
> 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
>
