A few days ago I noticed a large number of message delivery failures to a Domino server. They were all similar:
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
j.jolie@domino.example.com
SMTP error from remote mail server after end of data:
host domino.internal.example.com [10.8.4.3]:
_554 Error writing message to safe storage; message could not be stored to disk_
The fact that the error indicates a problem in writing message to safe storage can really only be disk related (out of space, damaged mail.box, or perhaps full transaction logs), but why did this machine return a permanent 5xx code? There is no way for the sending MTA to react to that – it will bounce the message as undeliverable.
I don’t administer these Domino servers, so I asked the administrators what had happened. It turns out one of the disks on this particular server had filled up. (Monitoring, anybody?)
I maintain that a 5xx code is wrong here; it should be a softer 4xx.
Just to be sure, I thought I’d test that on two different MTA. I chose to take a copy of the venerable sendmail running on FreeBSD.
When sendmail detects that disk space is running low
(confMIN_FREE_BLOCKS
), it starts rejecting messages. The log shows
rejecting new messages: min free: nnn
Let me now have a look at an SMTP transaction to that server:
<- 220 nanob1.mens.de ESMTP Sendmail 8.14.3/8.14.3
-> EHLO home.mens.de
<- 250-nanob1.mens.de Hello home.mens.de [192.168.1.20], pleased to meet you
<- 250-ENHANCEDSTATUSCODES
<- 250-PIPELINING
<- 250-8BITMIME
<- 250-SIZE
<- 250-DSN
<- 250-ETRN
<- 250-DELIVERBY
<- 250 HELP
-> MAIL FROM:<jpm@home.mens.de>
_< 452 4.4.5 Insufficient disk space; try again later_
-> QUIT
<- 221 2.0.0 nanob1.mens.de closing connection
The sender, correctly, gets a non-permanent 4xx code, so it has a chance to retry later. As soon as disk space becomes available, sendmail indicates
accepting new messages (again)
in the log, and it is then readily available to accept new messages.
I then took a system running Exim. After getting the disks filled up with
a some incantation of dd, I let off a few mails directed to that
Exim box. Here again, this server correctly refuses to accept a message
if its configured limits of free space (check_spool_space
) don’t provide
enough free space (and/or free inodes).
spool directory space check failed: space=nnnn inodes=mmmm
The sending MTA sees:
<- 220 home.mens.de ESMTP Exim 4.43 Thu, 04 Feb 2010 11:18:18 +0100
-> EHLO jmbp.local
<- 250-home.mens.de Hello jmbp.local [192.168.1.154]
<- 250-SIZE 20971520
<- 250-PIPELINING
<- 250 HELP
-> MAIL FROM:<jpm@jmbp.local>
_< 452 Space shortage, please try later_
-> QUIT
<- 221 home.mens.de closing connection
Here again, the target Exim server behaves correctly: the sending MTA gets a 4xx code and can attempt to transfer the message at a later point.
RFC 2821 even provides for this particular code:
452 Requested action not taken: insufficient system storage
Why does Domino return a permanent 5xx code? Richard agrees it shouldn’t because the reason isn’t message-specific. Are these servers simply incorrectly configured?