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 [EMAIL PROTECTED] OOO http://www.madism.org
pgp9lHG4Z1Eyr.pgp
Description: PGP signature
