On Wed, 2007-12-12 at 15:11 +0100, Rudy Gevaert wrote:
Kjetil Torgrim Homme wrote:
I'm not sure that the redirect action failed in this case. it
successfully passed the message on to Sendmail. in general, you can't
guarantee that the next hop will be successful.
I think it depends on what you see as 'failed' or 'succeeded'. :)
Nov 22 17:29:41 manaslu mail6/lmtp[9186]: sieve runtime error for
jeanmarie^noterdaeme(_at_)ugent(_dot_)be id
<4745AC91(_dot_)30707(_at_)ugent(_dot_)be>: Redirect:
Sendmail process terminated normally, exit status 69
In this case it was given successfully to sendmail, but sendmail didn't
forward it, it even exited with status 69. But that seems to be ok for
the cyrus implementation.
this is a quality of implementation issue, IMHO. as long as only *some*
types of errors can be discovered, and the types depend on
implementation strategy, I don't think it is appropriate for the Sieve
spec to make a list.
The only problem that remains is that the user still has login to his
mailbox to see the notification if the redirect action doesn't work (in
that case).
yes, this is unfortunate. a Sieve implementation is allowed to use
other notification methods if they're available, though. (e.g. the user
allows XMPP)
I think it is too onerous to require the "redirect" delivery to be
successful.
if a "redirect" delivery failure causes the script to fail, the Sieve
implementation can not rely on MDN to do the reporting, it has to keep
track of delivery success or failure itself. this is a bit awkward,
since it has to maintain its own queue, you can't just hand it off to
your MTA via "Sendmail-API", since there is no back-channel to the
submitter. what's worse -- the script can't terminate until the
delivery is done, which can take days! what would happen to commands
after the "redirect" in the script? should they be postponed?
obviously not.
Sorry, I don't understand what you are trying to say.
not sure if I'm able to state it more clearly, but I'll try.
current status is (as I understand the spec) that a redirect action
succeeds as long as it is syntactically correct. the Sieve
implementation isn't even required to check the supplied address for
syntax validity.
if you want the success of the redirect action to depend on the success
of the actual forwarding of the e-mail, you need a tight integration of
the sending action in your Sieve implementation. the server you're
redirecting to may be down, and then Sieve will have to queue the
message, and postpone the remainder of the Sieve script until the
redirect action returns with a definite answer. this is not workable,
IMHO.
--
regards,
Kjetil T.