Re: [IMail Forum] IMail ignores EHLO message size limits??? Bad...

[Matt]

Ok, I found the following from Ipswitch's site and the IMail 8.1 manual: http://www.ipswitch.com/support/imail/guide/imailug8.1/Chapter%205%20smtp2.html The SMTP Server supports the following Request for Comments (RFCs): * RFC 2821 and 2822 SMTP * RFC 1869 SMTP Service Extensions * RFC 1870 SMTP Service Extension for Message Size Declaration * RFC 1891,1892,1893,1894 SMTP Service Extension for Delivery Status Notifications * RFC 1985 SMTP Service Extension for Remote Message Queue Starting. Currently, IMail Server provides support for "ETRN host.name" and "ETRN @domain.name." For more information, see "Using ETRN to Retrieve Mail". * RFC 2222 SMTP Service Extension for Authentication. IMail Server supports PLAIN, LOGIN, and CRAM-MD5. So it would seem that this is either broken in 8.15 HF1, or it was never implemented properly.  Although the stuff in RFC 1870 is largely optional, it is pointless to not support the one thing that this RFC is all about. In my case, IMail should have sent the size within the MAIL FROM command to stay true to this RFC as so:     MAIL FROM:<[EMAIL PROTECTED]> SIZE=41874785 Then the receiving server should have returned an immediate 552 error upon seeing the excessive size (552: message exceeds fixed maximum message size) and IMail should have sent a QUIT command and then generated a bounce. Matt Sanford Whiteman wrote: The receiving server does have a problem in that a return code should be sent, temporary or permanent (4xx or 5xx). It's not always possible to send a return code in standard RFC sequence if the intent is to prevent flooding by oversize messages. An out-of-order return code may be sent in full-duplex during data transmission; the RFC compliance of full-duplex at that point in the envelope is doubtful, though, and it's certainly not supported by enough clients to be adequate (a different topic, though). Where does it state that this RFC does not require the sending (client) machine to pay attention to this parameter? The RFCs are not concerned with whether both client (QUEUEMGR) and server (SMTPD) components of a mail suite need to be compliant with the client and server actions of RFC 1870 in order for the _suite_ to claim RFC 1870 compliance. IMail does claim compliance with 1870, but it is far from unprecedented (not just with Ipswitch products) for a product to amplify partial RFC compliance for marketing purposes. That's what it looks like to me. --Sandy ------------------------------------ Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release/ Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.imprimia.com/products/software/freeutils/exchange2aliases/download/release/ http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/release/ 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/