Re: [Sqlgrey-users] Comments and features requests

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

Le Lundi 10 Janvier 2005 17:19, Lionel Bouton a =E9crit :
>
> Negative caches should not be this high if the return code is 45x when
> validating senders. I can understand high TTL for 55x, but remember tha=
t
> greylisting only simulates a temporary unavailability of the MX, if the
> mail is delayed for several hours when a server is unavailable for a
> couple of minutes there is a defect in the configuration IMHO.

I fully agree with this.

> The problem is more with sender verification configurability than with
> greylisting in my opinion.

Yes, but we also have to live with things "as they are" rather than "as t=
hey=20
should be", until of course these things are fixed ;-)

Many Linux distributions come with Postfix packages and many users aren't=
=20
going to install a possibly updated Postfix until the updated package is =
in=20
their favourite distro. Not everybody is of the patch-and-compile-myself=20
sort ;-)

OTOH, when one adds a separate greylisting daemon to his existing Postifx=
=20
setup, he'd like it to integrate as well as possible with the verificatio=
n=20
daemon, not "as it should be", but "as it is" ;-)

Furthermore, the problem is not how our greylisting system may affect *ou=
r*=20
own verification daemon, but how it will affect remote server's verificat=
ion=20
daemons when they try to verify an address from our site. And we have no=20
control upon how these daemons, if any, work. We don't know how the remot=
e=20
sites are configured. So the best thing we can do it to keep as much as=20
possible our greylisting system out of the way of these remote verificati=
on=20
daemons.

> Could Postfix's verify daemon be updated to have a separate (lower)
> negative cache ttl for 45x replies ? Seems the right thing to do as the
> informations stored in cache have very different meanings in the 45x an=
d
> 55x cases.

True, and that would be great. Meanwhile, we have to work around this=20
feature ;-)

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