[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Greylisting for @debian.org email, please

Le Ven 17 Juin 2005 01:42, Wouter Verhelst a écrit :
> On Thu, Jun 16, 2005 at 03:09:47PM +0200, Pierre Habouzit wrote:
> > Le Jeu 16 Juin 2005 14:33, Santiago Vila a écrit :
> > > Now that we have released sarge, I would like to ask debian-admin
> > > and the Project Leader to consider seriously doing something to
> > > reduce the level of spam we have to receive, store, and filter in
> > > our @debian.org addresses.
> > >
> > > For example, we could use greylisting. Or we could reject
> > > messages that are known to come directly from trojanized windows
> > > machines acting as open proxies. Or even better, we could do both
> > > things.
> >
> > I fully disagree, greylisting is really painful,
> What's painful about it?

  the delay it creates. For a ML it's often OK, and it may be benefic 
(since it will delay flames too, and also diminish their length and 
annoyance) but for our @debian.org addresses ... that sucks, I often 
rely on the fact that delivery is immediate on those.

> It stops a lot of viruses and spam, with no false positives. What's
> the problem?

  it can have false positive or at least be inefficient. e.g. : the 
alumni site of my school uses SRS rewriting since it does only mail 
forwarding (no real mailboxes) and that without that it would send to 
many bad mail wrt SPF.

  SRS changes the MAIL FROM for one user every 3 or 4 hours. so every 3 
or 4 hours he comes stuck in greylisting server again and again. For 
such domains, greylisting sucks.

  though, I think greylisting is a quite good last barrier defense. I 
have recently written a policy [1] daemon for postfix (that has been 
accepted recently) that works like that : it looks RBL's, and checks 
SPF against mails. if any of those tests is suspicious, it answer 
'DUNNO' (and also let the mail go through the next postfix filtering 
rule). if NONE of them was suspicious (no rbl hit, and clean SPF) then 
it answer 'OK' to postfix, and also validate the mail.

  My following filtering rule (and in fact last one) is a greylisting 
daemon. with this scheme, I don't greylist by default, and with the 
right RBLs and SPF settings, I have quite good results, combining a not 
to large growth of the greylist DB, and not too many delays, and no 
false positives.

  This is not an ad for my tool (it's called whitelister and just 
entered debian tonight ;p) but I think in such a scheme, greylisting is 
ok and also really effective. and after that, you can have your AVcheck 
and AS check, and you have a very robust, light, scalable queue.

  Don't forget also that MX of the planet that have a very big traffic 
list domains that are greylisted, and force mails delivered to such 
domains to wait 1h (if not more) in queue after any retry, in order to 
be really sure to retry *after* the greylist timeout. I'm sure of it, 
because I know admins of such MX's, and greylisting pulls the charge on 
their shoulder ...

  All the reasons I detail here are the one that make me think full, 
default, complete greylisting on a domain is *not* a good idea.

 [1] http://www.postfix.org/SMTPD_POLICY_README.html
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

Attachment: pgp5EkElIydSV.pgp
Description: PGP signature

Reply to: