Yahoo Groups archive

Milter-greylist

Index last updated: 2026-04-28 23:32 UTC

Thread

mxsync not quite working properly

mxsync not quite working properly

2007-04-26 by nlin

Hi

I have two mail servers running milter-greylist.  I recently upgraded one 
of the servers to the latest milter-greylist, whereas the other one is 
still running 2.0.2.

And now, every few days, I will see these error messages on the upgraded 
server:

Apr 24 00:04:08 foobar milter-greylist: (mxsync): addr 129.132.145.15 from 
<xxx@xxx> rcpt <xxx@....>: autowhitelisted for -103:-29:-54

Does anyone know why it's doing that?  I'm planning to upgrade the other 
server today.  But just trying to figure out why the autowhitelist would be 
a negative number to begin with.

thanks
nancy
-- 
-- 
-------------------------------------
Nancy Lin                        DECF
1109A Etcheverry Hall    510-642-7291
Office Hours:         2PM-4PM Mon-Thu
-------------------------------------

Re: [milter-greylist] mxsync not quite working properly

2007-04-26 by Emmanuel Dreyfus

On Thu, Apr 26, 2007 at 11:36:53AM -0700, nlin wrote:
> Does anyone know why it's doing that?  I'm planning to upgrade the other 
> server today.  But just trying to figure out why the autowhitelist would be 
> a negative number to begin with.

System clock skew?

-- 
Emmanuel Dreyfus
manu@...

Re: [milter-greylist] mxsync not quite working properly

2007-04-26 by nlin

Strange.  The two servers are synced up to ntpd server via a cron job every 
30 minutes though.

nancy
-------------------------------------
Nancy Lin                        DECF
1109A Etcheverry Hall    510-642-7291
Office Hours:         2PM-4PM Mon-Thu
-------------------------------------


Emmanuel Dreyfus wrote:
Show quoted textHide quoted text
> 
> 
> On Thu, Apr 26, 2007 at 11:36:53AM -0700, nlin wrote:
>  > Does anyone know why it's doing that? I'm planning to upgrade the other
>  > server today. But just trying to figure out why the autowhitelist 
> would be
>  > a negative number to begin with.
> 
> System clock skew?
> 
> -- 
> Emmanuel Dreyfus
> manu@... <mailto:manu%40netbsd.org>
> 
>

Re: [milter-greylist] mxsync not quite working properly

2007-04-27 by Oliver Fromme

nlin wrote:
 > Emmanuel Dreyfus wrote:
 > > nlin wrote:
 > > > Does anyone know why it's doing that? I'm planning to upgrade
 > > > the other server today. But just trying to figure out why the
 > > > autowhitelist would be a negative number to begin with.
 > > 
 > > System clock skew?
 > 
 > Strange.  The two servers are synced up to ntpd server via a cron job every 
 > 30 minutes though.

Which is a perfect way to introduce system clock skew.  :-)

If you run ntpdate (or similar) at regular intervals, the
clock might be forced to make jumps, forward or backwards.
Normally, applications are not prepared to handle that
and might cause all kinds of subtle malfunctions.  I even
had cases where apps hung because they saw the same time
stamp twice during a time-out calculation.  Another typical
symptom is Makefiles sometimes failing randomly without
apparent reason.

It is much better to not run any time adjustments via cron,
but instead run ntpd as a daemon.  It will correct the
system clock continuously without jumps (except for an
initial jump at boot time if necessary, which shouldn't be
harmful).  Another advantage is that ntpd records the
drift of the local hardware clock, so it can correct it
even if you lose connection to your upstream NTP servers.

ntpdate is bad and should never be used.  I think it has
even been officially deprecated and will be removed in the
future (at least the manpage says so).

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch\ufffdftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M\ufffdn-
chen, HRB 125758,  Gesch\ufffdftsf\ufffdhrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

Python is executable pseudocode.  Perl is executable line noise.

Re: [milter-greylist] mxsync not quite working properly

2007-04-27 by nlin

Thank you for the detailed response!  I will look into ntpd instead.

nancy
-------------------------------------
Nancy Lin                        DECF
1109A Etcheverry Hall    510-642-7291
Office Hours:         2PM-4PM Mon-Thu
-------------------------------------


Oliver Fromme wrote:
Show quoted textHide quoted text
> 
> 
> 
> nlin wrote:
>  > Emmanuel Dreyfus wrote:
>  > > nlin wrote:
>  > > > Does anyone know why it's doing that? I'm planning to upgrade
>  > > > the other server today. But just trying to figure out why the
>  > > > autowhitelist would be a negative number to begin with.
>  > >
>  > > System clock skew?
>  >
>  > Strange. The two servers are synced up to ntpd server via a cron job 
> every
>  > 30 minutes though.
> 
> Which is a perfect way to introduce system clock skew. :-)
> 
> If you run ntpdate (or similar) at regular intervals, the
> clock might be forced to make jumps, forward or backwards.
> Normally, applications are not prepared to handle that
> and might cause all kinds of subtle malfunctions. I even
> had cases where apps hung because they saw the same time
> stamp twice during a time-out calculation. Another typical
> symptom is Makefiles sometimes failing randomly without
> apparent reason.
> 
> It is much better to not run any time adjustments via cron,
> but instead run ntpd as a daemon. It will correct the
> system clock continuously without jumps (except for an
> initial jump at boot time if necessary, which shouldn't be
> harmful). Another advantage is that ntpd records the
> drift of the local hardware clock, so it can correct it
> even if you lose connection to your upstream NTP servers.
> 
> ntpdate is bad and should never be used. I think it has
> even been officially deprecated and will be removed in the
> future (at least the manpage says so).
> 
> Best regards
> Oliver
> 
> -- 
> Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
> Handelsregister: Registergericht Muenchen, HRA 74606, Gesch\ufffdftsfuehrung:
> secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M\ufffdn-
> chen, HRB 125758, Gesch\ufffdftsf\ufffdhrer: Maik Bachmann, Olaf Erb, Ralf Gebhart
> 
> FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd 
> <http://www.secnetix.de/bsd>
> 
> Python is executable pseudocode. Perl is executable line noise.
> 
>

Re: [milter-greylist] mxsync not quite working properly

2007-04-27 by Emmanuel Dreyfus

On Fri, Apr 27, 2007 at 08:39:24AM +0200, Oliver Fromme wrote:
> ntpdate is bad and should never be used.  I think it has
> even been officially deprecated and will be removed in the
> future (at least the manpage says so).

ntpdate is perfect for the initial sync before ntpd or any daemon 
has started. I beleive it's even made for that purpose: ntpd will 
refuse to work if the clock skew is too large at startup.

But I agree using ntpdate with cron is a bad idea if you have your
system started. Many apps assume that (PID, time) is a unique identifier
for the system, which assume the time never goes backward.

-- 
Emmanuel Dreyfus
manu@...

Re: [milter-greylist] mxsync not quite working properly

2007-04-27 by Oliver Fromme

Emmanuel Dreyfus wrote:
 > Oliver Fromme wrote:
 > > ntpdate is bad and should never be used.  I think it has
 > > even been officially deprecated and will be removed in the
 > > future (at least the manpage says so).
 > 
 > ntpdate is perfect for the initial sync before ntpd or any daemon 
 > has started.

I'm sorry I have to disagree.  ntpdate is evil and
has to die.  :-)

Seriously, ntpd should be run with the -g option.
It does the same as running ntpdate once (i.e.
performing one initial step if necessary), but
with much better accuracy.  It completely replaces
ntpdate.

 > I beleive it's even made for that purpose: ntpd will 
 > refuse to work if the clock skew is too large at startup.

Use ntpd -g.  ntpdate is a left-over from ancient
versions of the xntpd software suite, and it only
exists for historical reasons.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch\ufffdftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M\ufffdn-
chen, HRB 125758,  Gesch\ufffdftsf\ufffdhrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"[...]  one observation we can make here is that Python makes
an excellent pseudocoding language, with the wonderful attribute
that it can actually be executed."  --  Bruce Eckel

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.