On Tue, Jul 20, 2004 at 09:26:22AM +0100, Philip Hazel wrote:
> On Tue, 20 Jul 2004, Ron wrote:
>
> > 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.
>
> Well, that's all the RFC allows you to do. The server cannot respond
> until the client has sent all the data. The client does not listen for a
> response until it has sent all the data.
Is a client that sends EHLO misbehaved if it ignores an advertised
SIZE in the response? (they don't have to EHLO, but I suspect clients
that don't might be increasingly grouped as braindead or belligerent...)
> > 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.
>
> A forceful close of the connection means that the client sees what
> appears to be a network error. It will just try to send the message
> again later. Is this what you want?
That does seem suboptimal, I guess it depends on how many legitimate
clients are likely to get into this position. The belligerent can be
firewalled [1] since that is probably all that will stop them anyway.
I'd need to survey the number of braindead and old clients used by
people I want mail from to judge the wisdom of this...
It does seem better than nothing (as an option, off by default and
subject to host whitelisting etc.), but in the light of this I hope
we can think of something better still.
What currently happens if you hit the (presumed) hard limit of what
exim can accept as DATA?
> I see the problem, though. Perhaps there should be some kind of ultimate
> backstop just to prevent a connection from being held open for ever.
> Noted.
Personally, I'm still figuring out what a well behaved non-trivial mail
system really looks like, so I'm eminently more qualified to point out
problems as I see them than to suggest viable alternatives to this
audience at this stage. Still, if I think of anything useful to add
after chewing on it, I'll bring it back to the list. (which I'm not
on, so anyone who wants me to read something, please cc)
cheers,
Ron
[1] - which suggests the ability to notify some process of this
event would be useful, both for dynamic blacklisting and
for sending an error notification to the verified sender
of the message or admin at the offending host.
