> There's no way I would support an MTA of mine meekly sucking in a > 100 Mb msg just to wait for the RFC-opportunity to say: "sorry, that > was too big by 97 Mb."
I would, because I respect standards as the building blocks of interoperable software, rather than following the whims of gorillas who run crappy free webmail sites. If this is such a wonderful practice, where's Microsoft's RFC on it? Just because it appears to be a security measure doesn't mean it's any more forgivable than their "value-added" measures that screw up people playing by the only published rules. If you're panicked about purposeful DoS attacks, then accept the first couple of oversize e-mails as accidents, next just 5xx all future attempts from that IP well before the DATA command, then start catching them at the host-based socket level, and finally at the firewall and router--just as you would any other attack vector. If this kind of attack becomes common, it's a sure thing that there will be a blacklist to match. Additional criteria for such blacklisting would be repeated discrepancies between the ESMTP SIZE command and the actual received size.* -Sandy * Also note further support from RFC 1870: > 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. This section makes it clear that *even in a conventional request-reply scenario*, 552ing a message whose SIZE was announced correctly is questionable. But my major point is that circumventing the Request-Reply sequence is never acceptable. Only (a) inefficient code, or (b) code driven by fear of M$, would let such behavior go unquestioned. 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/
