OK, I know the "Network Failure System" is a bad thing to begin
with, but at work I have no choice but to use qmail with NFS.
Here's the scenario and then I'll get to the annoyance (yes, just
one, for now) I ran into. (All of this is happening on a GNU/Linux
platform).
We have a master file server where everyone's home dirs live. This
server, "bigbird", allows local machines to mount the home dirs as
needed (NFS clients are using autofs tricks to mount the NFS
shares). There is an MX box called "mail" which delivers mail to
the users' home dirs (in Maildir format) on bigbird via NFS.
"mail" also runs qmail-pop3d.
When initially setting this all up and testing it, there was about a
minute delay between sending mail and being able to retrieve it
pop3. After some careful inspection I noticed that the mail
messages in ~/Maildir/new/ had modification times about a minute in
the future relative to the time on the "mail" machine (again,
~/Maildir/new/ resides on "bigbird" and is spoken to by "mail" via
NFS). "bigbird"'s clock was about a minute faster than "mail"'s.
I'm curious as to how qmail-pop3d looks at messsages in
~/Maildir/new/, why it seems to ignore "messages from the future"
and why it seems to care about the modification time in the first
place. Messages in ~/Maildir/new/ are, um.. new? right?
Regardless of when they were created?
I'm rather new to NFS and I'm not fond of it but it has to hang
around. A short term solution has been to set bigbird's clock back
a little bit, at least realtive to the mail box's clock. Long term
solution will likely be to run NTP.
Any other non-disparaging thoughts on this issue will be
appreciated. ;-)
Regards,
kw
