Re: [IMail Forum] Maximum size email

[Matt]

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?