From: Keean Schupke (keeanfry-it.com)
Date: Wed Nov 21 2007 - 14:13:19 CST

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Okay, that gives me a two step development program for this feature.

1) implement verify using gateway/user/pass hashes to cache failures.

2) extend the verify service to allow using a database backend. As we
know the approximate password update frequency (say monthly new
passwords) setting a cache time of 2-3 months would stop the database
growing in size indefinitely.

I think even just (1) gives useful functionality, so I will submit a
patch for review at this stage, before going on to (2).

Regards,
Keean Schupke, Fry-IT Ltd.

> Back to the verify(8) approach, it is important to not store sucess
> results in the verify(8) cache in this case. Store only failures.
> The verify(8) service will not replace a success state with a failure
> state before the lifetime of the success entry expires.
>
> The "address" argument to the verify service is an arbitrary
> null-terminated string. A base64 encoding of the SHA1 hash of
> "gateway\0user\0pass\0" would make a reasonable key and will not collide
> with addresses (no "" sign).
>
> Enabling a persistent store for this "verify" service is probably a good
> idea, so that reboots don't result in re-use of stale passwords.
>
> The down-side is some risk of corrupted ".db" files after a bad crash.
> These would require manual intervention.
>
> --
> Viktor.
>
> Disclaimer: off-list followups get on-list replies or get ignored.
> Please do not ignore the "Reply-To" header.
>
> To unsubscribe from the postfix-users list, visit
> http://www.postfix.org/lists.html or click the link below:
> <mailto:majordomopostfix.org?body=unsubscribe%20postfix-users>
>
> If my response solves your problem, the best way to thank me is to not
> send an "it worked, thanks" follow-up. If you must respond, please put
> "It worked, thanks" in the "Subject" so I can delete these quickly.
>

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]