Re: [Sqlgrey-users] DST change and localtime

[Michel B. <mi...@bo...>]

Le Dimanche 20 F=E9vrier 2005 07:51, Klaus Alexander Seistrup a =E9crit :
>
> I was actually imagining several sqlgrey daemons connecting to the
> same central database, but of course the scenario you mention is also
> possible.

I seems more logical to have several MTAs use the same SQLgrey server, ra=
ther=20
than having several SQLgrey servers share the same database.

> >> What happens to localtime() timestamps (and intervals) as we pass fr=
om
> >> standard time to daylight saving time?
> >
> > Not much. Addresses in AWLs may be kept one hour more or less than
> > planned (let's say 1 month +/- 1 hour instead of 1 month), which does=
n't
> > really matter, does it ?
> >
> > Addresses in connect will be kept waiting for a reconnection for 1
> > more/less hour, which shouldn't have a big incidence either.
>
> It doesn't matter much, but the difference is there.

Yep. But this difference makes no difference on a practical standpoint.

> > What may be more noticeable is that, at the time the DST changes (in =
the
> > middle of the night) the "minimum time before accepting reconnection"=
 may
> > become one hour longer, or not enforced at all, for one hour.
>
> It will be in the middle of the night at the database machine, but
> mail might be fetched with e.g. IMAP/POP from everywhere on the globe,
> or forwarded from the MX to other mail accounts in other timezones.
>
> > The practical consequences for this will be IMHO insignificant.
>
> Whether it will be insignificant will depend on the actual sitation
> and use of that particular MX.=20

First, having an MTA and its SQLgrey server separated by several timezone=
s=20
doesn't look like a good idea on both a performance and reliability=20
standpoint. This would be especially true between a primary and backup MX=
,=20
who IMHO should definitely not share the same SQLgrey server or database,=
 as=20
it would create a single point of failure.

Second, let's be more precise about what may happen when the DST time cha=
nges:

- First note that this will only affect connections that are in the "new"=
=20
status (in the connect table). Connections already known to the AWLs won'=
t be=20
affected.

- When going from winter time to summer time (2AM suddenly becomes 3AM), =
it=20
will only affect connections that first came between (2AM - reconnect_del=
ay)=20
and 2 AM (which makes typically 5 minutes...).

These connections will be allowed to come back a little SOONER than it wo=
uld=20
normally happen : Let's say the first connection comes at 1:58 and=20
reconnect_delay is 5 minutes. Connection normally wouldn't be accepted ag=
ain=20
before 2:03, but 2:00 suddenly becomes 3:00, so reconnection will be=20
accepted, which results in having reduced the reconnect_delay from 5 to 2=
=20
minutes. This will happen only for connections that were first seen betwe=
en=20
1:55 and 2:00...

And this will have no practical incidence.


- When going from summer time to winter time (3AM becomes 2AM again, and =
1=20
hour is repeated), the phenomenon will be a little more complex, but yet =
will=20
affect only first connections in the "connect" table.

Let's say a connection first comes at 2:45 and reconnect_delay is 5 minut=
es.=20
Reconnection will be accepted after 2:50. Now if the reconnection doesn't=
=20
happen between 2:50 and 3:00, at 3:00, times goes back to 2:00 and=20
reconnection won't be accepted until it is 2:50 again.
This creates a maximum "one hour greyhole" for a reconnection in the midd=
le of=20
the night, on hour being the maximum (connections that first came in at 2=
:10=20
and would be accepted at 2:15, for example, will only suffer a 15' greyho=
le=20
if they hadn't reconnected before 3:00, when it becomes 2:00 again)

On a practical standpoint, having this happen once a year in the middle o=
f the=20
(local ;-) night won't make any difference for the vast majority of users=
 and=20
messages -- Note that greylisting a message always causes a delay over wh=
ich=20
we don't have any control, because we can't control the incoming MTA's re=
try=20
rate. Sometimes refusing a mail for 3 minutes will actually have it defer=
red=20
for several hours if the remote MTA doesn't retry before several hours...


So yet, this DST change story has a _little_ influence, but this influenc=
e is=20
so little that it can practically be ignored IMHO.

> IMHO the only sane thing to do when dealing with timestamps for other t=
han
> human consumption is to use UTC.

Theoretically, yes, but there are always exception cases. Here, keeping t=
he=20
database in local time will be more understandable for the admin who take=
s an=20
human look ;-) inside the database, and makes no real difference in the w=
ay=20
the system works.

It is also worth noting that SQLgrey logs its activity in the same system=
 mail=20
log as Postfix, and Postfix logs in local time... So to keep everything=20
coherent, it's better having SQLgrey log (and work) in local time as well=
...

Cheers.

--=20
Michel Bouissou <mi...@bo...> OpenPGP ID 0xDDE8AC6E

La plus grave maladie du cerveau c'est de r=E9fl=E9chir.
	-- Ko=E2n Shadok