Re: [iMS] Retry Bounces question

[David D Droddy]

RFC stipulates the following:   "The class sub-code provides a broad classification of the status.    The enumerated values the class are defined as:     2.X.X   Success        Success specifies that the DSN is reporting a positive delivery        action.  Detail sub-codes may provide notification of        transformations required for delivery.     4.X.X   Persistent Transient Failure        A persistent transient failure is one in which the message as        sent is valid, but some temporary event prevents the successful        sending of the message.  Sending in the future may be successful.     5.X.X   Permanent Failure        A permanent failure is one which is not likely to be resolved by        resending the message in the current form.  Some change to the        message or the destination must be made for successful delivery."    So, I guess we CAN make our own conclusions from the detailed reason data, but it does seem to me that the interpretation of the code by iMS sort of steps away from the RFC spec.   ----- Original Message ----- From: Keith Ivey To: inFusion Support List Sent: Monday, June 14, 2004 12:22 PM Subject: Re: [iMS] Retry Bounces question David D Droddy wrote: > If we report that a message failed for transient reasons, the sender > may attempt send to the recipient again in the future. If we report > that a message failed for more fatal reasons, the sender may consider > contacting the recipient to correct the email address or we may try to > find out if a spam filter or firewall is blocking the message in which > case we will attempt to assist the sender in resolving the issue. It seems to me that there's no real difference between the way you should handle a "temporary" failure that goes on for days and a "permanent" failure, especially considering the wide variety of mail system configurations (and misconfigurations) out there.  In either case, if you're really interested in contacting the person you have to use a different means or try to involve the admin of the receiving server.  I don't think most end users know or care about the distinction. -- Keith Ivey <[EMAIL PROTECTED]> Washington, DC ==^======================================================= This list server is Powered by iMS  "The Swiss Army Knife of Mail Servers" -------------------------------------------------------------------------------------- This list is provided as a free service.  Although we will try to address issues in a timely manner, support via this list is not guaranteed.  If you require expedited support then a support contract is required.  Support may be purchased from http://www.coolfusion.com/commerce.  Details regarding support options may be reviewed at: http://www.coolfusion.com/SupportOptions.cfm -------------------------------------------------------------------------------------- To leave this list please complete the form at http://www.coolfusion.com/Support/ Need an iMS Developer license?  Sign up for a free license here: http://www.coolfusion.com/Developers/ List archives: http://www.mail-archive.com/infusion-email%40eoscape.com/ Note: You are subscribed as [EMAIL PROTECTED] ==^======================================================= This list server is Powered by iMS "The Swiss Army Knife of Mail Servers" This list is provided as a free service. Although we will try to address issues in a timely manner, support via this list is not guaranteed. If you require expedited support then a support contract is required. Support may be purchased from http://www.coolfusion.com/commerce. Details regarding support options may be reviewed at: http://www.coolfusion.com/SupportOptions.cfm. To leave this list please complete the form at http://www.coolfusion.com/Support/ Need an iMS Developer license? Sign up for a free license here: http://www.coolfusion.com/Developers/ List archives: http://www.mail-archive.com/infusion-email%40eoscape.com/ Note: You are subscribed as [EMAIL PROTECTED]