[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: odd behavior in enforcing of message size limits



>   Since command pipelining is being used, the remote host sent all the 
> commands at once (notice "pipeline input exists").

Pipelining or no, the smtpserver should return a 552 error to the RCPT
request, and since no recipients are accepted, should return an
error on the DATA command.


>   Allowing the DATA command makes sense.  The remote host wouldn't see a 
> DATA command failing, and the message would be input as SMTP commands.   
> Better to let DATA command succeed, and drain rest of the buffer, and 
> then throw it away.

Piplelining through the DATA statement doesn't make sense; the
DATA statement is permitted to return an error in several cases
and the client should wait for an appropriate conditional-success
code before resuming transmission.


One way to solve the problem would to be to change smtpserver/smtpserver.c,
in the smtp_rcpt() function, just after the code fragment:
    } else if (sizeoptsum > availspace) {
	  type(452, "insufficient storage space, try again later");

to add the case:
	} else if (maxsize > 0 && filsiz > maxsize) {
	  type(552, "Message size exceeds fixed maximum size for acceptable email");

A side effect of this change is that the rcpt_count variable does
not get incremented, and the DATA statement would be read with
a rcpt_count of zero, causing a 550 error to be returned.


Another, and perhaps better, approach would be to modify smtp_mail()
to not update the "state" variable unless it is reporting success;
on any error condition it leaves the "state" alone.


		--Ken Pizzini