Matt, This may further assist your argument.
- The sending and receiving mail servers must both be RFC 1870 compliant to implement the MESSAGE SIZE declaration. - If the receiving mail server does not have sufficient system storage, then it should return a code "452 insufficient system storage" and sending mail server should then attempt to send any additional messages it may have already queued or a send a QUIT command. The sending mail server should then repeat the attempt to send the message to the server at a later time. - If the receiving mail server restricts a message based on a fixed maximum message size, then the receiving email server should send code "552 message exceeds fixed maximum message size" BEFORE the message is sent by the originating mail server and the sending mail server should immediately send either an RSET command or a QUIT command, in which case the originating mail server should then declare the message undeliverable and return appropriate notification to the sender. - Servers MUST NOT use the SIZE parameter to determine end of content in the DATA command. To wit: In order to accomplish this, the mail SIZE must be declared by the SENDING mail server per RFC 1870, see: http://tools.ietf.org/html/rfc1870 Specifically: 3. Framework for the Size Declaration Extension The following service extension is therefore defined: (1) the name of the SMTP service extension is "Message Size Declaration"; (2) the EHLO keyword value associated with this extension is "SIZE"; (3) one optional parameter is allowed with this EHLO keyword value, a decimal number indicating the fixed maximum message size in bytes that the server will accept. The syntax of the parameter is as follows, using the augmented BNF notation of <http://tools.ietf.org/html/rfc1870#ref-2> ]: size-param ::= [1*DIGIT] A parameter value of 0 (zero) indicates that no fixed maximum message size is in force. If the parameter is omitted no information is conveyed about the server's fixed maximum message size; (4) one optional parameter using the keyword "SIZE" is added to the MAIL FROM command. The value associated with this parameter is a decimal number indicating the size of the message that is to be transmitted. The syntax of the value is as follows, using the augmented BNF notation of [2 <http://tools.ietf.org/html/rfc1870#ref-2> ]: size-value ::= 1*20DIGIT (5) the maximum length of a MAIL FROM command line is increased by 26 characters by the possible addition of the SIZE keyword and value; (6) no additional SMTP verbs are defined by this extension. The remainder of this memo specifies how support for the extension affects the behavior of an SMTP client and server. 4. The Message Size Declaration service extension An SMTP server may have a fixed upper limit on message size. Any attempt by a client to transfer a message which is larger than this fixed upper limit will fail. In addition, a server normally has limited space with which to store incoming messages. Transfer of a message may therefore also fail due to a lack of storage space, but might succeed at a later time. A client using the unextended SMTP protocol defined in [<http://tools.ietf.org/html/rfc1870#ref-1>], can only be informed of such failures after transmitting the entire message to the server (which discards the transferred message). If, however, both client and server support the Message Size Declaration service extension, such conditions may be detected before any transfer is attempted. An SMTP client wishing to relay a large content may issue the EHLO command to start an SMTP session, to determine if the server supports any of several service extensions. If the server responds with code 250 to the EHLO command, and the response includes the EHLO keyword value SIZE, then the Message Size Declaration extension is supported. If a numeric parameter follows the SIZE keyword value of the EHLO response, it indicates the size of the largest message that the server is willing to accept. Any attempt by a client to transfer a message which is larger than this limit will be rejected with a permanent failure (552) reply code. A server that supports the Message Size Declaration extension will accept the extended version of the MAIL command described below. When supported by the server, a client may use the extended MAIL command (instead of the MAIL command as defined in [http://tools.ietf.org/html/rfc1870#ref-1]) to declare an estimate of the size of a message it wishes to transfer. The server may then return an appropriate error code if it determines that an attempt to transfer a message of that size would fail. 5. Definitions The message size is defined as the number of octets, including CR-LF pairs, but not the SMTP DATA command's terminating dot or doubled quoting dots, to be transmitted by the SMTP client after receiving reply code 354 to the DATA command. The fixed maximum message size is defined as the message size of the largest message that a server is ever willing to accept. An attempt to transfer any message larger than the fixed maximum message size will always fail. The fixed maximum message size may be an implementation artifact of the SMTP server, or it may be chosen by the administrator of the server. The declared message size is defined as a client's estimate of the message size for a particular message. 6. The extended MAIL command The extended MAIL command is issued by a client when it wishes to inform a server of the size of the message to be sent. The extended MAIL command is identical to the MAIL command as defined in [http://tools.ietf.org/html/rfc1870#ref-1], except that a SIZE parameter appears after the address. The complete syntax of this extended command is defined in [5]. The esmtp-keyword is "SIZE" and the syntax for esmtp-value is given by the syntax for size-value shown above. The value associated with the SIZE parameter is a decimal representation of the declared message size in octets. This number should include the message header, body, and the CR-LF sequences between lines, but not the SMTP DATA command's terminating dot or doubled quoting dots. Only one SIZE parameter may be specified in a single MAIL command. Ideally, the declared message size is equal to the true message size. However, since exact computation of the message size may be infeasable, the client may use a heuristically-derived estimate. Such heuristics should be chosen so that the declared message size is usually larger than the actual message size. (This has the effect of making the counting or non-counting of SMTP DATA dots largely an academic point.) NOTE: Servers MUST NOT use the SIZE parameter to determine end of content in the DATA command. 6.1 Server action on receipt of the extended MAIL command Upon receipt of an extended MAIL command containing a SIZE parameter, a server should determine whether the declared message size exceeds its fixed maximum message size. If the declared message size is smaller than the fixed maximum message size, the server may also wish to determine whether sufficient resources are available to buffer a message of the declared message size and to maintain it in stable storage, until the message can be delivered or relayed to each of its recipients. A server may respond to the extended MAIL command with any of the error codes defined in [1] for the MAIL command. In addition, one of the following error codes may be returned: (1) If the server currently lacks sufficient resources to accept a message of the indicated size, but may be able to accept the message at a later time, it responds with code "452 insufficient system storage". (2) If the indicated size is larger than the server's fixed maximum message size, the server responds with code "552 message size exceeds fixed maximium message size". A server is permitted, but not required, to accept a message which is, in fact, larger than declared in the extended MAIL command, such as might occur if the client employed a size-estimation heuristic which was inaccurate. 6.2 Client action on receiving response to extended MAIL command The client, upon receiving the server's response to the extended MAIL command, acts as follows: (1) If the code "452 insufficient system storage" is returned, the client should next send either a RSET command (if it wishes to attempt to send other messages) or a QUIT command. The client should then repeat the attempt to send the message to the server at a later time. (2) If the code "552 message exceeds fixed maximum message size" is received, the client should immediately send either a RSET command (if it wishes to attempt to send additional messages), or a QUIT command. The client should then declare the message undeliverable and return appropriate notification to the sender (if a sender address was present in the MAIL command). A successful (250) reply code in response to the extended MAIL command does not constitute an absolute guarantee that the message transfer will succeed. SMTP clients using the extended MAIL command must still be prepared to handle both temporary and permanent error reply codes (including codes 452 and 552), either immediately after issuing the DATA command, or after transfer of the message. 6.3 Messages larger than the declared size. Once a server has agreed (via the extended MAIL command) to accept a message of a particular size, it should not return a 552 reply code after the transfer phase of the DATA command, unless the actual size of the message transferred is greater than the declared message size. A server may also choose to accept a message which is somewhat larger than the declared message size. A client is permitted to declare a message to be smaller than its actual size. However, in this case, a successful (250) reply code is no assurance that the server will accept the message or has sufficient resources to do so. The server may reject such a message after its DATA transfer. 6.4 Per-recipient rejection based on message size. A server that implements this extension may return a 452 or 552 reply code in response to a RCPT command, based on its unwillingness to accept a message of the declared size for a particular recipient. (1) If a 452 code is returned, the client may requeue the message for later delivery to the same recipient. (2) If a 552 code is returned, the client may not requeue the message for later delivery to the same recipient Good luck getting Ipswitch to change this one! Bruce Barnes ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Sent: Sunday, November 05, 2006 23:50 To: [email protected] Subject: Re: [IMail Forum] Maximum size email Rod, I clearly stated that this violates the RFC, but there are 4 facts that you and others must understand. 1) RFC 821 (Simple Mail Transfer Protocol, circa 1982) which defines this behavior was written 24 years ago. 2) Regardless of how IMail currently behaves under these conditions, Micrsoft and SmarterMail servers do behave this way, and most servers have no issues with this behavior. 3) It is a vulnerability to accept unlimited amounts of data by SMTP, and the only way to stop this effectively is to not just stop it mid-sream, but also respond to it midstream so that it doesn't get respooled and resent. Every IMail server will accept an E-mail up to the capacity of the spool drive, but other servers like Exchange and SmarterMail won't. 4) The lack of support for RFC 1870 (SMTP Service Extension for Message Size Declaration, circa 1995) only makes matters worse. Over 95% of the real-world issues would be resolved with proper support for this. This however wouldn't close the vulnerability on it's own or resolve issues with standard/old-style SMTP connections. I don't get why take the purist approach to this when it is a real-world issue and leaves us vulnerable, costs us time, and costs us money. What Microsoft and SmarterMail have done by breaking a non-necessary technicality in a 24 year old RFC is in fact the best way to approach the issue except for the fact that not everyone else (IMail) is supporting this. If you run IMail, anyone can crash your server at any time by just sending you a massive message. IMail shouldn't confuse these two issues however in approaching them. Making IMail RFC 1870 compliant should be done independently of making IMail listen for errors during the DATA command. Everyone that I have worked with closely that run IMail and have a moderate or high number of users has had issues with this on both incoming and outgoing E-mail. The ones that don't notice probably miss it because they aren't actively monitoring bandwidth utilization or know where to look when a problem is reported about non-delivery. If you have an alternative recommendation for closing the hole in the RFC, please offer it up, but if you have no recommendation for how to close this hole, please don't get in the way. Matt Rod Dorman wrote: On Saturday, November 4, 2006, 23:14:48, Matt wrote: ... Microsoft and SmarterMail seem to have reinterpreted the RFC's to send the 550 error as soon as the message goes over size, Which is wrong. 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. Where in the RFC does it state its permissible to send replies before the completion of data transmission? 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/
