Re: [Sqlgrey-users] Comments and features requests

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

Postfix-users is CCed as I propose a change in the verify daemon later 
on in this mail, please skip to 2/ if you don't care about SQLgrey 
specific questions but only for greylisting + address verification 
behaviour.

# 1/ greylister return value

Michel Bouissou wrote the following on 01/10/2005 03:46 PM :

>
>Let me explain my view : The huge majority of trash that my mailserver 
>currently receives comes from zombie virus-sending Windows machines, or 
>spambots that don't have a normal retry pattern. The whole point in 
>greylisting is precisely to eliminate them, because they will *NOT* retry. So 
>rejecting their mail attempt with any code, either 450 or 550 results in the 
>same effect : They don't come back (at least using the same from/to/IP).
>
>I personally prefer to put first in my Postfix series of tests all the tests 
>that can be "local and quick", and only for messages that passes these, 
>perform tests that may be "longer or network or resources consuming", such as 
>sender address verification.
>  
>

Makes sense to me.

>That's why I'd like that a "Greylisted" event could immediately reject the 
>mail on first attempt (I wouldn't mind a "defer_if_permit" on an "early 
>reconnection" BTW, because it would allow me to check sender now that it is 
>probable that the same mail will come back again).
>
>  
>

This last one is a little more complex but I agree it can be helpful.

>Furthermore, if Greylisting caused an immediate reject, it would permit me not 
>to uselessly bother remote servers with address verification for addresses 
>that are dummy, and messages that won't come back.
>
>Furthermore, I prefer not to "pollute" my address verification DB where it can 
>be avoided, to prevent it from growing too much. SQLgrey uses a nice 
>PostgreSQL database on my system, it's size is no problem and it can be 
>easily maintained (vacuum analyze etc...), which is not the case of the 
>Postfix address verification daemon DB, which uses a simpler BerkeleyDB.
>
>Last but not least, I don't mind rejecting first with a 450 a spam that will 
>actually come back and that I will reject with a 554 on 2nd attempt (origin 
>blacklisted, non-existent sender...). By rejecting the message twice, I then 
>put a double load on the spammer's server, and I don't hate the idea of 
>giving them more work to get rejected twice ;-)
>  
>

Ok you convinced me. Added to my TODO list for 1.4.x.

# 2/ address verification

>
>  
>
>>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.
>>    
>>
>
>No, because server B will probably *NOT* verify again so quickly. Server B 
>will probably have a "negative cache TTL" telling it not to retry a failed 
>verification before a given delay (I personally use 3 hours delay) to avoid 
>repeteadly bothering remote servers with possible repeated requests for the 
>same non-existent address.
>  
>

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 that 
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.

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

sender verification is a risky thing to do btw, you should only call 
verify on known-to-be forged domain where you are pretty sure you can 
verify the Return-Path of each and every valid mail.

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 and 
55x cases.

>If this scheme, what happens is as follows:
>- Server A wants to send mail to server B
>- Server B tries to verify sender address on server A, but gets greylisted, 
>and its verification receives a "450".
>- Server B keeps this 450 in cache for its "negative TTL time" (let's say 3 
>hours).
>- Server A will retry several times to send its mail to server B, and will be 
>refused with 450 immediately as long as the sender address verification 
>negative TTL isn't expired.
>- After at least 3 hours (but some sending servers may have retry delays that 
>grows exponentially, such as qmail, so it could well be 8 or 10 hours),
>

in qmail's case, it shouldn't grow much since the 2nd verification 
attempt will most probably succeed.

Best regards,

Lionel.