[Dovecot] Deliver bounces messages if can't write to logs
I am new to using Dovecot's LDA deliver. One particular item which I think may be improved.. If one uses logs instead of syslog and if Dovecot/Deliver can't write to the logs, mail is bounced.
In contrast if it can't connect to the authentication socket auth-master, it defers.
Shouldn't mail be deferred if access to the log files fails due to rights? Doesn defer makes more sense than to bounce in this case?
In all likelihood it was postfix that bounced/deferred, but I believe it has to do with what response postfix got from deliver.
On Tue, 2006-11-28 at 09:56 -0500, Francisco Reyes wrote:
I am new to using Dovecot's LDA deliver. One particular item which I think may be improved.. If one uses logs instead of syslog and if Dovecot/Deliver can't write to the logs, mail is bounced.
In contrast if it can't connect to the authentication socket auth-master, it defers.
Shouldn't mail be deferred if access to the log files fails due to rights? Doesn defer makes more sense than to bounce in this case?
In all likelihood it was postfix that bounced/deferred, but I believe it has to do with what response postfix got from deliver.
Well, yes.. But the problem is that Dovecot in general uses its own exit codes which Postfix doesn't understand. Errors that deliver code itself catches are returned with standard exit codes, but fatal errors elsewhere in Dovecot code are returned with the non-standard codes, which Postfix apparently treats as permanent failures.
So there are two solutions for this:
Change all Dovecot's exit codes to use the standard exit codes.
Do some kind of exit code hooking so that Dovecot's exit codes are converted to standard exit codes, but only when running deliver.
Both of these are pretty large changes, so they won't happen before v1.0..
Timo Sirainen writes:
So there are two solutions for this:
- Change all Dovecot's exit codes to use the standard exit codes.
What advantage, if any, is there to the current return codes that postfix doesn't udnerstand?
Both of these are pretty large changes, so they won't happen before v1.0..
I used a third solution... changed to use syslog. I would have preferred to use the logs since it breaks down into informative and error outputs, but bouncing mail is not good.. just because it could not connect to logs.
On Sun, 2006-12-03 at 11:59 -0500, Francisco Reyes wrote:
Timo Sirainen writes:
So there are two solutions for this:
- Change all Dovecot's exit codes to use the standard exit codes.
What advantage, if any, is there to the current return codes that postfix doesn't udnerstand?
The current exit codes were implemented to Dovecot long before deliver even existed. But there are also some advantages. Dovecot's exit codes are:
FATAL_LOGOPEN = 80, /* Can't open log file */
FATAL_LOGWRITE = 81, /* Can't write to log file */
FATAL_LOGERROR = 82, /* Internal logging error */
FATAL_OUTOFMEM = 83, /* Out of memory */
FATAL_EXEC = 84, /* exec() failed */
FATAL_DEFAULT = 89Normally all the exit codes are the FATAL_DEFAULT. In these cases Dovecot also logs the actual error message. The other codes are useful, because if any of them happens there might not be any error messages in logs, so the only way to know what happened would be to look at the exit code (which Dovecot master logs, if it can).
If I used the standard exit codes, the first 5 would be:
#define EX_OSERR 71 /* system error (e.g., can't fork) */
And the default exit code would probably be:
#define EX_TEMPFAIL 75 /* temp failure; user is invited to retry */
If EX_OSERR happens and there's nothing in the logs, there's really no way to know if the error happened because the log couldn't be written to or because memory was low.
I'm not sure why I've added FATAL_EXEC. If it happens there should also be a proper error logged.
Both of these are pretty large changes, so they won't happen before v1.0..
I used a third solution... changed to use syslog.
Well, yes, this fixes your particular problem. But there are also other rare problems which should be treated as temporary errors instead of permanent errors.
I would have preferred to use the logs since it breaks down into informative and error outputs, but bouncing mail is not good.. just because it could not connect to logs.
Shouldn't the problem also go away if you just fix it so that deliver can always write to the logs?..
Timo Sirainen writes:
Well, yes, this fixes your particular problem. But there are also other rare problems which should be treated as temporary errors instead of permanent errors.
Ideally, as your time allows.. you should code changes you see fit.. to avoid messages getting bounced in case of failure to write to the logs.
Shouldn't the problem also go away if you just fix it so that deliver can always write to the logs?
Absolutely. The problem is trivial for a single installation, but gets more interesting if one has to do it in many machines, other people will have to learn the procedure and one has to worry about log rotation and the such.
In an ideal world we would have some automated set of scripts to install and configure Dovecot. The FreeBSD port's system does most of the work already (we use FreeBSD) so it should not be too bad. My next concern would be log rotation. I think we discussed on some other email.. so I will check the archives.
participants (3)
-
Brian G. Peterson
-
Francisco Reyes
-
Timo Sirainen