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?