> 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/
