When when the 'databytes' control file is present, qpsmtpd includes the SIZE keyword in the response to EHLO. While it's useful to tell the client the maximum acceptable size at that point, isn't including that keyword a claim that qpsmtpd actually supports the SIZE extension? Since qpsmtpd currently ignores any ESMTP parameters in the MAIL and RCPT commands, it seems that the claim is false.
Now maybe this doesn't matter, as long as the maximum size never changes after the EHLO response. The client should never try to deliver a larger message, so it should never issue a SIZE parameter that's too large. However, if we allow for adjusting the maximum size depending on the sender or recipient, we probably need to start paying attention to the ESMTP parameters. That is, if the client tells us the size of the message in the MAIL command, we shouldn't say OK and then later, after it sends the data, take that back and say the message is too big. We should say it's too big after the MAIL or RCPT. See RFC 1870. This ties into the parsing of the MAIL and RCPT commands, which currently isn't right. The parsing should be the same for both (currently it isn't), it should allow spaces in the addresses, and it should parse the ESMTP parameters (and apparently respond with a 555 if it doesn't understand all of them). Is someone working on that at the moment, or should I start looking into it myself? I don't want to step on any toes or duplicate work. -- Keith C. Ivey <[EMAIL PROTECTED]> Washington, DC
