On Sat, Nov 05, 2016 at 10:03:32AM +0200, [email protected] wrote: > 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? >
I don't think it is reasonable. First of all there shouldn't be a case where the permissions needs to be fixed in the first place, if something hits queue with wrong permissions there is something really worrying that shouldn't be fixed without admin deciding to do so. Then, we have changed permissions only twice in about 9 years of smtpd. Both times we only required a one-time fix, kind of a flag day, to make the transition and never hear about it again. It doesn't make sense for me to add code that will stay in the daemon to cope with events as rare as these, particularly now that queue has the privileges we want and is not likely to see changes any time soon. -- Gilles Chehade https://www.poolp.org @poolpOrg
