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?

As a reminder, an RFC 2307 posixGroup has a multi-valued LDAP attribute type called memberUid which is the user identifier (uid) of the member. A sample groups looks like this:

dn: cn=tgroup,ou=Groups,dc=fupps,dc=com
gidNumber: 6009
objectClass: top
objectClass: posixGroup
cn: tgroup
description: Testgroup for jP
memberUid: jpm
memberUid: janej

So, what we need is a method by which Exim finds that group (easy with a ${lookup ) and then performs another LDAP search to retrieve the mail attribute type of each of the group's members.

What I came up was was this:

ldap_posixgroups:
 driver = redirect
 data = ${map{<, ${lookup ldapm{ldap:///GROUPBASE\
          ?memberUid?sub?(cn=${quote_ldap:$local_part})}}}{\
          ${lookup ldapm{ldap:///PEOPLEB?mail?sub?uid=${quote_ldap:$item}}}\
          }}

The first ${lookup retrieves the values of the memberUid attribute type. For the group above, these are

jpm, janej

${map iterates through the comma-separated list, invoking a new (i.e. the second) ${lookup for each value which it places in $item. This second ${lookup performs a search for the mail attribute type of each of the users. For example, user janej has multiple mail addresses:

j.jolie@fupps.com, jane.jolie@fupps.com, jj@fupps.com

Putting all that together, the result will be

jp@example.de,j.jolie@fupps.com,, jane.jolie@fupps.com,, jj@fupps.com

and Exim's redirect router happily eats that (ignoring superflous commas), and it routes the message to the two users (and their four e-mail addresses).