> 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.
Right. We never promised that "upgrade to snapshot" or "make build new source" would be 100.000% equiv to a fresh install. Nor should we make the tools "repair" misconfigurations of that type.
