Hi, I think we have 3 issues, one bug, one sensible enhancement - and one important enhancement to benefit from common practice.
A) Clearly, RFC 1870 must work properly - otherwise it's a bug. Anything we can do to stop wasting bandwidth must work! The Imail log for outgoing messages doesn't show that Imail generates the SIZE=nnnnnn value on its MAIL FROMs: Trying protected.com (0) 220 mail.protected.com Microsoft ESMTP MAIL Service, Version: 6.0.3790.1830 ready at Mon, 6 Nov 2006 11:04:27 -0500 Connect protected.com [68.236.97.131:25] (1) >EHLO mail.webhost.hm-software.com 250-mail.protected.com Hello [63.107.174.14] 250-TURN 250-SIZE 250-ETRN 250-PIPELINING 250-DSN 250-ENHANCEDSTATUSCODES 250-8bitmime 250-BINARYMIME 250-CHUNKING 250-VRFY 250-X-EXPS GSSAPI NTLM LOGIN 250-X-EXPS=LOGIN 250-AUTH GSSAPI NTLM LOGIN 250-AUTH=LOGIN 250-X-LINK2STATE 250-XEXCH50 250 OK >MAIL FROM:<[EMAIL PROTECTED]> What am I missing? As far as I can tell, Imail only implments RFC1870 on the inbound side - but forgot to implmement it on the outbound side? B) Imail as the receiver of an oversized message from a non-RFC1870 server. If Imail were to at least simply discard any excess bytes, but wait until the transmission is complete before rejecting it compliantly, it would still cost one-time bandwidth, but would not tie up disk space. I think this is the minimum requirement! In addition, it could offer the administrator a new (optional!) setting to allow Imail to report an immediate size error after a system wide limit has been reached and then drop the connection during the DATA transfer. As has been pointed out, the risk is that the other side will behave according to standards, keep retrying and thus only worsen the problem on both sides until the retry max is exceeded on the sender. C) Imail as the sender of an oversized message to a non-RFC1870 server. When Imail is the sending server, it should be prepared for the increasingly common practice that an oversized transmission is interrupted before the end-of-data. Thus it should listen for any return codes during data transfer and act appropriate on any 5xx or 4xx it receives. I don't see any "risk" in Imail benefiting from other servers that do implement this behavor. Best Regards Andy Schmidt H&M Systems Software, Inc. 600 East Crescent Avenue, Suite 203 Upper Saddle River, NJ 07458-1846 Phone: +1 201 934-3414 x20 (Business) Fax: +1 201 934-9206 http://www.HM-Software.com/ ---------------------------------------------------------------------------- ----------------------------------- Date: Sat, 04 Nov 2006 23:14:48 -0500 From: Matt <[EMAIL PROTECTED]> Subject: Re: [IMail Forum] Maximum size email Reply-To: [email protected] This is a multi-part message in MIME format. --------------070307080606050409020907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This is why I brought up the RFC 1870 issue. The message would be rejected before the DATA command on all EHLO connections that also supported the Size declaration. Certainly all common/modern E-mails clients do. There is no protection however from HELO connections or things that don't send the Size declaration. Microsoft and SmarterMail seem to have reinterpreted the RFC's to send the 550 error as soon as the message goes over size, and most servers do listen to such errors during the DATA command, but IMail doesn't. I would also like to see this changed, though based on my read of the RFC, IMail is not required to do so by standards. The behavior however is in fact much better, and allowing unlimited DATA to be sent is a vulnerability. To close this vulnerability and prevent the resending of such messages, one must respond with a 550 during the DATA command. So in this case breaking the RFC is necessary for protecting one's server. Matt To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
