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: firstname.lastname@example.org 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.
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:<email@example.com> _< 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:<firstname.lastname@example.org> _< 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?