Hello,
I have subscribed to this list to report a (possible) problem with error
reporting. Please accept my apologies if this is not the correct place
to report it or if I'm not following the list policy.
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.
In my logs I saw that like this:
Nov 22 17:29:40 manaslu postfix/postdrop[23167]: warning: uid=980: File
too large
Nov 22 17:29:40 manaslu postfix/sendmail[23166]: fatal:
((_dot_)(_dot_)(_dot_)(_at_)(_dot_)(_dot_)(_dot_))(980):
Message file too big
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
I don't know the underlying architecture here, but it isn't obvious
to me that this is a redirect error. Redirect reinjects a message into
the transport infrastructure. That message can bounce at some subsequent
point even though the redirect itself was succesful.
FWIW, the way we handle redirect in our implementation is to put a copy of the
message with new recipients in what amounts to a submission queue. The
submission may fail at a later point but that doesn't prevent the redirect from
completing succesfully in almost all cases.
I understand that the RFC says the user needs to be notified, but this
doesn't happen. I agree that the issue is implementation specific, but
I want to raise the following questions.
a) Who is the user?
The owner of the sieve.
b) How must the user be notified?
That's implementation-specific. Again FWIW, we do this by sending a special
notification message to the sieve owner.
For (a) you would be assume it is the user who set the sieve script.
Yes, but note that admins can and do set up sieves for users but in such a case
it isn't clear they're the ones who should receive error notifications.
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).
Maybe, maybe not. It's a question of intent. If the redirect is to, say,
a remote archive and the main copy of the message was delivered normally,
notifying the sender about a copy they don't know and don't care about,
may end up causing more problems than it solves.
(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).
Remember that in the event of an error the sieve result is ignored and
a keep is performed. This mitigates at least some of the issues of
using email to make the report.
If the
forwarding mechanism is broken the mailadmin should be notified.
It really depends on how it's problem.
Maybe the RFCbis could be clearer on some points?
A bit late for that now that 3028bis is about to come out as an RFC.
Ned