~From: Noel J. Bergman ~ There is a window within which to PREVENT loss, there is the remote ~possibility of a duplicate transaction. we are not running a guaranteed message deliver service within James ... there is a window - however small - of either loss or duplicates; depending on how the transfer validation was implemented. i may be anal about this but SMTP is not a guaranteed delivery mechanism and neither is the internal spool/queue that we are using. for all intents and purposes, we can rest assured that the window of loss/duplication is very small - but there IS a window. we can not pretend that it doesn't exist or that SMTP is a guaranteed message delivery system; that's just plain foolish.
~> i have scenario that the sender receives a positive from James ~> when it in fact cannot respond - positive or negative as the ~> db is unavailable. ~In point of fact, if the database is unavailable when the ~handler receives e-mail from the sender, it will return an error to the sender. no, this is incorrect as i have pointed out in the dev list. i will need to upgrade to the next official release or run several unsanctioned patches to correct this - but for a commercial ISP, it cannot be expected to run a development version. as far as i am concerned, this is a problem that is being addressed - but it does exist. alan -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
