[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