Re: [Sqlgrey-users] Comments and features requests

[Lionel B. <lio...@bo...>]

Michel Bouissou wrote the following on 01/10/2005 09:26 AM :

>Hi there,
>
>I've started using SQLgrey a couple of days ago, and I'm rather happy with it.
>
>I have however a couple of comments and feature requests :
>
>1/ In the provided "clients_fqdn_whitelist", the following line:
>scd.yahoo.com
>is wrong, does not work, and should be replaced with
>*.scd.yahoo.com
>  
>

Thanks. Commited in CVS.

>2/ The latest version of Postgrey allows specifying the result (both code and 
>text) that Postgrey should give when a connection is greylisted. It would be 
>nice if SQLgrey could do the same.
>Currently SQLgrey returns "defer_if_permit" and this cannot be modified 
>(except by fiddling in the code).
>However, some may prefer to reject immediately with a 450 temporary failure, 
>rather than carry on with further potentially expensive Postfix tests (such 
>as checking external DNSBLs or verifying sender existence), where the 
>connection will in the end be rejected anyway...
>
>  
>

I suppose you use a 550 rejection at least with DNSBLs. In this case 
you'll lose time by forcing a temporary failure instead of rejecting on 
the first connection.
With sender verification it can be more complex, I'm not sure of the 
cases where 450 and 550 are used. If the sender verification use 550, 
you end up in the same case than the one described above : you lose time 
and performance if a 450 is used then it will save one 450 but not the 
subsequent ones.

So in the end, I'm not sure you will gain much from it or if in fact you 
won't lose something...
But it's a simple thing to add, so if you find a case where it clearly 
is beneficial, I'll code it.

>3/ It would be nice to have a whitelist of senders (using regexps) for whom 
>greylisting should never be done. This list should by default include the 
>addresses that some MTA use to perform "sender address verification", as we 
>should avoid greylisting those verifications as much as possible, the 
>combination of greylisting and sender address verification introducing 
>problems and rather long delays. These verification origin addresses are, 
>among the most common:
><> (null sender)
>MAILER-DAEMON@*
>postmaster@*
>  
>

I don't think greylisting and sender address verification clash with 
each other. The common problem is the following :
Server A uses greylisting, Server B uses sender address verification.
- Server A formard a mail to Server B,
- Server B wants to check that the sender exists and Server A is the MX 
for the corresponding domain, Server A is not in the auto-whitelists of 
Server B
- Server A don't trust Server B yet, so Server B verification fails and 
(temporarily) refuses the mail,
- Server B will retry (around 20 minutes later with default Postfix 
configuration under light load), then Server A will be able to verify 
(and will be for 60 days and more with default SQLgrey config), the mail 
gets through.

In the end what happens is that you more or less apply greylisting on 
the "outgoing" mails where the destination uses sender verification as 
well as the "incoming" mails. With auto-whitelisting, you shouldn't 
notice much of a difference.

The problem with adding hard whitelists for origin addressses is that 
you will have many SPAMs coming through (postmaster, MAILER-DAEMON and 
<> are used rather often).

In conclusion, I think auto-whitelisting should take care of the problem 
efficiently and adding sender whitelists will bring more harm than good.
If you find odd installations where sender verification is poorly 
implemented (for example using a 550 insted of a 450) at the point of 
breaking greylisting, I believe you should add them to the whitelists 
server by server (these would be broken SMTP configurations, so it 
should be the right place), warn their postmasters and post the cases on 
this mailing-list.

>
>Thanks for this excellent piece of software.
>
>  
>

You are welcomed. Thanks for the comments.

Lionel.