Re: Re: Greylisting for @debian.org email, please
-- La información incluida en el presente correo electronico y cualquier archivo adjunto al mismo están dirigidos exclusivamente a su destinatario.Pueden contener información confidencial o privilegiada. Si recibe esta comunicación sin ser el destinatario le informamos que está prohibida cualquier utilización de la misma y le rogamos que nos lo notifique inmediatamente y la devuelva a su origen, asegurandose de que el mensaje original, cualquier copia relacionada con el mismo y sus archivos adjuntos sean eliminados de su sistema.
Re: greylisting on debian.org?
On Wednesday 19 July 2006 00:13, Stephen Gran wrote: This one time, at band camp, Thomas Bushnell BSG said: Loïc Minier [EMAIL PROTECTED] writes: Can we get greylisting now? We have it, duh. Have you not been paying attention? We don't have it yet. Have you not been paying attention? The only delay we have now is due to spam clogged queues and load. Stop it right now. alioth has greylisting. This whole discussion has, though, never been about alioth. I guess you *both* know that already since you've read the discussion. So don't play silly just for the sake of it, please. -- vbi -- All computers wait at the same speed. pgpKUsVFmFvRa.pgp Description: PGP signature
Re: greylisting on debian.org?
Thomas Bushnell BSG [EMAIL PROTECTED] schrieb/wrote: So the meaning of 4xx is temporary local problem. RFC 2822 says 4yz Transient Negative Completion reply (p. 42). The standard also encourages the re-use of existing error codes for slightly different situations (p. 43). Claus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
Le mardi 18 juillet 2006 à 12:22 -0700, Thomas Bushnell BSG a écrit : Josselin Mouette [EMAIL PROTECTED] writes: I have refused greylisting for a long time for that exact reason. However the setup Pierre Habouzit describes does not delay most of legitimate mail. Frankly, the remaining delays are sporadic and one can live with them. What bothers me is that we hear it never delays legitimate mail! and Who said that? then well, ok, it delays some. If the anti-spam advocates consistently said our measures impose such-and-such a cost, but we think it's worth it, I would be delighted. This is exactly what I'm saying. There is a cost, but it is small compared to the benefit. But what I seem to hear is not that. It's hey, this imposes no costs! Who said that? or spam is evil, so any cost is worth bearing to fight it! Who said that? And by the way, have you talked about the cost of all this spam going through? I'm currently still receiving between 100 and 200 spams per day on my @debian.org, and this has a *huge* cost. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: greylisting on debian.org?
On Tue, Jul 18, 2006 at 12:24:21PM -0700, Thomas Bushnell BSG wrote: So the meaning of 4xx is temporary local problem. Sending that when you don't have a temporary local problem is a violation, right there. Must the standard repeat after every sentence, oh, and don't lie. If it helps, think of it being a temporary local problem that we don't trust the sender yet. I think you are being unreasonably difficult in this discussion. Be liberal in what you accept... ? Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
Le mar 18 juillet 2006 00:08, Magnus Holmgren a écrit : On Monday 17 July 2006 23:41, Pierre Habouzit took the opportunity to write: Le lun 17 juillet 2006 19:53, Adrian von Bidder a écrit : So the question is, imho, not if we should potentially lock out users of big mail pools - those are in the default whitelists anyway by now. The question is: can we temporarily (until they can be whitelisted) lock out users of standards?-who-needs-standards? systems that don't implement sensible queueing. Many of these sites are small - but there are also a few bigger names: Yahoo groups, Amazon, Roche, Motorola. (According to postgrey's default whitelist. Some of these are from 2004 or earlier, and AFAIK nobody tries to verify if these systems are still stupid in that way.) OTOH those systems are not listed on RBL's (or it does not last) and you won't greylist them. Which RBL's do you have in mind? I mean, some RBL's, like XBL/SBL, are high-quality enough that you can outright reject. Others, like SpamCop, are likely to include some of the bigger names from time to time. DUL lists might be good candidates. I personnaly use DUL, rfc-ignorant and XBL/SBL. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpgIScRRQMZr.pgp Description: PGP signature
Re: greylisting on debian.org?
On Mon, Jul 17, 2006 at 11:48:21PM +0200, Pierre Habouzit wrote: Le lun 17 juillet 2006 22:29, Lionel Elie Mamane a écrit : Here is one: I am strongly opposed to greylisting (on mail sent to me or that I send), for the reason that it delays legitimate mail. which shows that you didn't read the discussion Wrong. Disagreeing with you is not the same as not reading your arguments. Sorry that you were not convincing. that was about enabling greylisting on *certain* *specificaly* *suspicious* hosts. I know. a suspicious host is: * either listed on some RBL's (rbl listing dynamic blocks are a good start usually) * either having no reverse DNS set * either having curious EHLO lines (that one may catch too much good mail sadly, so it's to handle with care). * ... This will still include legitimate mail. I apply greylisting on the two first criteriums on a quite used mail server (around 300.k mails per week, which is not very big, but should be representative enough). there is less than 50 mails a week over those that *may* be legitimate mails that are actually slowed down. Bingo: Legitimate mail slowed down. You think the price is worth it, which is a valid opinion. I happen not to think so. Usually when mail I send gets greylisted, it is because the software thinks I am suspicious. so *please* do me a favour, read the thread you are answering to, I did. because you really really answer miles away from the debate. No, I'm not. I'm expressing an opinion after reading all of the debate, from the points of it I remember. and if you never actually realized, there *IS* such a slowdown on debian mail lists, it's called crossassassin, it kills master on a regular basis, and is *REALLY* less effective than greylisting. I don't remember the master cannot cope under mail load, we need desperate measures point being brought up before. I may have missed it. Best Regards, -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
On Tue, Jul 18, 2006 at 12:47:49AM +0200, Josselin Mouette wrote: Le lundi 17 juillet 2006 à 22:29 +0200, Lionel Elie Mamane a écrit : On Sun, Jul 16, 2006 at 08:36:31AM +0200, Christian Perrier wrote: Quoting Wolfgang Lonien ([EMAIL PROTECTED]): Do we use greylisting on the @debian.org domain and especially on @lists.debian.org? So, up to now, we've found Thomas Bushnell who seems really hardly voting against greylisting on Debian hosts, (...). So far and unless I forget someone, I haven't seen much other people being strongly opposed to greylisting on Debian hosts, Here is one: I am strongly opposed to greylisting (on mail sent to me or that I send), for the reason that it delays legitimate mail. I have refused greylisting for a long time for that exact reason. However the setup Pierre Habouzit describes does not delay most of legitimate mail. That is the crux of the disagreement. You guys think that as long as most of the legitimate mail is not delayed, the price is worth it. I don't think so. Frankly, the remaining delays are sporadic and one can live with them. Knowing that most legitimate mail doesn't get delayed doesn't make me feel better when mail I sit waiting for gets delayed. Obviously, for most mail I don't care as I don't sit waiting for it, I batch-treat it a fez times per day or per week. So a half-hour delay on it, I don't even see it. For *most* mail. I'm applying greylisting if one of these conditions is met: * the incoming IP is listed in a DUL; Bingo! You hit a hot button of mine. * Exim sender/callout fails with a fatal error. Fatal means not temporary? -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
* Stephen Gran [EMAIL PROTECTED] [2006-07-17 18:43]: It's not uncommon for big sites to have pools of high throughput machines that don't have qrunners, and larger pools of machines that do. The first group gets a message, and tries to deliver immediately, and any temporary failure gets the messages shunted to the secondary pool. Once in the secondary pool, it can be bounced from machine to machine to load balance queue size and so on. That being said, the original query about this was a strawman argument designed specifically to find a problem, and I would say fairly confidently we don't need to worry about this. I have analyzed the logs on mail servers I have access to, and I cannot find any site which passes a message between more than a half dozen or at most a dozen IP addresses before delivery. This is two or three orders of magnitude less than the kind of thing Thomas and others are concerned about. By the time sites big enough to use pools that big exist (which I actually doubt - scalability might just be too hard to manage to be worth it), greylisting will be another dead tool in the arms race with spammers. So far, all the arguments against the idea have just been assertions and strawmen. Unless someone can present a serious argument, can we consider this thread done? I've been using greylisting with postgrey and whitelists for some time now (more than a year to be precise) and I still do get mail from gmail, yahoo and msn accounts. And if one is so concerned about them one could contact their postmasters asking for a list of IPs for whitelisting. After all we are talking about developers @debian.org email addresses not abouts lists.debian.org. yours Martin -- [EMAIL PROTECTED] Debian GNU/Linux - The Universal Operating System * Myon wirft noch ein paar 'f' zum Verteilein in den Channel -!- florolf is now known as fflorolff
Re: greylisting on debian.org?
Le mardi 18 juillet 2006 à 09:47 +0200, Lionel Elie Mamane a écrit : That is the crux of the disagreement. You guys think that as long as most of the legitimate mail is not delayed, the price is worth it. I don't think so. If too much spam gets through, *all* legitimate mail gets delayed. It gets delayed by the additional filters it has to get through thereafter, and it gets delayed by having to dig it out of a mailbox full of spam. * Exim sender/callout fails with a fatal error. Fatal means not temporary? It means either the domain doesn't exist, or the server explicitly replied the user doesn't exist. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: greylisting on debian.org?
Le mar 18 juillet 2006 09:34, Lionel Elie Mamane a écrit : This will still include legitimate mail. something like 50 over 300k is less than 0.016%. which is also really less than the usual number of false positives of your bayesian mail filter. see end of mail. and if you never actually realized, there *IS* such a slowdown on debian mail lists, it's called crossassassin, it kills master on a regular basis, and is *REALLY* less effective than greylisting. I don't remember the master cannot cope under mail load, we need desperate measures point being brought up before. I may have missed it. these days master has a high load on a regular basis: load average: 239.68, 299.68, 326.84 from IRC a couple of days ago, What I experience as a debian developer is that: * 80% of the overall spam that eventually comes into my inbox went through my debian.org account, that renders the read of such a mailbox really hard, and I'm pretty sure that I miss more than 0.016% of legitimate mail in my readings. * my @debian.org address has considerable slowdowns due to our MXs beeing overloaded from time to time. 80% of the time, it's because of crossassassin becoming mad, or some spam attack. Just take some factual numbers: I receive sth like 300 mails a day (top, I think the mean value is more around 150). that makes 109.500 mails a year. I know for a fact that my bayesian filter makes sth like 4 to 5 errors per year. And yes I know how to train one. So my bayesian mail filter has at least a 0.05% false positive rate, and I'm really convinced in fact it's more like 0.1% (maybe even more). SA is used extensively on debian hosts, I'm also quite sure it also has worse rates than a 0.1%. So you are claiming that greylisting is a really bad method ? come on ! currently, I receive so many spams from debian, that I just CANT sort them. it's sth like 90spams a *day* sometimes. How do you find the time to look at the good mails in there ? I can't. So by not delaying 0.016% of the legitimate mails, you make a lot of people *LOOSE* for real way more than that. please, your point is only made of impressions, now you have numbers. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpG5ojNkr7dX.pgp Description: PGP signature
Re: greylisting on debian.org?
* Lionel Elie Mamane [EMAIL PROTECTED] [2006-07-17 22:32]: On Sun, Jul 16, 2006 at 08:36:31AM +0200, Christian Perrier wrote: So far and unless I forget someone, I haven't seen much other people being strongly opposed to greylisting on Debian hosts, Here is one: I am strongly opposed to greylisting (on mail sent to me or that I send), for the reason that it delays legitimate mail. Greylisting is among the minor causes for mail delays in my experience. Most delays when it comes to debian.org mails are caused by the load on the servers from what I see. With other companies mails the main delays are caused by their ISPs smarthosts as they always have queue times of up to 30 minutes while greylisting only delays once. yours Martin -- [EMAIL PROTECTED] Debian GNU/Linux - The Universal Operating System yath lol, mein feuermelder ist dausicher yath im batteriefach unter der batterie steht yath WARNUNG: BATTERIE ENTFERNT -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
(afaik, it's very obvious that I'm subscribed to -devel and, unless I'm wrong, I never requeted for being CC'ed in private) Lionel Elie Mamane a écrit : Wrong. Disagreeing with you is not the same as not reading your arguments. Sorry that you were not convincing. I'm afraid you failed to make it clear. Glad that you cleared this out. This will still include legitimate mail. Sure...just like legitimate mail is very likely to be slowed...or lost on DD machines because most of us *have* to use anti-spam measures on our own machines (most often without the needed complete knowledge, /me being the first). Or, even without this, slowing down because our @debian.org addresses are overspammed and we may be likely to jst miss one important mail. Or (already happened to me) losing information because a legitimate mail, lost in a bunch of spam crap, was infortunate enough to just appear like spam...and be discarded or not read. There is a price to pay and slowing down (not losing...slowing down) a very small portion of legitimate mail is a small part of it. Bingo: Legitimate mail slowed down. You think the price is worth it, which is a valid opinion. I happen not to think so. The question becomes: aren't you in a small minority? We certainly all know that it's perfectly impossible to reach a 100% consensus on such a topic. But what would be your point if a strong majority of DD agrees with the use of greylisting (as described by Pierre) I don't remember the master cannot cope under mail load, we need desperate measures point being brought up before. I may have missed it. Well, given the way I received debian lists mail last day, there has probably been something somewhere..:) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
On Tue, Jul 18, 2006 at 10:22:41AM +0200, Christian Perrier wrote: Lionel Elie Mamane a écrit : Bingo: Legitimate mail slowed down. You think the price is worth it, which is a valid opinion. I happen not to think so. The question becomes: aren't you in a small minority? That may very well be. A message was sent saying only Thomas disagrees, I just wanted to say that if we go the voice-counting way, I have one, too. We certainly all know that it's perfectly impossible to reach a 100% consensus on such a topic. But what would be your point if a strong majority of DD agrees with the use of greylisting (as described by Pierre) Then it would be OK to implement it. The very best would be to do the same I do on my mail server, where users can individually choose greylisting or not for personal mail to them, by a settings file in their home directory. But if a strong majority wants greylisting, it is OK to just do it on all mail (except postmaster@, maybe). I don't remember the master cannot cope under mail load, we need desperate measures point being brought up before. I may have missed it. Well, given the way I received debian lists mail last day, there has probably been something somewhere..:) I meant in this thread. I do not read all threads, nor all mailing lists. -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
Then it would be OK to implement it. The very best would be to do the same I do on my mail server, where users can individually choose greylisting or not for personal mail to them, by a settings file in their home directory. But if a strong majority wants greylisting, it is OK to just do it on all mail (except postmaster@, maybe). Well, if per-user settings are possible, then it would be a *very* valuable feature to have. That would certainly allow avoiding concerns like yours (or minimize them as much as possible). Dunno if that is possible with Pierre Habouzit greylisting system...Pierre? --
Re: greylisting on debian.org?
Le mar 18 juillet 2006 11:51, Christian Perrier a écrit : Then it would be OK to implement it. The very best would be to do the same I do on my mail server, where users can individually choose greylisting or not for personal mail to them, by a settings file in their home directory. But if a strong majority wants greylisting, it is OK to just do it on all mail (except postmaster@, maybe). Well, if per-user settings are possible, then it would be a *very* valuable feature to have. That would certainly allow avoiding concerns like yours (or minimize them as much as possible). Dunno if that is possible with Pierre Habouzit greylisting system...Pierre? it is, and it's not. the historical way to perform greylist is to do it on a per user basis, answering your 200/400 answers to each RCPT TO command. so basically, the greylister could know he should not greylist some recipients. *but*: (1) many broken MTA do not understand that you give a 400 to some RCPT's and not others, and have erratic behaviours that may result in: - many resents of the same mail for the people that do not use greylisting - delay even for the one that do not user greylisting (2) modern greylisting usually do it at DATA now (I mean at the DATA command, where the smtpd usually anser sth like: 321 please end your command with CRLF.CRLF or sth similar), because it makes checks beeing done only once. but basically, what I've suggested alread some time ago, is not to refine the greylisting method, here you can use whatever greylister you want, with whatever customization you need/want. I just suggested to do conditionnal greylisting, the rest is up to the greylister you use, really. everything is possible. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpgGNtDYLpPw.pgp Description: PGP signature
Re: greylisting on debian.org?
On Tue, Jul 18, 2006 at 09:47:13AM +0200, Lionel Elie Mamane wrote: On Tue, Jul 18, 2006 at 12:47:49AM +0200, Josselin Mouette wrote: * Exim sender/callout fails with a fatal error. Fatal means not temporary? Yes. It means exim did this to one of the MX hosts listed for the domain: EHLO hostname MAIL FROM: RCPT TO:address to be tested QUIT and received a 5xx error in reply to the RCPT TO: line (not 4xx). -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Greylisting: discussion should stop here, for now (Re: greylisting on debian.org?)
Apart from the fact that the opinions seem to be set (and haven't really changed since the last time the discussion came up IIRC, so we really can stop arguing - nothing new for quite some time...): am I correct in my observation that nobody who has participated in this discussion up to now is involved in Debian email administration? I had a quick look at http://www.debian.org/intro/organization, but I didn't really check all names. So even if the discussion leans in favor of greylisting on RBL (SBL+XBL? Or also DUL, spamcop, ...?): is there any chance of this getting anywhere? cheers -- vbi -- Computer programmers don't byte, they nibble a bit. pgp9ga3YUdUgE.pgp Description: PGP signature
Re: Greylisting: discussion should stop here, for now (Re: greylisting on debian.org?)
Le mar 18 juillet 2006 13:20, Adrian von Bidder a écrit : Apart from the fact that the opinions seem to be set (and haven't really changed since the last time the discussion came up IIRC, so we really can stop arguing - nothing new for quite some time...): am I correct in my observation that nobody who has participated in this discussion up to now is involved in Debian email administration? I had a quick look at http://www.debian.org/intro/organization, but I didn't really check all names. For the record (it was already said in the thread IIRC), the setup we are discussing is in production on alioth since sth like 4 or 5 monthes now (maybe a bit less) on my idea, and thanks to Raphael Hertzog for actually using his alioth admin hat to put it together. so as a matter of a fact, yes, I've already worked in a way so that such solutions can be implemented where there is reachable and listening people to work with. So even if the discussion leans in favor of greylisting on RBL (SBL+XBL? Or also DUL, spamcop, ...?): is there any chance of this getting anywhere? I'm not sure the DSA team is a very open one, if I'm mistaken, then take that mail as an official application request, either for a temporary delegation (or for a more permanent thing) to work on implementing more efficient mail delivery on debian MX'es. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpzougW7nRbL.pgp Description: PGP signature
Re: greylisting on debian.org?
Josselin Mouette [EMAIL PROTECTED] writes: I have refused greylisting for a long time for that exact reason. However the setup Pierre Habouzit describes does not delay most of legitimate mail. Frankly, the remaining delays are sporadic and one can live with them. What bothers me is that we hear it never delays legitimate mail! and then well, ok, it delays some. If the anti-spam advocates consistently said our measures impose such-and-such a cost, but we think it's worth it, I would be delighted. But what I seem to hear is not that. It's hey, this imposes no costs! or spam is evil, so any cost is worth bearing to fight it! Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
Stephen Gran [EMAIL PROTECTED] writes: This one time, at band camp, Thomas Bushnell BSG said: And finally, if we don't care about standards conformance, I have said that a good second-best is to document exactly what our requirements are, rather than burying them in apparent secrecy. What standards, exactly? Can you be specific? I have seen you assert this several times, but I see nothing in the RFCs preventing a site from saying it has a temporary local problem when it doesn't. You've been asked this before in response to your assertion, and haven't answered. So the meaning of 4xx is temporary local problem. Sending that when you don't have a temporary local problem is a violation, right there. Must the standard repeat after every sentence, oh, and don't lie. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
Adam Borowski [EMAIL PROTECTED] writes: Even worse, there's nothing preventing a site from saying it has a temporary local problem when it _does_. Thus, if your mail server can't handle retrying, it will drop mail every time something is not in perfect working order. And hardware or network failures are something to be expected. Any legitimate server must support retrying. For any reason. Yes, and this is not the point. The point is that the standard does *not* say that the retry must come from the same place, or even anything like the same place. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
[EMAIL PROTECTED] (Marco d'Itri) writes: On Jul 17, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: Still, if you think it's just nitpicking, then why not ask the IETF to amend the standard to clearly permit this practice? Because there is no reason to do this, this is not a standard issue but plain operations. Really? So you think the IETF would happily issue a statement agreeing? Of course, the facts are that the IETF regards graylisting as a violation of the email protocols and not to be implemented. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Greylisting: discussion should stop here, for now (Re: greylisting on debian.org?)
Pierre Habouzit [EMAIL PROTECTED] writes: For the record (it was already said in the thread IIRC), the setup we are discussing is in production on alioth since sth like 4 or 5 monthes now (maybe a bit less) on my idea, and thanks to Raphael Hertzog for actually using his alioth admin hat to put it together. Can you document on the relevant web page exactly how the graylisting works and what specific things get blocked and when? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
On Tue, Jul 18, 2006, Thomas Bushnell BSG wrote: If the anti-spam advocates consistently said our measures impose such-and-such a cost, but we think it's worth it, I would be delighted. the measures impose a cost, but we think it's worth it Can we get greylisting now? -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
On Jul 18, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: Because there is no reason to do this, this is not a standard issue but plain operations. Really? So you think the IETF would happily issue a statement agreeing? Yes. Of course, the facts are that the IETF regards graylisting as a violation of the email protocols and not to be implemented. When (and how?) did the IETF express such an opinion? -- ciao, Marco signature.asc Description: Digital signature
Re: greylisting on debian.org?
On Jul 18, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: Yes, and this is not the point. The point is that the standard does *not* say that the retry must come from the same place, or even anything like the same place. The point is that in the real world nobody cares that this is not specified in a standard. -- ciao, Marco signature.asc Description: Digital signature
Re: greylisting on debian.org?
Loïc Minier [EMAIL PROTECTED] writes: On Tue, Jul 18, 2006, Thomas Bushnell BSG wrote: If the anti-spam advocates consistently said our measures impose such-and-such a cost, but we think it's worth it, I would be delighted. the measures impose a cost, but we think it's worth it Can you detail what the cost is for the specific procedures in use on Debian's servers? No, because you are apparently unaware it exists already. But yet, without knowing the cost, you are sure it's worth it. Bah. Can we get greylisting now? We have it, duh. Have you not been paying attention? Thomas
Re: Greylisting: discussion should stop here, for now (Re: greylisting on debian.org?)
Le mar 18 juillet 2006 21:26, Thomas Bushnell BSG a écrit : Pierre Habouzit [EMAIL PROTECTED] writes: For the record (it was already said in the thread IIRC), the setup we are discussing is in production on alioth since sth like 4 or 5 monthes now (maybe a bit less) on my idea, and thanks to Raphael Hertzog for actually using his alioth admin hat to put it together. Can you document on the relevant web page exactly how the graylisting works and what specific things get blocked and when? I've already gived numbers in the thread (even graphs), for a similar setup. I don't have access to alioth logs, but the setup is world readable, log on alioth and read it ;) Moreover, as there is quite few valid aliases, alioth greylist do not takes care of the recipient in account for the greylisting, but only the MAIL FROM + SENDER IP, which a good trade off for alioth, but may not be true for DD accounts. that's the sole deviation of what has been discussed here, and is not very relevant to the discussion anyway. Technically, I don't know what you want me to say more than what is explained on my blog and in that thread (or in alioth's world readable exim.conf). Moreover I don't see what value the 6 or 7 mails that you posted less than 1 hour ago, in the same quarter, answering to at least half of the most recents posts in the thread, have made the discussion make any progress. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp2b0E7CPZll.pgp Description: PGP signature
Re: greylisting on debian.org?
This one time, at band camp, Thomas Bushnell BSG said: Loïc Minier [EMAIL PROTECTED] writes: On Tue, Jul 18, 2006, Thomas Bushnell BSG wrote: If the anti-spam advocates consistently said our measures impose such-and-such a cost, but we think it's worth it, I would be delighted. the measures impose a cost, but we think it's worth it Can you detail what the cost is for the specific procedures in use on Debian's servers? No, because you are apparently unaware it exists already. But yet, without knowing the cost, you are sure it's worth it. Bah. The specific cost right now is that we have load averages on master in excess of 300. Fairly consistently. Greylisting promises to ease that load by quite a bit. It imposes a small cost: some legitimate mail that doesn't meet whatever criteria is decided on (rDNS, RBL, whatever) will be delayed. None will be rejected by this measure, unless the sending site itself can't be bothered with RFC compliance. That doesn't bother me that much. If it bothers you, use your non-Debian email address for all your package related work, and hardly any of your mail will pass through master. And I notice you still haven't been able to come up with anything resembling a link for your earlier assertions. Can we take it as read that they were, in fact, unfounded? Can we get greylisting now? We have it, duh. Have you not been paying attention? We don't have it yet. Have you not been paying attention? The only delay we have now is due to spam clogged queues and load. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: greylisting on debian.org?
This one time, at band camp, Thomas Bushnell BSG said: So the meaning of 4xx is temporary local problem. Sending that when you don't have a temporary local problem is a violation, right there. Must the standard repeat after every sentence, oh, and don't lie. Actually, that's just the error message most MTA's give out. The RFC has finer grained meanings for the range of 4xx messages. Would you be happier if greylisting gave back a 451 (error in processing)? This is factually true - processing began, but one of the preconditions failed. That is not a lie. You might want to go back and reread the RFCs about all of this. Most of what you are saying isn't actually in the RFCs, but is part of the mythology that has grown up around them. Try to find 'be liberal in what you accept ... ' in RFC 2821. Notice also that local site policy _always_ trumps the RFC, but with a note to the effect that you _should_ (not must) take care to not violate interoperability when implementing site policy. I would argue greylisting doesn't violate interoperability. But maybe you have another assertion. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: greylisting on debian.org?
On Sunday 16 July 2006 04:35, Thomas Bushnell BSG took the opportunity to write: Stephen Gran [EMAIL PROTECTED] writes: I suggest that when we find a domain that sends mail from 120 /27's (roughly a /20), we worry about it then. An excellent strategy. I think so. How many systems (aside from the big ones like MSN, Gmail, ..., which are generally known) do you estimate would be affected? At most sites outgoing messages stay with the same host until delivered, except after the initial delivery attempt a temporarily failed message may be passed to a secondary MTA. Do you have some mechanism in place to detect such a case when or if it happens? Deal with it when people complain. Also, this kind of information can be shared so that not every mail admin has to find it out himself by users complaining. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpYujtBdEr7I.pgp Description: PGP signature
Re: greylisting on debian.org?
This one time, at band camp, Magnus Holmgren said: On Sunday 16 July 2006 04:35, Thomas Bushnell BSG took the opportunity to write: Stephen Gran [EMAIL PROTECTED] writes: I suggest that when we find a domain that sends mail from 120 /27's (roughly a /20), we worry about it then. An excellent strategy. I think so. How many systems (aside from the big ones like MSN, Gmail, ..., which are generally known) do you estimate would be affected? At most sites outgoing messages stay with the same host until delivered, except after the initial delivery attempt a temporarily failed message may be passed to a secondary MTA. It's not uncommon for big sites to have pools of high throughput machines that don't have qrunners, and larger pools of machines that do. The first group gets a message, and tries to deliver immediately, and any temporary failure gets the messages shunted to the secondary pool. Once in the secondary pool, it can be bounced from machine to machine to load balance queue size and so on. That being said, the original query about this was a strawman argument designed specifically to find a problem, and I would say fairly confidently we don't need to worry about this. I have analyzed the logs on mail servers I have access to, and I cannot find any site which passes a message between more than a half dozen or at most a dozen IP addresses before delivery. This is two or three orders of magnitude less than the kind of thing Thomas and others are concerned about. By the time sites big enough to use pools that big exist (which I actually doubt - scalability might just be too hard to manage to be worth it), greylisting will be another dead tool in the arms race with spammers. So far, all the arguments against the idea have just been assertions and strawmen. Unless someone can present a serious argument, can we consider this thread done? Take care, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: greylisting on debian.org?
[sending systems that don't deal with greylisting] On Monday 17 July 2006 17:36, Magnus Holmgren wrote: [...] Also, this kind of information can be shared so that not every mail admin has to find it out himself by users complaining. Some data points: * the default greylist shipped by greylist is growing only quite slow, so apparently the big players are in there by now. * big pools are only the smallest part of that whitelist, so this discussion is a bit silly. The really problematic sites are not really rfc compliant: sites that don't retry at all, or that retry with different sender addresses (which from the pov of greylisting is the same, obviously.) So the question is, imho, not if we should potentially lock out users of big mail pools - those are in the default whitelists anyway by now. The question is: can we temporarily (until they can be whitelisted) lock out users of standards?-who-needs-standards? systems that don't implement sensible queueing. Many of these sites are small - but there are also a few bigger names: Yahoo groups, Amazon, Roche, Motorola. (According to postgrey's default whitelist. Some of these are from 2004 or earlier, and AFAIK nobody tries to verify if these systems are still stupid in that way.) cheers -- vbi -- Wie man sein Kind nicht nennen sollte: Hanno Ferr pgpkWEMiGmTS2.pgp Description: PGP signature
Re: greylisting on debian.org?
On Sun, Jul 16, 2006 at 08:36:31AM +0200, Christian Perrier wrote: Quoting Wolfgang Lonien ([EMAIL PROTECTED]): Do we use greylisting on the @debian.org domain and especially on @lists.debian.org? So, up to now, we've found Thomas Bushnell who seems really hardly voting against greylisting on Debian hosts, (...). So far and unless I forget someone, I haven't seen much other people being strongly opposed to greylisting on Debian hosts, Here is one: I am strongly opposed to greylisting (on mail sent to me or that I send), for the reason that it delays legitimate mail. Best Regards, -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
Christian Perrier [EMAIL PROTECTED] writes: So, up to now, we've found Thomas Bushnell who seems really hardly voting against greylisting on Debian hosts, with arguments about it breaking established standards. I personnally find these arguments very nitpicking and mostly aimed at finding a justification for an opinion that will definitely not change. I'm not a nitpicker for its own sake; I'm a nitpicker for the principle be liberal in what you accept and conservative in what you send. That calls for being nitpicky on one side and not the other. Still, if you think it's just nitpicking, then why not ask the IETF to amend the standard to clearly permit this practice? And finally, if we don't care about standards conformance, I have said that a good second-best is to document exactly what our requirements are, rather than burying them in apparent secrecy. This is not about stonewalling. So how about the last of these: clear and accurate documentation? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
Magnus Holmgren [EMAIL PROTECTED] writes: Do you have some mechanism in place to detect such a case when or if it happens? Deal with it when people complain. Also, this kind of information can be shared so that not every mail admin has to find it out himself by users complaining. Are you willing to promise that if someone gives a genuine complaint about how this is blocking their legitimat email, you will amend your practice to deal, rather than to insist that they should change theirs? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
Le lun 17 juillet 2006 19:53, Adrian von Bidder a écrit : So the question is, imho, not if we should potentially lock out users of big mail pools - those are in the default whitelists anyway by now. The question is: can we temporarily (until they can be whitelisted) lock out users of standards?-who-needs-standards? systems that don't implement sensible queueing. Many of these sites are small - but there are also a few bigger names: Yahoo groups, Amazon, Roche, Motorola. (According to postgrey's default whitelist. Some of these are from 2004 or earlier, and AFAIK nobody tries to verify if these systems are still stupid in that way.) OTOH those systems are not listed on RBL's (or it does not last) and you won't greylist them. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpQYwSHKTXs9.pgp Description: PGP signature
Re: greylisting on debian.org?
This one time, at band camp, Thomas Bushnell BSG said: And finally, if we don't care about standards conformance, I have said that a good second-best is to document exactly what our requirements are, rather than burying them in apparent secrecy. What standards, exactly? Can you be specific? I have seen you assert this several times, but I see nothing in the RFCs preventing a site from saying it has a temporary local problem when it doesn't. You've been asked this before in response to your assertion, and haven't answered. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: greylisting on debian.org?
Le lun 17 juillet 2006 22:29, Lionel Elie Mamane a écrit : Here is one: I am strongly opposed to greylisting (on mail sent to me or that I send), for the reason that it delays legitimate mail. which shows that you didn't read the discussion that was about enabling greylisting on *certain* *specificaly* *suspicious* hosts. a suspicious host is: * either listed on some RBL's (rbl listing dynamic blocks are a good start usually) * either having no reverse DNS set * either having curious EHLO lines (that one may catch too much good mail sadly, so it's to handle with care). * ... I apply greylisting on the two first criteriums on a quite used mail server (around 300.k mails per week, which is not very big, but should be representative enough). there is less than 50 mails a week over those that *may* be legitimate mails that are actually slowed down. so *please* do me a favour, read the thread you are answering to, because you really really answer miles away from the debate. and if you never actually realized, there *IS* such a slowdown on debian mail lists, it's called crossassassin, it kills master on a regular basis, and is *REALLY* less effective than greylisting. when spam makes our MX load go to highs I never suspected a machine could resist, I think maybe it's time to try a more robust solution. Pierre, that is pissed that his @debian.org address barely more usable than a hotmail one (and I do not know any worse mail service on the entire web). -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpvRDQPt81wu.pgp Description: PGP signature
Re: greylisting on debian.org?
On Mon, Jul 17, 2006 at 10:42:22PM +0100, Stephen Gran wrote: This one time, at band camp, Thomas Bushnell BSG said: And finally, if we don't care about standards conformance, I have said that a good second-best is to document exactly what our requirements are, rather than burying them in apparent secrecy. What standards, exactly? Can you be specific? I have seen you assert this several times, but I see nothing in the RFCs preventing a site from saying it has a temporary local problem when it doesn't. Even worse, there's nothing preventing a site from saying it has a temporary local problem when it _does_. Thus, if your mail server can't handle retrying, it will drop mail every time something is not in perfect working order. And hardware or network failures are something to be expected. Any legitimate server must support retrying. For any reason. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
On Monday 17 July 2006 23:41, Pierre Habouzit took the opportunity to write: Le lun 17 juillet 2006 19:53, Adrian von Bidder a écrit : So the question is, imho, not if we should potentially lock out users of big mail pools - those are in the default whitelists anyway by now. The question is: can we temporarily (until they can be whitelisted) lock out users of standards?-who-needs-standards? systems that don't implement sensible queueing. Many of these sites are small - but there are also a few bigger names: Yahoo groups, Amazon, Roche, Motorola. (According to postgrey's default whitelist. Some of these are from 2004 or earlier, and AFAIK nobody tries to verify if these systems are still stupid in that way.) OTOH those systems are not listed on RBL's (or it does not last) and you won't greylist them. Which RBL's do you have in mind? I mean, some RBL's, like XBL/SBL, are high-quality enough that you can outright reject. Others, like SpamCop, are likely to include some of the bigger names from time to time. DUL lists might be good candidates. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpShTNmCba9F.pgp Description: PGP signature
Re: greylisting on debian.org?
On Monday 17 July 2006 23:27, Thomas Bushnell BSG took the opportunity to write: Magnus Holmgren [EMAIL PROTECTED] writes: Deal with it when people complain. Also, this kind of information can be shared so that not every mail admin has to find it out himself by users complaining. Are you willing to promise that if someone gives a genuine complaint about how this is blocking their legitimat email, you will amend your practice to deal, rather than to insist that they should change theirs? Parse error. If someone complains because their mail servers are too spread out, I'd whitelist them. If someone complains because their own software is broken, well, that depends. I would explain to them nicely why they should fix it, but I wouldn't argue unless I have a good reason to do so. Nothing needs to be amended. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpt7qL58rXV8.pgp Description: PGP signature
Re: greylisting on debian.org?
Le lundi 17 juillet 2006 à 22:29 +0200, Lionel Elie Mamane a écrit : On Sun, Jul 16, 2006 at 08:36:31AM +0200, Christian Perrier wrote: Quoting Wolfgang Lonien ([EMAIL PROTECTED]): Do we use greylisting on the @debian.org domain and especially on @lists.debian.org? So, up to now, we've found Thomas Bushnell who seems really hardly voting against greylisting on Debian hosts, (...). So far and unless I forget someone, I haven't seen much other people being strongly opposed to greylisting on Debian hosts, Here is one: I am strongly opposed to greylisting (on mail sent to me or that I send), for the reason that it delays legitimate mail. I have refused greylisting for a long time for that exact reason. However the setup Pierre Habouzit describes does not delay most of legitimate mail. Frankly, the remaining delays are sporadic and one can live with them. I'm applying greylisting if one of these conditions is met: * the incoming IP is listed in a DUL; * Exim sender/callout fails with a fatal error. This setup has considerably reduced both the load and the amount of spam on the server. However I still have to deal with @debian.org spam with a less and less efficient (and more and more cpu consuming) bayesian filter, as it cannot be filtered out this way. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: greylisting on debian.org?
On Jul 17, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: Still, if you think it's just nitpicking, then why not ask the IETF to amend the standard to clearly permit this practice? Because there is no reason to do this, this is not a standard issue but plain operations. -- ciao, Marco signature.asc Description: Digital signature
Re: greylisting on debian.org?
Quoting Wolfgang Lonien ([EMAIL PROTECTED]): Hi all, this is maybe the wrong group for it (sorry in that case), but: Do we use greylisting on the @debian.org domain and especially on @lists.debian.org? So, up to now, we've found Thomas Bushnell who seems really hardly voting against greylisting on Debian hosts, with arguments about it breaking established standards. I personnally find these arguments very nitpicking and mostly aimed at finding a justification for an opinion that will definitely not change. So far and unless I forget someone, I haven't seen much other people being strongly opposed to greylisting on Debian hosts, especially with the setup described by Pierre Habouzit (greylisting only suspicious hosts). Isn't it time to move on? signature.asc Description: Digital signature
Re: greylisting on debian.org?
On Thu, Jul 13, 2006 at 11:01:09AM -0700, Thomas Bushnell BSG wrote: Henrique de Moraes Holschuh [EMAIL PROTECTED] writes: The specific example used was some spam source sitting in the same /27 netblock in a colo server room, and getting through the graylister because a proper MTA from the same /27 netblock had already been added to the approve it, it does retries list of the graylister. Ok, now I understand. As I've already said, graylisting on /27 netblocks amounts to inventing new network standards, which I believe should go through the IETF standardization process before we block email from people who don't comply with our newly invented standards. Really, I don't understand why you wrote this. Greylisting already exists. This would just make it _less_ of a problem. By greylisting from /27 netblocks, you wouldn't block any additional mail as opposed to greylisting in general; quite to the contrary. Greylisting in this manner does not require anything specific from a remote host, except that it must follow the standards as defined in RFC2821 and come back some time after it received the initial 4xx status reply. What part of that is a newly invented standard? Moreover, I'd like to point out that any piece of software which intends to implement some anti-spam measures will have to interpret some specific standard more strictly than required by the relevant RFCs so as to be able to distinguish spambots from human beings. There is no way around that, save making degrading some human being to anti-spam measure for the Debian Project and requiring him or her to manually approve each and every email to our mailinglists. I don't think you want that. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
Wouter Verhelst [EMAIL PROTECTED] wrote: On Thu, Jul 13, 2006 at 11:01:09AM -0700, Thomas Bushnell BSG wrote: [...] Ok, now I understand. As I've already said, graylisting on /27 netblocks amounts to inventing new network standards, which I believe should go through the IETF standardization process before we block email from people who don't comply with our newly invented standards. Really, I don't understand why you wrote this. Greylisting already exists. This would just make it _less_ of a problem. By greylisting from /27 netblocks, you wouldn't block any additional mail as opposed to greylisting in general; quite to the contrary. Greylisting in this manner does not require anything specific from a remote host, except that it must follow the standards as defined in RFC2821 and come back some time after it received the initial 4xx status reply. What part of that is a newly invented standard? [...] Hello, The following setup would be in compliance with rfc2821 but would not be able to deliver mail to a greylisting host: - retrying every hour for up to five days - messages are sent out from 120 different IP-addresses all living in different /27 netblocks. - retries do not happen on the same IP. Initial try IP-address #1, 2nd try IP-address #2, ... ,120th try IP-address #120 This in an extreme setup, but if the retry strategy is more complicated, e.g. every hour for 12 hours, then every two hours for 12 hours and every four hours from then on only 42 IP addresses are needed. If some (broken) caching is involved numbers go down further. cu andreas -- The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal vision of the emperor's, and its inclusion in this work does not constitute tacit approval by the author or the publisher for any such projects, howsoever undertaken.(c) Jasper Ffforde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
This one time, at band camp, Andreas Metzler said:
Wouter Verhelst [EMAIL PROTECTED] wrote:
On Thu, Jul 13, 2006 at 11:01:09AM -0700, Thomas Bushnell BSG wrote:
[...]
Ok, now I understand. As I've already said, graylisting on /27
netblocks amounts to inventing new network standards, which I believe
should go through the IETF standardization process before we block
email from people who don't comply with our newly invented standards.
Really, I don't understand why you wrote this.
Greylisting already exists. This would just make it _less_ of a problem.
By greylisting from /27 netblocks, you wouldn't block any additional
mail as opposed to greylisting in general; quite to the contrary.
Greylisting in this manner does not require anything specific from a
remote host, except that it must follow the standards as defined in
RFC2821 and come back some time after it received the initial 4xx status
reply. What part of that is a newly invented standard?
[...]
Hello,
The following setup would be in compliance with rfc2821 but would
not be able to deliver mail to a greylisting host:
- retrying every hour for up to five days
- messages are sent out from 120 different IP-addresses all living in
different /27 netblocks.
- retries do not happen on the same IP. Initial try IP-address #1, 2nd
try IP-address #2, ... ,120th try IP-address #120
I suggest that when we find a domain that sends mail from 120 /27's
(roughly a /20), we worry about it then.
zgrep -E 'H=[^[:space:]]*.yahoo.com ' /var/log/exim4/mainlog* | egrep -v
'(-|=)' | \
awk -F [ '{print $2}' | awk -F] '{print $1}' | sort -u | wc -l
2792
That's just over a /21, and they're the biggest I deal with. This is just
under a year's logs, on a fairly busy site. This site uses greylisting,
and does not use netblocks - it greylists the IP/sender/recipient tuple
as is. I have had no complaints about lost mail, although a few about
slow mail.
But that's not the entire point; there will be false positives. There are
probably false positives right now with the various other spam filters in
place, although I have no idea and can't check on them. Presumably the
sender doesn't get a notification in cases where a procmail rule or
spamassassin rule keeps a mail from hitting a list or my @debian.org
account.
With a greylisting system, there is no blackholing of mail - the sender
will get 'still retrying' DSN's, and finally a couldn't deliver DSN
in the above scenario. The sender is notified if there's a problem, so
long as the sending site pretends to follow the RFC.
The point is to make email useable without making it untreliable. This
way seems like a pretty good compromise to me.
--
-
| ,''`.Stephen Gran |
| : :' :[EMAIL PROTECTED] |
| `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
-
signature.asc
Description: Digital signature
Re: greylisting on debian.org?
On 7/15/06, Andreas Metzler [EMAIL PROTECTED] wrote: Hello, The following setup would be in compliance with rfc2821 but would not be able to deliver mail to a greylisting host: - retrying every hour for up to five days - messages are sent out from 120 different IP-addresses all living in different /27 netblocks. - retries do not happen on the same IP. Initial try IP-address #1, 2nd try IP-address #2, ... ,120th try IP-address #120 I thought the point was that someone with such a setup is unlikely to have all 120 servers either listed on an RBL or with broken reverse DNS. And if they are, are you sure you want to receive mail from them? Greylisting everything is silly, and that's not what's being discussed here (AIUI anyway). Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
Martijn van Oosterhout [EMAIL PROTECTED] wrote: On 7/15/06, Andreas Metzler [EMAIL PROTECTED] wrote: Hello, The following setup would be in compliance with rfc2821 but would not be able to deliver mail to a greylisting host: [...] I thought the point was that someone with such a setup is unlikely to have all 120 servers either listed on an RBL or with broken reverse DNS. And if they are, are you sure you want to receive mail from them? [...] I am all for greylisting as suggested, I just wanted to clarify Thomas' claim that greylisting *can* break RFC compliant hosts, i.e. the inventing new network standards. cu andreas -- The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal vision of the emperor's, and its inclusion in this work does not constitute tacit approval by the author or the publisher for any such projects, howsoever undertaken.(c) Jasper Ffforde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
Andreas Metzler [EMAIL PROTECTED] writes: This in an extreme setup, ...or a setup designed to be used as an argument against greylisting. -- Stig Sandbeck Mathisen [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
Wouter Verhelst [EMAIL PROTECTED] writes: Greylisting already exists. This would just make it _less_ of a problem. By greylisting from /27 netblocks, you wouldn't block any additional mail as opposed to greylisting in general; quite to the contrary. Yes, I understand. What I'm saying is that the confining the graylisting to /27 netblocks instead of per-host, while an improvement, is not enough of an improvement for me to say, yes, what a wonderful idea graylisting is. Or rather, it *is* a wonderful idea, but I believe that conforming to network protocols is an even more wonderful idea. When you say graylisting already exists, you seem to be ignoring the possibility that we could have no graylisting. It's not like we are somehow obliged to choose a graylisting solution. Greylisting in this manner does not require anything specific from a remote host, except that it must follow the standards as defined in RFC2821 and come back some time after it received the initial 4xx status reply. What part of that is a newly invented standard? The standards do *not* say that the remote host must resend the message from the same host, or the same /27 netblock. It is this requirement which is newly invented. Moreover, I'd like to point out that any piece of software which intends to implement some anti-spam measures will have to interpret some specific standard more strictly than required by the relevant RFCs so as to be able to distinguish spambots from human beings. There is no way around that, save making degrading some human being to anti-spam measure for the Debian Project and requiring him or her to manually approve each and every email to our mailinglists. I don't think you want that. I can just hear George Bush using this argument. We have no way of imposing our will on evil-person so-and-so except by starting a war and killing millions of people, so, golly shucks, we just have to start the war. Sorry guys! Saying that there is no way to meet your goals other than by doing some bad thing does not somehow eliminate the badness of the thing. It is you who wants to avoid cooperating with the IETF on anti-spam measures, finding solutions that perhaps can work for the whole network. Not me. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
Stephen Gran [EMAIL PROTECTED] writes: I suggest that when we find a domain that sends mail from 120 /27's (roughly a /20), we worry about it then. An excellent strategy. Do you have some mechanism in place to detect such a case when or if it happens? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
Henrique de Moraes Holschuh [EMAIL PROTECTED] writes: The specific example used was some spam source sitting in the same /27 netblock in a colo server room, and getting through the graylister because a proper MTA from the same /27 netblock had already been added to the approve it, it does retries list of the graylister. Ok, now I understand. As I've already said, graylisting on /27 netblocks amounts to inventing new network standards, which I believe should go through the IETF standardization process before we block email from people who don't comply with our newly invented standards. If you don't think the standard could make it through the IETF, doesn't that tell you something? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
On Mon, Jul 10, 2006 at 06:28:40PM +0100, Stephen Gran wrote: This one time, at band camp, Henrique de Moraes Holschuh said: On Mon, 10 Jul 2006, Adrian von Bidder wrote: As I know it, the receiving MX connects the regular MX for the sender address to see if *that* is ready to receive mail. Works beautifully if outbound != inbound. And sets the envolope sender to what in the probe? , hopefully. Anything else is silly. Yes and no. An increasing number of sites refuse bounces (that is messages with null return-path) to some addresses that are known never to send mail. This breaks the procedure and is reacted by other sites by using a fixed [EMAIL PROTECTED] address, and mail to that address doesn't incur that check (but ends up in /dev/null or gets refused at DATA time). -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
This one time, at band camp, Lionel Elie Mamane said: On Mon, Jul 10, 2006 at 06:28:40PM +0100, Stephen Gran wrote: This one time, at band camp, Henrique de Moraes Holschuh said: On Mon, 10 Jul 2006, Adrian von Bidder wrote: As I know it, the receiving MX connects the regular MX for the sender address to see if *that* is ready to receive mail. Works beautifully if outbound != inbound. And sets the envolope sender to what in the probe? , hopefully. Anything else is silly. Yes and no. An increasing number of sites refuse bounces (that is messages with null return-path) to some addresses that are known never to send mail. This breaks the procedure and is reacted by other sites by using a fixed [EMAIL PROTECTED] address, and mail to that address doesn't incur that check (but ends up in /dev/null or gets refused at DATA time). When I find sites that are broken, I report them to dsn.rfc-ignorant.com, and then others can use that as a whitelist or blacklist as they choose for deciding what to do with callouts and the like. I do refuse the null sender to various role accounts that never send mail, but I don't do it at RCPT TO time, only after the remote end has sent DATA. This allows callouts to work, but still blocks bounces resulting from joe jobs and the like. Take care, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: greylisting on debian.org?
On Tue, Jul 11, 2006 at 08:56:52AM +0200, Lionel Elie Mamane wrote: On Mon, Jul 10, 2006 at 06:28:40PM +0100, Stephen Gran wrote: This one time, at band camp, Henrique de Moraes Holschuh said: On Mon, 10 Jul 2006, Adrian von Bidder wrote: As I know it, the receiving MX connects the regular MX for the sender address to see if *that* is ready to receive mail. Works beautifully if outbound != inbound. And sets the envolope sender to what in the probe? , hopefully. Anything else is silly. Yes and no. An increasing number of sites refuse bounces (that is messages with null return-path) to some addresses that are known never to send mail. This breaks the procedure and is reacted by other sites by using a fixed [EMAIL PROTECTED] address, and mail to that address doesn't incur that check (but ends up in /dev/null or gets refused at DATA time). That doesn't add up. Since never sends mail, there will never be a sender verification callback TO that address either. What's the problem? Likewise if you refuse bounces to other inbound-only addresses, you should never get inbound probes. That is kind of the point. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
On Tue, Jul 11, 2006 at 08:48:43PM +1000, Hamish Moffatt wrote: On Tue, Jul 11, 2006 at 08:56:52AM +0200, Lionel Elie Mamane wrote: On Mon, Jul 10, 2006 at 06:28:40PM +0100, Stephen Gran wrote: This one time, at band camp, Henrique de Moraes Holschuh said: On Mon, 10 Jul 2006, Adrian von Bidder wrote: As I know it, the receiving MX connects the regular MX for the sender address to see if *that* is ready to receive mail. Works beautifully if outbound != inbound. And sets the envolope sender to what in the probe? , hopefully. Anything else is silly. Yes and no. An increasing number of sites refuse bounces (that is messages with null return-path) to some addresses that are known never to send mail. This breaks the procedure and is reacted by other sites by using a fixed [EMAIL PROTECTED] address, and mail to that address doesn't incur that check (but ends up in /dev/null or gets refused at DATA time). That doesn't add up. Since never sends mail, there will never be a sender verification callback TO that address either. Some sites verify the [EMAIL PROTECTED] and [EMAIL PROTECTED] addresses before accepting mail with sender [EMAIL PROTECTED] . -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
On 7/11/06, Lionel Elie Mamane [EMAIL PROTECTED] wrote: Some sites verify the [EMAIL PROTECTED] and [EMAIL PROTECTED] addresses before accepting mail with sender [EMAIL PROTECTED] . IIRC sourceforge verifies for the existence of a postmaster@ address -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
This one time, at band camp, Török Edvin said: On 7/11/06, Lionel Elie Mamane [EMAIL PROTECTED] wrote: Some sites verify the [EMAIL PROTECTED] and [EMAIL PROTECTED] addresses before accepting mail with sender [EMAIL PROTECTED] . IIRC sourceforge verifies for the existence of a postmaster@ address That's a lot of overhead when there's a postmaster.rfc-ignorant.org rbl. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: greylisting on debian.org?
On Tue, Jul 11, 2006 at 01:28:47PM +0200, Lionel Elie Mamane wrote: On Tue, Jul 11, 2006 at 08:48:43PM +1000, Hamish Moffatt wrote: That doesn't add up. Since never sends mail, there will never be a sender verification callback TO that address either. Some sites verify the [EMAIL PROTECTED] and [EMAIL PROTECTED] addresses before accepting mail with sender [EMAIL PROTECTED] . That seems reasonable. If you're sending as [EMAIL PROTECTED] you should accept callbacks for it, and likewise you're required to accept mail for [EMAIL PROTECTED] Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
Henrique de Moraes Holschuh [EMAIL PROTECTED] writes: On Mon, 10 Jul 2006, Thomas Bushnell BSG wrote: martin f krafft [EMAIL PROTECTED] writes: That's better than not greylisting anyone. Nobody is trying to design the perfect spam filter. We just want to reduce spam on debian.org. A perfect spam filter is one which catches all spam and bounces no valid mail. Saying we aren't trying to be perfect is ambiguous about which imperfections you are willing to tolerate. I would like you to be explicit and clear about which valid mail you will be bouncing, rather than vague and inspecific. It was pretty clear for anyone actually reading the messages. The error is in the safe side, i.e. let stuff through the graylisting without delaying it. Huh? This makes no sense to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
On Tue, 11 Jul 2006, Thomas Bushnell BSG wrote: Henrique de Moraes Holschuh [EMAIL PROTECTED] writes: On Mon, 10 Jul 2006, Thomas Bushnell BSG wrote: martin f krafft [EMAIL PROTECTED] writes: That's better than not greylisting anyone. Nobody is trying to design the perfect spam filter. We just want to reduce spam on debian.org. A perfect spam filter is one which catches all spam and bounces no valid mail. Saying we aren't trying to be perfect is ambiguous about which imperfections you are willing to tolerate. I would like you to be explicit and clear about which valid mail you will be bouncing, rather than vague and inspecific. It was pretty clear for anyone actually reading the messages. The error is in the safe side, i.e. let stuff through the graylisting without delaying it. Huh? This makes no sense to me. You do not graylist, i.e. you let it through the graylisting stage unaffected. The specific example used was some spam source sitting in the same /27 netblock in a colo server room, and getting through the graylister because a proper MTA from the same /27 netblock had already been added to the approve it, it does retries list of the graylister. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
Thomas Bushnell BSG tb at becket.net writes: martin f krafft madduck at debian.org writes: [...] It assumes, for example, that the remote MTA will use the same IP address each time it sends the message. [...] eh no. Standard greylisting practise nowadays (it already was standard when sarge was released) is to not greylist on host IP but at least on the /27 netblock. cu andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
On Sun, 09 Jul 2006, Thomas Bushnell BSG wrote: I don't think I understand just what you're saying. Can you spell out the details for me? Does the second email I sent (with the missing stuff) provides the clarification you asked for? It distresses me that I have said twice now that a solution which Read below. When you do, please remember that many of us consider that a fully-open system which drowns us in SPAM is also broken, because you do lose information for failure of locating it among the noise. dumb one in my book. I want a solution which specifically *never* needs any preset hardcoded this set of addresses/domains gets a pass. There is no hardcoding. Please use more exact terms. I think I understood what you wanted to say, but whitelists are not *hardcoded*. They have never been, they are updated in runtime. So use the proper terms next time. In their dumbest form, match using big, static netmasks like 255.255.128.0. That should give you a hint of what I am talking about. A hardcoded list is the problem. Got it? A loose hardcoded list is still a problem. What I believe you mean is that for you, a non-perfect solution for identifying outgoing SMTP clusters is not acceptable, as it gives a non-zero possibility of permanent delivery failure to a graylisted destination. Well, there are solutions that are good enough in practice. If you do not like them because they are not perfect (as in guaranteed zero fail rate), then there is no solution I know of that will be acceptable to you. But please remember that people operating outgoing SMTP clusters *want* to deliver email, and that they are aware of graylisting practices and also of the diminishing probability of sucessful delivery when the sending site has broken DNS configuration, or is listed in popular blackists and dial-up IP space lists. Also, keep in mind that the Debian graylisting proposal specifically states that graylisting is not to be applied to every single incoming connection, but rather to those coming from broken DNS sources, and blacklisted sources, which are extremely unlikely to be the class of sending cluster that would break graylisting in the first place. So you do NOT need a perfect theorical solution to get zero fail rate in practice for the proposed graylisting scheme. You don't get any guarantees of a zero fail rate, however. Here's what I understood of what you wrote: Alice wants to send email to Bob. Alice graylists incoming email. Bob does sender verification trying to email people back before accepting a message. You claim Alice cannot send mail to Bob because Bob will attempt to almost send email back to Alice, thus Bob's verification attempt will be graylisted (with a 4xx), causing Bob to deny the delivery of Alice's message with a 4xx. If that's not correct, please clarify. If it is correct, I am asking you *why* Alice's system will never let Bob's verification probe through (thus allowing her email to be delivered to Bob). Because Bob never sends a complete email message to Alice. That is a broken graylist implementation, then. It should be fixed (or avoided at all costs). Which graylister was that one? For graylisting, you need to verify that the sender will retry. This is not done through verification of completed email delivery! It is done as soon as you got enough information to identify it as the same sender and message. If the sender will retry, you are to approve him through the graylist regardless of any delivery taking place. I *can* see a scenario where delivery might never happen (I am ignoring configuration error scenarios on Alice's side), but it depends on Alice also doing the same type of sender verification, and on one or both sides violating RFC 2821. Doing sender verification and graylisting are both violations of the RFCs. You can hardly say this will work as long as everyone else follows the RFC when you aren't doing so yourself. My point is that Agreed, you cannot say that. But nobody did say it. And the scenario you experienced for Alice's failure to deliver email to Bob requires a broken graylisting implementation that acts in a specific *wrong* way, and that was the answer to my question. Now, I am a bit annoyed with the graylisting violates the RFCs generic statement, so I'd really appreciate if you could make it more specific. Please explain how the idea behind graylisting (force a host to retry a SMTP transaction at a later time) violates RFC 2821. RFC 2821, AFAIK, requires that the sending side deal with that scenario, and anyone who doesn't deal with it is the one violating the RFC. There is an issue with current graylisting implementations that *I know of* (and I certainly am no expert in the area), in that they *will* fail to recognize shared-queue outgoing clusters in theory, and *may* fail to do so in practice (depends on such cluster deployments failing to match known patterns). This
Re: greylisting on debian.org?
On Mon, 10 Jul 2006 06:15:55 + (UTC), Andreas Metzler [EMAIL PROTECTED] wrote: Thomas Bushnell BSG tb at becket.net writes: martin f krafft madduck at debian.org writes: [...] It assumes, for example, that the remote MTA will use the same IP address each time it sends the message. [...] eh no. Standard greylisting practise nowadays (it already was standard when sarge was released) is to not greylist on host IP but at least on the /27 netblock. So you will whitelist the spamming customer in the same rack farm than your bona fide communications partner. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: greylisting on debian.org?
also sprach Marc Haber [EMAIL PROTECTED] [2006.07.10.0930 +0200]: eh no. Standard greylisting practise nowadays (it already was standard when sarge was released) is to not greylist on host IP but at least on the /27 netblock. So you will whitelist the spamming customer in the same rack farm than your bona fide communications partner. That's better than not greylisting anyone. Nobody is trying to design the perfect spam filter. We just want to reduce spam on debian.org. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system prisons are built with stones of law, brothels with bricks of religion. -- william blake signature.asc Description: Digital signature (GPG/PGP)
Re: greylisting on debian.org?
On Jul 10, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: I am concerned that you not use a spam-defeating technique which blocks perfectly legitimate and standards-compliant email. Then why you are not loudly complaining about the antispam software currently applied to our mail lists and BTS, which silently discards mail that appears to be spam? Silently discarding legitimate email is a problem, rejecting legitimate email is at best an annoyance. -- ciao, Marco signature.asc Description: Digital signature
Re: greylisting on debian.org?
On Mon, Jul 10, 2006 at 07:39:19AM +0200, Pierre Habouzit wrote: Le lun 10 juillet 2006 02:17, Matthew R. Dempsky a écrit : On Sun, Jul 09, 2006 at 05:02:39PM -0700, Thomas Bushnell BSG wrote: Another problem is with hosts that do not accept a message from an MTA unless that MTA is willing to accept replies. This is a common spam prevention measure. It also prevents mail from setups that use different servers for inbound and outbound mail. which is highly unlikely if you never greylist hosts that are not listed in rbl's. This has nothing to do with greylisting. ``It'' above refers to ``Not accepting messages from an MTA unless that MTA is willing to accept replies'', not ``graylisting''. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
On Sunday 09 July 2006 15:48, Martijn van Oosterhout wrote: [greylisting] The point was about mailers sending mail to debian. If they receive a 4xx they have to queue the mail and retry later. It's cheap for debian, but expensive for everyone else. Does anybody have sensible numbers about that? On my relatively small server, I usually have between 0 and 40 messages in the deferred queue. Of those, up to 1 or 2 are due to greylisting. All others are because recipients have crap mailservers or nameservers. As madduck said: either you are small, so your mailserver isn't loaded anyway, or you're big, so the additional load from greylisting isn't noticeable, or you're a spammer. Hmm. Discussing mail problems on irc while answering mailing list mail in a mail setup related mail thread mail confuses me mail. can't mail stop mail. cheers -- mail -- Perl: The Swiss Army Chainsaw pgpmEmzcvnOMH.pgp Description: PGP signature
Re: greylisting on debian.org?
On Monday 10 July 2006 02:17, Matthew R. Dempsky wrote: On Sun, Jul 09, 2006 at 05:02:39PM -0700, Thomas Bushnell BSG wrote: Another problem is with hosts that do not accept a message from an MTA unless that MTA is willing to accept replies. This is a common spam prevention measure. It also prevents mail from setups that use different servers for inbound and outbound mail. Hmm. I've not seen this kind of sender verification. As I know it, the receiving MX connects the regular MX for the sender address to see if *that* is ready to receive mail. Works beautifully if outbound != inbound. While very effective, this is admittedly the kind of spam prevention measure which puts some load on the systems on both ends. cheers -- vbi -- featured product: the KDE desktop - http://kde.org pgp4PvAIo4oYH.pgp Description: PGP signature
Re: greylisting on debian.org?
On Monday 10 July 2006 06:58, Thomas Bushnell BSG wrote: Doing sender verification and graylisting are both violations of the RFCs. Which rfcs and where, exactly? Specific filename, version and line numbers, as Kimball would say it. AFAICT, the protocol allows the receiving end to temporarily reject email, and the sending end will retry. AFAICT QUIT is allowed after RCPT TO to abort a mail transaction - and sender verification is no different from a normal mail transaction in the view of the receiver. -- vbi -- featured link: http://fortytwo.ch/smtp pgpt9ZMHb4WZG.pgp Description: PGP signature
Re: greylisting on debian.org?
On Mon, Jul 10, 2006 at 05:57:45PM +0200, Adrian von Bidder wrote: On Monday 10 July 2006 02:17, Matthew R. Dempsky wrote: On Sun, Jul 09, 2006 at 05:02:39PM -0700, Thomas Bushnell BSG wrote: Another problem is with hosts that do not accept a message from an MTA unless that MTA is willing to accept replies. This is a common spam prevention measure. It also prevents mail from setups that use different servers for inbound and outbound mail. Hmm. I've not seen this kind of sender verification. As I know it, the receiving MX connects the regular MX for the sender address to see if *that* is ready to receive mail. Works beautifully if outbound != inbound. While very effective, this is admittedly the kind of spam prevention measure which puts some load on the systems on both ends. Actually, I don't see it as spam prevention. It is a mean to lock onself out of broken|fascist mail servers and let their users know that it is their server blocking legitimate email and not my users ignoring them. There is no point in accepting a message that cannot be answered (or bounced). The spam prevention is only a nice side effect. -- Blu. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
This one time, at band camp, Thomas Bushnell BSG said: martin f krafft [EMAIL PROTECTED] writes: Anyway, I'll be interested to hear a summary of their arguments, as Christian Perrier requested. I find it hard to imagine how properly configured greylisting should cause any problems. It's a violation of the standard. It is especially problematic, because it is a violation against the spirit of being liberal in what you accept, and conservative in what you require. Sadly, those days may be coming to an end. It assumes, for example, that the remote MTA will use the same IP address each time it sends the message. If the remote MTA is a big server farm, with a lot of different hosts that could be processing the mail, what is your strategy for preventing essentially infinite delay? I use a greylist implementation that autowhitelists after a configurable number of successful retries for a tuple. Assuming you mean places like yahoo or aol, the essentially infinite delay you speak of has never been an issue so far. They all end up whitelisted after a while, and then mail from them proceeds without delay. Assuming the number of users debian has, it shouldn't take very long to record hits for all of their outbound servers. Another problem is with hosts that do not accept a message from an MTA unless that MTA is willing to accept replies. This is a common spam prevention measure. The graylisting host cannot then send mail to such sites until they've been whitelisted, because when they try the reverse connection out, it always gets a 4xx error. I've been bitten by this one before. That is an odd implementation of sender callouts designed by someone who doesn't understand SMTP, and is not really an issue for the conversation at hand. Normal sender callouts, which route the message to the public MX, have their pros and cons, but it's not under discussion at the moment. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: greylisting on debian.org?
On Mon, 10 Jul 2006, Adrian von Bidder wrote: On Monday 10 July 2006 02:17, Matthew R. Dempsky wrote: On Sun, Jul 09, 2006 at 05:02:39PM -0700, Thomas Bushnell BSG wrote: Another problem is with hosts that do not accept a message from an MTA unless that MTA is willing to accept replies. This is a common spam prevention measure. It also prevents mail from setups that use different servers for inbound and outbound mail. Hmm. I've not seen this kind of sender verification. As I know it, the receiving MX connects the regular MX for the sender address to see if *that* is ready to receive mail. Works beautifully if outbound != inbound. And sets the envolope sender to what in the probe? -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
Andreas Metzler [EMAIL PROTECTED] writes: Thomas Bushnell BSG tb at becket.net writes: martin f krafft madduck at debian.org writes: [...] It assumes, for example, that the remote MTA will use the same IP address each time it sends the message. [...] eh no. Standard greylisting practise nowadays (it already was standard when sarge was released) is to not greylist on host IP but at least on the /27 netblock. Then, it assumes, for example, that the remote MTA will use the same /27 netblock each time it sends the message. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
martin f krafft [EMAIL PROTECTED] writes: That's better than not greylisting anyone. Nobody is trying to design the perfect spam filter. We just want to reduce spam on debian.org. A perfect spam filter is one which catches all spam and bounces no valid mail. Saying we aren't trying to be perfect is ambiguous about which imperfections you are willing to tolerate. I would like you to be explicit and clear about which valid mail you will be bouncing, rather than vague and inspecific. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
On Jul 10, Adrian von Bidder [EMAIL PROTECTED] wrote: AFAICT, the protocol allows the receiving end to temporarily reject email, and the sending end will retry. AFAICT QUIT is allowed after RCPT TO to abort a mail transaction - and sender verification is no different from a normal mail transaction in the view of the receiver. Correct. OTOH, sender verification is evil for a different reason: if a domain is forged by a spammer and a large number of systems receiving the spam perform sender verification, the MX of the forged domain will be DoS'ed. This is about as antisocial as vacation messages and replies by antivirus software. -- ciao, Marco signature.asc Description: Digital signature
Re: greylisting on debian.org?
Henrique de Moraes Holschuh [EMAIL PROTECTED] writes: Read below. When you do, please remember that many of us consider that a fully-open system which drowns us in SPAM is also broken, because you do lose information for failure of locating it among the noise. You may lose that information; I do not. There is no hardcoding. Please use more exact terms. I think I understood what you wanted to say, but whitelists are not *hardcoded*. They have never been, they are updated in runtime. So use the proper terms next time. Then how do you know which things to add to the white list *in the case I mentioned*? What I believe you mean is that for you, a non-perfect solution for identifying outgoing SMTP clusters is not acceptable, as it gives a non-zero possibility of permanent delivery failure to a graylisted destination. I want you to be explicit and clear about which new rules you are writing into the RFCs, so that people can conform to them. You are making up new standards and hosing people who do not comply; at the very least you have an obligation to document the new standards you are making up. Please explain how the idea behind graylisting (force a host to retry a SMTP transaction at a later time) violates RFC 2821. RFC 2821, AFAIK, requires that the sending side deal with that scenario, and anyone who doesn't deal with it is the one violating the RFC. You must be willing to retry the transaction, but there is *not* a requirement that you retry it from the same address, or the same netblock, or the same anything. If the graylisting waited until DATA, and cached the message contents (or a hash of them, say) in such a way that it could detect the retransmit no matter what address it came from the next time, this would work just fine AFAICT. Still, making up new standards is a risk-prone thing. The fact that nobody has thought of the case where this will fail does not mean it won't fail. Graylisting was a wonderful idea, but the people who first thought of it didn't even notice the failure modes. This is the danger, and a clear and open statement these are the specific cases where we know that our scheme will fail would be a very nice thing. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
[EMAIL PROTECTED] (Marco d'Itri) writes: On Jul 10, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: I am concerned that you not use a spam-defeating technique which blocks perfectly legitimate and standards-compliant email. Then why you are not loudly complaining about the antispam software currently applied to our mail lists and BTS, which silently discards mail that appears to be spam? I have complained about that, in fact. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
On Jul 10, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: I want you to be explicit and clear about which new rules you are writing into the RFCs, so that people can conform to them. You are making up new standards and hosing people who do not comply; at the very least you have an obligation to document the new standards you are making up. No, not really. The Internet does not work this way. People have no obligation to document anything at all, and the rest of the world has to cope. Experience shows that the rest of the world is coping pretty well with graylisting, notwithstanding how many pathological situations you can design (interesting, this list looks like debian-legal@ again...). -- ciao, Marco signature.asc Description: Digital signature
Re: greylisting on debian.org?
This one time, at band camp, Henrique de Moraes Holschuh said: On Mon, 10 Jul 2006, Adrian von Bidder wrote: On Monday 10 July 2006 02:17, Matthew R. Dempsky wrote: On Sun, Jul 09, 2006 at 05:02:39PM -0700, Thomas Bushnell BSG wrote: Another problem is with hosts that do not accept a message from an MTA unless that MTA is willing to accept replies. This is a common spam prevention measure. It also prevents mail from setups that use different servers for inbound and outbound mail. Hmm. I've not seen this kind of sender verification. As I know it, the receiving MX connects the regular MX for the sender address to see if *that* is ready to receive mail. Works beautifully if outbound != inbound. And sets the envolope sender to what in the probe? , hopefully. Anything else is silly. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: greylisting on debian.org?
[EMAIL PROTECTED] (Marco d'Itri) writes: On Jul 10, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: I want you to be explicit and clear about which new rules you are writing into the RFCs, so that people can conform to them. You are making up new standards and hosing people who do not comply; at the very least you have an obligation to document the new standards you are making up. No, not really. The Internet does not work this way. People have no obligation to document anything at all, and the rest of the world has to cope. I'm speaking about Debian here. We stand for openness, clarity, and free software. We stand for the interests of our users. We do not stand for keeping secrets and causing problems. I want *you*, the people pushing this for Debian, to do this, if they want it on Debian. What you do on your own systems is not my concern. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
On Jul 10, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: I'm speaking about Debian here. We stand for openness, clarity, and free software. We stand for the interests of our users. We do not We used to. Nowadays we stand for the mechanical veneration of holy principles. -- ciao, Marco signature.asc Description: Digital signature
Re: greylisting on debian.org?
On 2006-07-10 Thomas Bushnell BSG [EMAIL PROTECTED] wrote: Andreas Metzler [EMAIL PROTECTED] writes: Thomas Bushnell BSG tb at becket.net writes: martin f krafft madduck at debian.org writes: [...] It assumes, for example, that the remote MTA will use the same IP address each time it sends the message. [...] eh no. Standard greylisting practise nowadays (it already was standard when sarge was released) is to not greylist on host IP but at least on the /27 netblock. Then, it assumes, for example, that the remote MTA will use the same /27 netblock each time it sends the message. No. It assumes that the sending MTA will not circle through a number of different /27 netblocks that is so big that the retry limit will be hit before successful delivery. cu andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
On Mon, 10 Jul 2006, Marco d'Itri wrote: On Jul 10, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: I am concerned that you not use a spam-defeating technique which blocks perfectly legitimate and standards-compliant email. Then why you are not loudly complaining about the antispam software currently applied to our mail lists and BTS, which silently discards mail that appears to be spam? At least for the BTS, those messages are not discarded; they're just separated out and processing on them is halted. Blars spends a lot of time looking at borderline messages to put back in non-spam into the queue, and catches most of them. Don Armstrong -- For those who understand, no explanation is necessary. For those who do not, none is possible. http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes: At least for the BTS, those messages are not discarded; they're just separated out and processing on them is halted. Blars spends a lot of time looking at borderline messages to put back in non-spam into the queue, and catches most of them. Not quite right, I look at the borderline messages that got passed through and delete them from bugs if they are spam. (and use them to train the filters either way.) I do look at the messages caught by crossassassin and reinject if needed, but that's many orders of magnatude less than those caught by spamassassin. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
On Mon, Jul 10, 2006 at 05:57:45PM +0200, Adrian von Bidder wrote: On Monday 10 July 2006 02:17, Matthew R. Dempsky wrote: On Sun, Jul 09, 2006 at 05:02:39PM -0700, Thomas Bushnell BSG wrote: Another problem is with hosts that do not accept a message from an MTA unless that MTA is willing to accept replies. This is a common spam prevention measure. It also prevents mail from setups that use different servers for inbound and outbound mail. Hmm. I've not seen this kind of sender verification. As I know it, the receiving MX connects the regular MX for the sender address to see if *that* is ready to receive mail. Works beautifully if outbound != inbound. In fact, broken servers which don't obey MX will _already_ fail: debian.org A 192.25.206.10 debian.org MX master.debian.org master.debian.org A 70.103.162.30 [~]$ telnet 192.25.206.10 25 Trying 192.25.206.10... Connected to 192.25.206.10. Escape character is '^]'. 220 gluck.debian.org ESMTP Exim 4.50 Mon, 10 Jul 2006 18:06:29 -0600 helo utumno.angband.pl 250 gluck.debian.org Hello acrc58.neoplus.adsl.tpnet.pl [83.11.4.58] mail from: [EMAIL PROTECTED] 250 OK rcpt to: [EMAIL PROTECTED] 550 relay not permitted MX records have been with us for 20 years, so I don't think a legitimate mailer can ever disobey one. Of course, illegitimate mailers often do. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
On Tue, Jul 11, 2006 at 02:39:00AM +0200, Adam Borowski wrote: In fact, broken servers which don't obey MX will _already_ fail: [ demonstration that debian.org doesn't accept RCPT TO @debian.org ] The issue isn't whether MTA's check against MX or A records, it's whether they check the IP that connected to them vs check MX records. Unless Debian's MTA's are setup to relay outbound mail via the debian.org IP, I don't see how this is relevant. (I make no claim which of the above setups are actually employed---I simply pointed out the connect-to-sender's-IP scheme TB mentioned is broken on its own, independant of greylisting.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
On Mon, 10 Jul 2006, Thomas Bushnell BSG wrote: martin f krafft [EMAIL PROTECTED] writes: That's better than not greylisting anyone. Nobody is trying to design the perfect spam filter. We just want to reduce spam on debian.org. A perfect spam filter is one which catches all spam and bounces no valid mail. Saying we aren't trying to be perfect is ambiguous about which imperfections you are willing to tolerate. I would like you to be explicit and clear about which valid mail you will be bouncing, rather than vague and inspecific. It was pretty clear for anyone actually reading the messages. The error is in the safe side, i.e. let stuff through the graylisting without delaying it. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
Quoting Thomas Bushnell BSG ([EMAIL PROTECTED]): martin f krafft [EMAIL PROTECTED] writes: This has been brought up. Basically I don't think people were opposed to it, but there was noone available to implement it. There were people opposed to it, in fact. What were their arguments? signature.asc Description: Digital signature
Re: greylisting on debian.org?
On Sun, 9 Jul 2006 08:14:20 +0200, Christian Perrier [EMAIL PROTECTED] wrote: Quoting Thomas Bushnell BSG ([EMAIL PROTECTED]): martin f krafft [EMAIL PROTECTED] writes: This has been brought up. Basically I don't think people were opposed to it, but there was noone available to implement it. There were people opposed to it, in fact. What were their arguments? For example, that greylisting puts significant load on systems that deliver mail to us, and that it is only a question of time before spam zombies retry. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: greylisting on debian.org?
also sprach Marc Haber [EMAIL PROTECTED] [2006.07.09.1430 +0200]: For example, that greylisting puts significant load on systems that deliver mail to us, I am sorry, I don't buy this argument at all. First, a 4xx is not significant load on any mailer unless you're running some piece of crap. Sure, when you reach the thousands, even postfix could break the occasional sweat, but which one server delivers thousands of messages to continuously new from/rcpt combinations -- because remember, greylisting caches. and that it is only a question of time before spam zombies retry. Yeah sure, which is why some of us wanted greylisting years ago, so the question of time would have been longer regardless. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system man kann die menschen nur von ihren eigenen meinungen überzeugen. -- charles tschopp signature.asc Description: Digital signature (GPG/PGP)
Re: greylisting on debian.org?
also sprach Thomas Bushnell BSG [EMAIL PROTECTED] [2006.07.09.0557 +0200]: There were people opposed to it, in fact. Sure, nobody expected it to be any different. This is Debian, after all. :) There will always be opposers. If we let our work be hindered by them, we're going to stagnate. Anyway, I'll be interested to hear a summary of their arguments, as Christian Perrier requested. I find it hard to imagine how properly configured greylisting should cause any problems. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system no micro$oft components were used in the creation or posting of this email. therefore, it is 100% virus free and does not use html by default (yuck!). signature.asc Description: Digital signature (GPG/PGP)
Re: greylisting on debian.org?
On 7/9/06, martin f krafft [EMAIL PROTECTED] wrote: also sprach Marc Haber [EMAIL PROTECTED] [2006.07.09.1430 +0200]: For example, that greylisting puts significant load on systems that deliver mail to us, I am sorry, I don't buy this argument at all. First, a 4xx is not significant load on any mailer unless you're running some piece of crap. Sure, when you reach the thousands, even postfix could break the occasional sweat, but which one server delivers thousands of messages to continuously new from/rcpt combinations -- because remember, greylisting caches. The point was about mailers sending mail to debian. If they receive a 4xx they have to queue the mail and retry later. It's cheap for debian, but expensive for everyone else. A far more reasonable solution is to only greylist mail with an unreasonably high spamassassin score. Normal mail I assume generally doesn't score high and is not susceptable to greylisting. Not that I mind, the amount of spam received via this mailing list is so marginal I can hardly imagine people worrying about it. Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
also sprach Martijn van Oosterhout [EMAIL PROTECTED] [2006.07.09.1548 +0200]: The point was about mailers sending mail to debian. If they receive a 4xx they have to queue the mail and retry later. It's cheap for debian, but expensive for everyone else. My point was: even 100 such queued mails are not expensive nowadays (unless your MTA is crap). If you have more than 100 queued mails due to greylisting on debian.org, you are either a big provider and can handle it, or a spammer. A far more reasonable solution is to only greylist mail with an unreasonably high spamassassin score. Normal mail I assume generally doesn't score high and is not susceptable to greylisting. Sure. Or greylist only when it's from a dynIP address. Not that I mind, the amount of spam received via this mailing list is so marginal I can hardly imagine people worrying about it. Your email address doesn't appear to be plastered all over Debian package control files, changelogs, the bug tracking system, and the mailing lists. Or at least not as much as some others. I get somewhere between 200-400 spam messages into my debian.org account per day. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system *** important disclaimer: by sending an email to any address, that will eventually cause it to end up in my inbox without much interaction, you are agreeing that: - i am by definition, the intended recipient - all information in the email is mine to do with as i see fit and make such financial profit, political mileage, or good joke as it lends itself to. in particular, i may quote it on usenet. - i may take the contents as representing the views of your company. - this overrides any disclaimer or statement of confidentiality that may be included on your message. signature.asc Description: Digital signature (GPG/PGP)
Re: greylisting on debian.org?
Martijn van Oosterhout [EMAIL PROTECTED] wrote: [...] The point was about mailers sending mail to debian. If they receive a 4xx they have to queue the mail and retry later. It's cheap for debian, but expensive for everyone else. A far more reasonable solution is to only greylist mail with an unreasonably high spamassassin score. Normal mail I assume generally doesn't score high and is not susceptable to greylisting. Greylisting after DATA sounds like a bad idea to me: 1. The bandwith has already been wasted. 2. The bandwith will be wasted again if the host retries 3. spamassassin is a performance hog, and you'll need to rerun it when the host retries. *If* you want to be picky about greylisting use something *cheap*, e.g. - greylist only hosts listed on a DNS blacklist. - Don't greylist on host/sender/receipient triples but check network/sender/receipient. And possibly combine this with *not* greylisting _any_ sender/receipient tuple iff $host already passed greylisting for another sender/receipient tuple. (We already know the host to do proper retries, no use in greylisting again.) Not that I mind, the amount of spam received via this mailing list is so marginal I can hardly imagine people worrying about it. We are not (only) talking about lists.d.o. primarly but the [EMAIL PROTECTED] addresses. /These/ gather loads of spam. cu andreas -- The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal vision of the emperor's, and its inclusion in this work does not constitute tacit approval by the author or the publisher for any such projects, howsoever undertaken.(c) Jasper Ffforde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
On Sun, 2006-07-09 at 16:14 +0200, martin f krafft wrote: A far more reasonable solution is to only greylist mail with an unreasonably high spamassassin score. Normal mail I assume generally doesn't score high and is not susceptable to greylisting. Sure. Or greylist only when it's from a dynIP address. Indeed, the current Alioth config only greylists those hosts that have some kind of 'problem', like no reverse DNS entry or are featured on some kind of RBL. Any decent mailserver is allowed right through. Any indecent mailserver is told to wait just a little bit, but is still allowed to send its mail. On Sun, 09 Jul 2006 14:30:33 +0200, Marc Haber wrote: and that it is only a question of time before spam zombies retry. That's not really relevant: if we can block spam now, we should do it now. Sure, we still need to be looking for new measures for when greylisting stops to work, but that doesn't exclude using it now in any way. Thijs signature.asc Description: This is a digitally signed message part
Re: greylisting on debian.org?
also sprach Thijs Kinkhorst [EMAIL PROTECTED] [2006.07.09.1622 +0200]: Indeed, the current Alioth config only greylists those hosts that have some kind of 'problem', like no reverse DNS entry or are featured on some kind of RBL. Any decent mailserver is allowed right through. Any indecent mailserver is told to wait just a little bit, but is still allowed to send its mail. postgrey, for instance, whitelists hosts that have 5 successful deliveries. In the presence of this option, you can just greylist *everything*. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system mumlutlitithtrhreeaadededd s siigngnatatuurere signature.asc Description: Digital signature (GPG/PGP)
