Milter-greylist

Uriel Wittenberg <tomrsn@...> wrote:

> Excuse me, but ARE ALL BLACKLISTS UNRELIABLE? That's what you're suggesting.
> I never talked about DNSRBL's, and I have no idea why you keep harping on
> them.

Because in the scenario you described, your blacklist is supposed to be
updated within one hour. That's why I assumed it was a DNSRBL-style
blacklist, or at least something updated automatically.

Of course if you have the manpower to maintain a local blacklist where
addition are manually checked in less than one hour, my point doesn't
stand anymore. 

What kind of blacklist do you plan to use? 

> If blacklists in general are unreliable, then fix your website, since it
> implies that it's appropriate to use them:

The situation is much different. When using a blacklist at the MTA
level, you can reject the incoming mail during the SMTP connexion. If
the blacklist is wrong (which will happen if it's managed
automatically), then the sender will receive a Delivery Status
Notification (DSN) telling that the mail was rejected. 

An unreliable blacklist cause mail rejection, but no mail disapear
without notification. The mail system is not made unreliable.

The solution you suggest is performed after the mail server accepted the
message. You want to delete a message from a mailbox because the sender
is in a blacklist. But if the blacklist is wrong, you delete a valid
message without a notification.   

Here an unreliable blacklist will cause mail to be silently discarded,
which is something most people will find not acceptable.

I suppose such a tool could generate reports of destroyed e-mails, but
if the user has to parse the report to find 1 fake positive for 100
entries, that won't work: most users will quickly stop checking the
report.

-- 
Emmanuel Dreyfus
Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@...