Hi tech@,
While investigating missing system mail, I found out the messages were in
/var/spool/smtpd/offline
One of them actually contains the explanation for why these were missing:
======
/etc/mtree/4.4BSD.dist diffs (-OLD +NEW)
======
--- /var/backups/etc_mtree_4.4BSD.dist.current Thu Sep 10 01:31:47 2015
+++ /etc/mtree/4.4BSD.dist Mon Oct 12 09:56:06 2015
@@ -1,4 +1,4 @@
-# $OpenBSD: 4.4BSD.dist,v 1.273 2015/08/24 10:41:11 ajacoutot Exp $
+# $OpenBSD: 4.4BSD.dist,v 1.274 2015/10/10 09:45:15 ajacoutot Exp $
/set type=dir uname=root gname=wheel mode=0755
@@ -779,7 +779,7 @@
..
incoming type=dir uname=_smtpq gname=wheel mode=0700
..
- offline type=dir uname=root gname=wheel mode=1777
+ offline type=dir uname=root gname=_smtpq mode=0770
..
purge type=dir uname=_smtpq gname=wheel mode=0700
..
This seems perfectly logical to be the probable result of missing a beat
or two in following current snapshots to reflect following system change
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/etc/mtree/4.4BSD.dist.diff?r1=1.273&r2=1.274
It turns out that by coincidence inability to write to /var at one point
had resulted in the messages being put as uid root gid wheel, as per the
previous directory ownership, which in turn prevented start up delivery.
They were spooled as:
# ls -l /var/spool/smtpd/offline | sed 4q
total 268
-rw------- 1 root wheel 163 Oct 10 2015 1444473745.kT9rSONRgT
-rw------- 1 root wheel 2282 Oct 11 2015 1444516201.eWN5Bf8X52
-rw------- 1 root wheel 57886 Oct 11 2015 1444516388.gQjkO6FQqh
They should have been:
# ls -l /var/spool/smtpd/offline | sed 4q
total 268
-rw------- 1 root _smtpq 163 Oct 10 2015 1444473745.kT9rSONRgT
-rw------- 1 root _smtpq 2282 Oct 11 2015 1444516201.eWN5Bf8X52
-rw------- 1 root _smtpq 57886 Oct 11 2015 1444516388.gQjkO6FQqh
The question here pops up, is it reasonable to include in smtpd start up
checks permission fix for messages contained in /var/spool/smtpd/offline
so they are processed and also delivered as intended instead of skipped?
In my basic logic, directory changes should propagate into them, also if
a program expects to process a directory's contents, it shouldn't block,
so probably the suggestion would be to fix the permissions and continue.
This case would repeat again if at some point a spool in use is changed.
I see this may rarely be needed yet will result in improved reliability.
If such a check is considered meaningful, where else would it be useful?
Kind regards,
Anton
