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.
I want to raise the following questions.
a) Who is the user?
b) How must the user be notified?
For (a) you would be assume it is the user who set the sieve script.
yes.
But actually it should be (in this case) the sender that at least gets a
message that the email could not be forwarded (it delivered, but not to
the final destination).
why? there's nothing wrong with notifying the sender as well (but
please limit backscatter!), but it's the recipient (script owner) who
needs to be notified that his filter failed so that he can fix it.
Now that I gave it an other thought I think the user who set the forward
should be notified. The notification should be put in his inbox. I'm
saying this because:
- you can't rely on the redirect action to actually work, so if the
forward doesn't work the notification will be put in his inbox
- the redirect action could be set up for a specific action
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).
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.
the Cyrus implementation does not perform actions as it runs through the
script, it collects a list of actions which should be taken, and
performs these *after* the script has finished. I think this is a
perfectly reasonable approach.
I can't comment on this, I would have to look at the source.
BTW, in Cyrus (at least 2.2.x), a redirect is implemented as a message
submitted with the cyrus system user as the envelope sender, so failed
redirects go to the mail admin. this is not a Sendmail forward, since
that keeps the envelope sender from the original message. it would
probably be good to make Cyrus compliant here.
This is already the case in 2.3.10
Maybe the RFCbis could be clearer on some points?
publication of 3028bis as RFC 5228 is imminent, so it will almost
certainly have to wait until 3028ter.
some text to clarify success or failure of "redirect" might be a good
idea.
I would think so too.
Rudy
--
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Rudy Gevaert Rudy(_dot_)Gevaert(_at_)UGent(_dot_)be tel:+32 9
264 4734
Directie ICT, afd. Infrastructuur ICT Department, Infrastructure office
Groep Systemen Systems group
Universiteit Gent Ghent University
Krijgslaan 281, gebouw S9, 9000 Gent, Belgie www.UGent.be
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --