Received mail timestamp is off by 7 hours

[Luke]

>> 1) NTP is difficult to configure.  I've done it, but it wasn't trivial.
>
> 	It's always seemed rather straightforward to me, what in particular 
> gave you trouble, perhaps we could help?

Well, there seemed to be two different services.  One was something that 
would run only on boot.  The other was a daemon.  The daemon seemed more 
useful, especially for a system that shouldn't be rebooted often, but it 
had a wide variety of configuration options.  The NTP server that I found 
to connect to insisted that I not connect to it more frequently than X, 
and X was a longer time interval than was defined in the default setup, so 
I had to mess around with it.
It's been almost a year since I tried to set this up, so I don't remember 
anything more specific than that.  If the NTP server I was using had been 
a bit more permissive, I probably could've used the default configuration 
without changes.

>> 2) Finding an NTP server willing to accept traffic from the public isn't 
>> easy either.  For me it involved a scavenger hunt through out-of-date 
>> websites and a lot of failed attempts.
>
> 	time.nist.gov is public, and has it's own atomic clock.  A google 
> search for "public ntp servers" also found this:  http://www.pool.ntp.org/

Thanks for the tip!  I remember seeing www.pool.ntp.org before, but I 
misunderstood what it was for.

>> 3) If your clock tends to run noticably fast or slow, constant NTP 
>> corrections tend to do more harm than good, at least in my experience.  It 
>> got to where I couldn't even run a buildworld because NTP kept tinkering 
>> with the clock in the middle of the process.
>
> 	That suggests larger problems on your system, to me, but I dunno.

You're right.  This machine did have serious problems.  The clock was 
wild.  Using the NTP daemon to try to correct it just aggravated the 
situation because calibration was just about impossible.