Eric Knudstrup | 23 Sep 03:12 2010

postgrey database clock problem

I think I came up with an issue where my server's clock was off by a 
number of days after a reboot, then when NTP came back on entries in the 
postgrey db were days off.  This resulted in some mail being effectively 
permanently bounced that had been greylisted during that window.
Would it be reasonable to nuke entries in the db that were off by 
ridiculous amounts to catch this sort of error?

--

-- 
Unsubscribe mailto:postgrey-request@...?subject=unsubscribe
Archive     http://lists.ee.ethz.ch/postgrey
WebAdmin    http://lists.ee.ethz.ch/lsg2.cgi

lst_hoe02 | 23 Sep 21:42 2010
Picon

Re: postgrey database clock problem

Zitat von Eric Knudstrup <eric@...>:
> I think I came up with an issue where my server's clock was off by a
> number of days after a reboot, then when NTP came back on entries in the
> postgrey db were days off.  This resulted in some mail being effectively
> permanently bounced that had been greylisted during that window.

Huh? Why bounce? Postgrey only ever should deliver a 4xx reply code.  
Do you mean greylisted for too long?

> Would it be reasonable to nuke entries in the db that were off by
> ridiculous amounts to catch this sort of error?

This would imply that you tell Postgrey when your clock is right  
because otherwise this would also trigger when your clock is totally  
wrong and start to expunge correct entries.

Regards

Andreas

-- Attached file removed by Ecartis and put at URL below --
-- Type: application/pkcs7-signature
-- Desc: S/MIME Cryptographic Signature
-- Size: 5k (6046 bytes)
-- URL : http://lists.ee.ethz.ch/p/56-smime.p7s

--

-- 
Unsubscribe mailto:postgrey-request@...?subject=unsubscribe
Archive     http://lists.ee.ethz.ch/postgrey
WebAdmin    http://lists.ee.ethz.ch/lsg2.cgi
(Continue reading)

Eric Knudstrup | 23 Sep 21:54 2010

Re: postgrey database clock problem

On 09/23/2010 12:42 PM, lst_hoe02@... wrote:
> Zitat von Eric Knudstrup<eric@...>:
>    
>> I think I came up with an issue where my server's clock was off by a
>> number of days after a reboot, then when NTP came back on entries in the
>> postgrey db were days off.  This resulted in some mail being effectively
>> permanently bounced that had been greylisted during that window.
>>      
> Huh? Why bounce? Postgrey only ever should deliver a 4xx reply code.
> Do you mean greylisted for too long?
>    
Yes, greylisted for too long.
>    
>> Would it be reasonable to nuke entries in the db that were off by
>> ridiculous amounts to catch this sort of error?
>>      
> This would imply that you tell Postgrey when your clock is right
> because otherwise this would also trigger when your clock is totally
> wrong and start to expunge correct entries.
>    
I'm getting early-retry log entries for 1000000 seconds.  Would 
comparing this to the minimum timeout have other implications?

Eric

--

-- 
Unsubscribe mailto:postgrey-request@...?subject=unsubscribe
Archive     http://lists.ee.ethz.ch/postgrey
WebAdmin    http://lists.ee.ethz.ch/lsg2.cgi

(Continue reading)

lst_hoe02 | 24 Sep 10:21 2010
Picon

Re: postgrey database clock problem

Zitat von Eric Knudstrup <eric@...>:
> On 09/23/2010 12:42 PM, lst_hoe02@... wrote:
>> Zitat von Eric Knudstrup<eric@...>:
>>
>>> I think I came up with an issue where my server's clock was off by a
>>> number of days after a reboot, then when NTP came back on entries in the
>>> postgrey db were days off.  This resulted in some mail being effectively
>>> permanently bounced that had been greylisted during that window.
>>>
>> Huh? Why bounce? Postgrey only ever should deliver a 4xx reply code.
>> Do you mean greylisted for too long?
>>
> Yes, greylisted for too long.
>>
>>> Would it be reasonable to nuke entries in the db that were off by
>>> ridiculous amounts to catch this sort of error?
>>>
>> This would imply that you tell Postgrey when your clock is right
>> because otherwise this would also trigger when your clock is totally
>> wrong and start to expunge correct entries.
>>
> I'm getting early-retry log entries for 1000000 seconds.  Would
> comparing this to the minimum timeout have other implications?

It may be possible to include a saftey net in ignoring future  
date/times, but if your clock jump to future date the nightly expunge  
will cut you datastore anyway.

Regards

(Continue reading)

lst_hoe02 | 24 Sep 11:22 2010
Picon

Re: postgrey database clock problem

Zitat von Eric Knudstrup <eric@...>:
> On 09/23/2010 12:42 PM, lst_hoe02@... wrote:
>> Zitat von Eric Knudstrup<eric@...>:
>>
>>> I think I came up with an issue where my server's clock was off by a
>>> number of days after a reboot, then when NTP came back on entries in the
>>> postgrey db were days off.  This resulted in some mail being effectively
>>> permanently bounced that had been greylisted during that window.
>>>
>> Huh? Why bounce? Postgrey only ever should deliver a 4xx reply code.
>> Do you mean greylisted for too long?
>>
> Yes, greylisted for too long.
>>
>>> Would it be reasonable to nuke entries in the db that were off by
>>> ridiculous amounts to catch this sort of error?
>>>
>> This would imply that you tell Postgrey when your clock is right
>> because otherwise this would also trigger when your clock is totally
>> wrong and start to expunge correct entries.
>>
> I'm getting early-retry log entries for 1000000 seconds.  Would
> comparing this to the minimum timeout have other implications?

You may try the following patch against Postgrey 1.33 :

 <at>  <at>  -365,7 +365,7  <at>  <at> 
          # whitelist if count is enough
          if(defined $cawl_count and $cawl_count >=  
$self->{postgrey}{awl_clients})
(Continue reading)

lst_hoe02 | 24 Sep 11:37 2010
Picon

Re: postgrey database clock problem

Zitat von lst_hoe02@...:
> Zitat von Eric Knudstrup <eric@...>:
>> On 09/23/2010 12:42 PM, lst_hoe02@... wrote:
>>> Zitat von Eric Knudstrup<eric@...>:
>>>
>>>> I think I came up with an issue where my server's clock was off by a
>>>> number of days after a reboot, then when NTP came back on entries in the
>>>> postgrey db were days off.  This resulted in some mail being effectively
>>>> permanently bounced that had been greylisted during that window.
>>>>
>>> Huh? Why bounce? Postgrey only ever should deliver a 4xx reply code.
>>> Do you mean greylisted for too long?
>>>
>> Yes, greylisted for too long.
>>>
>>>> Would it be reasonable to nuke entries in the db that were off by
>>>> ridiculous amounts to catch this sort of error?
>>>>
>>> This would imply that you tell Postgrey when your clock is right
>>> because otherwise this would also trigger when your clock is totally
>>> wrong and start to expunge correct entries.
>>>
>> I'm getting early-retry log entries for 1000000 seconds.  Would
>> comparing this to the minimum timeout have other implications?
>
> You may try the following patch against Postgrey 1.33 :
>
>  <at>  <at>  -365,7 +365,7  <at>  <at> 
>           # whitelist if count is enough
>           if(defined $cawl_count and $cawl_count >=
(Continue reading)


Gmane