David MacQuigg wrote:
I would just continue accepting the message, and throw away the data,
then give a 'message too big' error at the end.
>
This doesn't deal with the case where the data never stops.
What would be the criteria?
That is why our server, once upon a time, had a block transfer count
check against local policy size limits with the drop idea as well.
But it was pulled due to retransmissions and mostly seen from
legitimate users. We want the client MUA to see a normal server
response to this and have it popup the dialog to the user hopefully
showing the server response text. The odds are good nor should we
expect the MUA to read some forced DATA abort server text from the
server. At best we can expect the client to be modeled as followed in
a client/server state machine fashion:
DATA state:
Data
read data
err = send data
if err is socket closed then
// RFC 2821/5321 says assume 451
close resources
requeue
return false
end if
Loop
wait 5 mins (default) for server response
We can't assume that for an socket error that it will exit the loop
and capture some legacy transmission data remaining in the socket
buffers. It MAY be there, but we can't assume this.
Data
read data
err = send data
if err is not successful then
// see if there is any buffered data in input stream
exit loop
end if
Loop
wait 5 mins (default) for server response
We have one rule left related to this on the server's data transfer
loop and outside the loop. If the detected extended SMTP sender
provided MAIL SIZE info and it exceeded the size in the transfer, then
this is trapped and the sender info is recorded. But we don't drop
the line anymore. I can't tell you off hand if we have any logs on this.
So I would lean towards Levine's point, that it is rare to see this,
and probably simply because that it would be trapped under normal
circumstances after the data transfer is complete. Sure, a pain in
the butt - but they are not defeating your server.
--
Sincerely
Hector Santos
http://www.santronics.com