Alan, some clarifications,
> I understand you explaination - this is to be a behaviour of > the smpt handler and not necessarily a function of > configuration/mailets. > > this is an important function - to properly notify the > sender of any problems in receiving the mail. Yes, the SMTP handler should inform the connected sending SMTP host of anything that prevents the message being accepted succesfully by the use of the standard and extended response codes. But... technically speaking this does not preclude James from succesfully accepting a message which cannot be succesfully delivered or forwarded. Which is normally notified by means of a "bounce" error-reporting mail message. This may indeed be Catch-22 Yosarian, its certainly the kind of semantic nicety lawyers enjoy, but it doesn't open any loopholes for mail to fall through, and it does comply with the published standards. Your problem was that the first part isn't being honoured in your case, so the second is irrelevant. d. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
