On Wed, 2007-12-12 at 10:46 +0100, Rudy Gevaert wrote:
RFC3028 and the latest draft of RFC3028bis state in section 2.10.6.
2.10.6. Errors
...
When an error happens, implementations MUST notify the user that an
error occurred, which actions (if any) were taken, and do an implicit
keep.
We are using Cyrus Imapd and their sieve implementation. I found out of
the following problem last week. Our incoming mail relays accept email
with a size limit of 12MB. We have users that have sieve redirect
scripts on the backend mail stores. As you know to forward the email a
sendmail forward is used (as stated in the RFC, but this is left out in
the latest draft). Because of an unfortunate oversight the postfix that
runs on the mail stores (and thus it is postfix providing the sendmail
binary) did have its message size limit set to 10MB. Forwarding
messages greater than 10MB didn't work. [...]
I understand that the RFC says the user needs to be notified, but this
doesn't happen.
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 agree that the issue is implementation specific, but
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.
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.
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.
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.
(b) I would say by email, but depending who the user is, there could be
problems. E.g. if he is forwarding all incoming email to an other
address, it depends if he will be notified (mail could be lost). If the
forwarding mechanism is broken the mailadmin should be notified.
the implementation MUST be able to do a "keep". if it can't do that, it
should not have accepted the message in the first place.
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.
--
best wishes,
Kjetil T.