Ahh! Now you've explained it, it makes a lot of sense.
Many thanks,
Mark Lidstone IT and Network Support Administrator
BMT SeaTech Ltd
Grove House, Meridians Cross, 7 Ocean Way
Ocean Village, Southampton. SO14 3TJ. UK
Tel: +44 (0)23 8063 5122
Fax: +44 (0)23 8063 5144
E-Mail: mailto:mark.lidstone@bmtseatech.co.uk Website: www.bmtseatech.co.uk
== Confidentiality Notice and Disclaimer: The contents of this e-mail and any attachments are intended only for the use of the e-mail addressee(s) shown. If you are not that person, or one of those persons, you are not allowed to take any action based upon it or to copy it, forward, distribute or disclose the contents of it and you should please delete it from your system. BMT SeaTech Limited does not accept liability for any errors or omissions in the context of this e-mail or its attachments which arise as a result of Internet transmission, nor accept liability for statements which are those of the author and not clearly made on behalf of BMT SeaTech Limited.
==
-----Original Message----- From: Timo Sirainen [mailto:tss@iki.fi] Sent: 23 August 2004 09:07 To: Mark Lidstone Cc: dovecot@dovecot.org Subject: RE: [Dovecot] Unusual behaviour
On Mon, 2004-08-23 at 08:48 +0100, Mark Lidstone wrote:
Is it supposed to give the current time and date in the error message.
I've no problem with it giving an "internal error" message to the client, but I am a little confused about the time being in there. That's all I'm asking about.
Client should never see any "real" error messages to make sure no extra information about the system gets leaked. So any time something unexpected happens, Dovecot gives the "internal error" message to user while writing the real error to log file.
The timestamp is there to help sysadmin find the real error message from log files when user gives a copy&pasted internal error message. Instead of timestamp I guess there could be also some unique identifier which could be grepped from logs but I think timestamp is better.
And about the original problem of giving "internal error" when Dovecot process didn't have access to some maildir.. Maybe it could have replied "Permission denied" to client in that case. It already does in several cases, but I guess the problem here was that it was trying to create the missing dirs but couldn't. I'll look over all these permission issues properly when creating real shared folder support.