Re: murphy in sbl.spamhaus.org
On Sa, 27.11.2004, 03:43, Stephen Gran wrote: ... I guess what I'm trying to say is, I understand your misgivings, beause people implementing most anything can manage to do it in a really stupid, painful and harmful way. That doesn't necessarily mean the idea is unsound. Greylisting is, itself, a one-trick pony. It will lose it's effectiveness whenever spammers get around to implementing queues on their zombie clients. OTOH, admin'ing an MTA these days is an arms race, and a new weapon can be a lot of help. I disagree here. If only a few of us would use greylisting no spammer would think about implementing queues. But if the majority would use it and they (the spammers) implement queues, it could end in a disaster for them. Or how would you call a queue with millions of messages waiting? And now for the warriors among us: At that point you could play with the time window perhaps using random shifts to at least knock them out. I'm using mimedefang as my 'aircraft-carrier' for such games. ;) You are able to react very fast with that tool if the situation would change! Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: murphy in sbl.spamhaus.org
On Sun, 28 Nov 2004, Christian Storch wrote: I disagree here. Well, unless there is nobody with a clue working for the spammers, and given how much money this scum have at their disposal, I find that unlikely... greylisting IS an one-shot tool. But if the majority would use it and they (the spammers) implement queues, it could end in a disaster for them. Or how would you call a queue with millions of messages waiting? Stupidity, since all messages are deterministically generated from a single template, and you don't even need to retain state to defeat normal greylisting. Just do two passes with about 2h between them. Heck, who cares if you deliver twice to those without greylisting? You're a spammer, remember? Of course, until enough spammers start using such software, greylisting remains useful. -- 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: murphy in sbl.spamhaus.org
On Friday 26 November 2004 03.34, Stephen Frost wrote: * Adrian 'Dagurashibanipal' von Bidder ([EMAIL PROTECTED]) wrote: plug And, of course, postgrey as the very first line of defense. /plug Coupled with the usual checking on HELO (blocking 'localhost' HELOs and my own IP does wonders!), SMTP protocol conformance (pipelining), sender (envelope) address checking. Things which increase the load on the remote mail servers are *bad*. That would include responding with temporary errors unnecessairly and adding unnecessary delays in communication. pipelining by itself isn't necessairly terrible- adding things like 2 minute delays is bad though. I'm happy to queue my outgoing email if the remote end uses greylisting, as I expect the remote site to queue my incoming mail with my greylisting. Add to the the fact that amongst the mail senders big enough so that the queue size matters are probably many of those ISPs with badly policed (DSL/cable) network, operating the spam zombies which cause me to use greylisting in the first place... About pipelining: what postfix does is enforce proper use of pipelining: the sender may only start pipelining requests when it has actually seen that postfix does support pipelining. Regular mail servers never notice this, but some stupid spammers just push the request out without waiting for responses at all - these are rejected. -- vbi -- TODO: apt-get install signify pgpfp7vTpvIYg.pgp Description: PGP signature
Re: murphy in sbl.spamhaus.org
On Fr, 26.11.2004, 03:34, Stephen Frost wrote: * Adrian 'Dagurashibanipal' von Bidder ([EMAIL PROTECTED]) wrote: plug And, of course, postgrey as the very first line of defense. /plug Coupled with the usual checking on HELO (blocking 'localhost' HELOs and my own IP does wonders!), SMTP protocol conformance (pipelining), sender (envelope) address checking. Things which increase the load on the remote mail servers are *bad*. That would include responding with temporary errors unnecessairly and adding unnecessary delays in communication. pipelining by itself isn't necessairly terrible- adding things like 2 minute delays is bad though. What about greylisting depending on results of e.g. SA? Only above a limit of scores from SA greylisting would be become active. Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: murphy in sbl.spamhaus.org
* Christian Storch: Things which increase the load on the remote mail servers are *bad*. That would include responding with temporary errors unnecessairly and adding unnecessary delays in communication. pipelining by itself isn't necessairly terrible- adding things like 2 minute delays is bad though. What about greylisting depending on results of e.g. SA? Only above a limit of scores from SA greylisting would be become active. This is very impolite because it requires that the entire message is transferred at least twice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: murphy in sbl.spamhaus.org
On Fri, Nov 26, 2004 at 10:04:38AM +0100, Christian Storch wrote: What about greylisting depending on results of e.g. SA? Only above a limit of scores from SA greylisting would be become active. Use as many RBLs instead of the SA score, but use them not for blocking but for activating greylisting, teergrubing and non-pipelining/synch-checks. All these actions effectivly block ratware but by using the RBLs you can avoid hitting the delays on real MTAs. Regards, David -- * Customer: My palmtop won't turn on. * Tech Support: Did the battery run out, maybe? * Customer: No, it doesn't use batteries. It's Windows powered. -- http://www.rinkworks.com/stupid/cs_power.shtml -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: murphy in sbl.spamhaus.org
On Fri, Nov 26, 2004 at 10:57:31AM +0100, Florian Weimer wrote: * Christian Storch: Things which increase the load on the remote mail servers are *bad*. That would include responding with temporary errors unnecessairly and adding unnecessary delays in communication. pipelining by itself isn't necessairly terrible- adding things like 2 minute delays is bad though. What about greylisting depending on results of e.g. SA? Only above a limit of scores from SA greylisting would be become active. This is very impolite because it requires that the entire message is transferred at least twice. I thought greylisting closes the smtp connection with a temporary failure immediately to unfamiliar routers. Then they can transmit the message on a second attempt, but since spam relays don't queue, they won't try again. // George -- George Georgalis, systems architect, administrator Linux BSD IXOYE http://galis.org/george/ cell:646-331-2027 mailto:[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: murphy in sbl.spamhaus.org
George Georgalis schrieb/wrote/a écrit/escribió: On Fri, Nov 26, 2004 at 10:57:31AM +0100, Florian Weimer wrote: * Christian Storch: What about greylisting depending on results of e.g. SA? Only above a limit of scores from SA greylisting would be become active. This is very impolite because it requires that the entire message is transferred at least twice. I thought greylisting closes the smtp connection with a temporary failure immediately to unfamiliar routers. Then they can transmit the message on a second attempt, but since spam relays don't queue, they won't try again. Chrisitan proposed greylisting based on SA scores - that requires the messages to be transmitted before rejecting them the first time (with an temporary error), and then to be transmitted again. It's a matter of time til the spammers begin to implement queues in their spamware (on some infected Windows zombies). Greylisting is obsolete then. pgpPPnWcUtG40.pgp Description: PGP signature
Re: murphy in sbl.spamhaus.org
* Adrian 'Dagurashibanipal' von Bidder ([EMAIL PROTECTED]) wrote: On Friday 26 November 2004 03.34, Stephen Frost wrote: * Adrian 'Dagurashibanipal' von Bidder ([EMAIL PROTECTED]) wrote: plug And, of course, postgrey as the very first line of defense. /plug Coupled with the usual checking on HELO (blocking 'localhost' HELOs and my own IP does wonders!), SMTP protocol conformance (pipelining), sender (envelope) address checking. Things which increase the load on the remote mail servers are *bad*. That would include responding with temporary errors unnecessairly and adding unnecessary delays in communication. pipelining by itself isn't necessairly terrible- adding things like 2 minute delays is bad though. I'm happy to queue my outgoing email if the remote end uses greylisting, as I expect the remote site to queue my incoming mail with my greylisting. That's nice, obviously you don't handle much mail. Add to the the fact that amongst the mail senders big enough so that the queue size matters are probably many of those ISPs with badly policed (DSL/cable) network, operating the spam zombies which cause me to use greylisting in the first place... That's a *terrible* and just plain stupid assumption. Queue size makes a difference to me, both on a machine I run for some friends and in the part-time work that I do for a small ISP (which, hey, doesn't even provide DSL or cable modem service). Queue size matters to universities who are draconian about their policing, and I'm sure it matters to the 'good' ISPs too. Let me tell you that if you use that greylisting crap against the servers that *I* run your mail will get dumped into a secondary queue which is processed at a much slower rate. I won't slow things down for others because of a few idiots who can't figure out how to configure their mail servers. About pipelining: what postfix does is enforce proper use of pipelining: the sender may only start pipelining requests when it has actually seen that postfix does support pipelining. Regular mail servers never notice this, but some stupid spammers just push the request out without waiting for responses at all - these are rejected. That'd be why I said that pipelineing isn't really an issue but adding in random unnecessary delays is bad, which is something that's been advocated in a number of places and ends up increasing the load on my mail servers. Stephen signature.asc Description: Digital signature
Re: murphy in sbl.spamhaus.org
This one time, at band camp, Stephen Frost said: * Adrian 'Dagurashibanipal' von Bidder ([EMAIL PROTECTED]) wrote: On Friday 26 November 2004 03.34, Stephen Frost wrote: * Adrian 'Dagurashibanipal' von Bidder ([EMAIL PROTECTED]) wrote: And, of course, postgrey as the very first line of defense. Things which increase the load on the remote mail servers are *bad*. That would include responding with temporary errors unnecessairly and adding unnecessary delays in communication. Things which slow down my MTA are equally bad. Add to the the fact that amongst the mail senders big enough so that the queue size matters are probably many of those ISPs with badly policed (DSL/cable) network, operating the spam zombies which cause me to use greylisting in the first place... That's a *terrible* and just plain stupid assumption. Queue size makes a difference to me, both on a machine I run for some friends and in the part-time work that I do for a small ISP (which, hey, doesn't even provide DSL or cable modem service). Queue size matters to universities who are draconian about their policing, and I'm sure it matters to the 'good' ISPs too. Of course queue size matters. I don't think that's what he's saying though. He's saying that those organizations that are that big are also a source of a lot fo the spam flying about. Not %100 true, but there is some correlation. A sensible greylisting scheme will auto-whitelist a sending IP after so many whitelisted entries (successful retries) - the only point of greylisting is that we know that the remote end won't retry in most cases. Once it's been shown that they do retry, why bother greylisting them anymore? If you do implement this sort of scheme, any extra load you place on the remote end is transient, and will go away shortly, never to be repeated. It's not really a large price to pay for a pretty effective tool. Let me tell you that if you use that greylisting crap against the servers that *I* run your mail will get dumped into a secondary queue which is processed at a much slower rate. I won't slow things down for others because of a few idiots who can't figure out how to configure their mail servers. Take a deep breath, and count to ten. I handle some fairly large mail installations at work, and greylisting has been of tremendous benefit to us. If it's done sensibly (as above) it does transiently increase load on remote MTA's for a couple of days until the common sending IPs have been whitelisted, and then it settles back down. About pipelining: what postfix does is enforce proper use of pipelining: the sender may only start pipelining requests when it has actually seen that postfix does support pipelining. Regular mail servers never notice this, but some stupid spammers just push the request out without waiting for responses at all - these are rejected. That'd be why I said that pipelineing isn't really an issue but adding in random unnecessary delays is bad, which is something that's been advocated in a number of places and ends up increasing the load on my mail servers. Introducing delays is usually only advocated for fairly egregious and obvious spam-like tactics (HELO as my IP/hostname, etc). If you're doing that, then you deserve to be a little overloaded. If you're running a reasonably sensible MTA, then you should never trip those kinds of checks. If people are delaying a sensible MTA, then they deserve to be LART'ed for doing something silly, but the practice itself isn't unreasonable. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgprmOgfdY15j.pgp Description: PGP signature
Re: murphy in sbl.spamhaus.org
* Stephen Gran ([EMAIL PROTECTED]) wrote: This one time, at band camp, Stephen Frost said: That's a *terrible* and just plain stupid assumption. Queue size makes a difference to me, both on a machine I run for some friends and in the part-time work that I do for a small ISP (which, hey, doesn't even provide DSL or cable modem service). Queue size matters to universities who are draconian about their policing, and I'm sure it matters to the 'good' ISPs too. Of course queue size matters. I don't think that's what he's saying though. He's saying that those organizations that are that big are also a source of a lot fo the spam flying about. Not %100 true, but there is some correlation. The problem is that it's probably not even 20% true. There really isn't any correlation. There are lots of good ISPs and other service providers who are big enough that queue size matters to them but which aren't sources of spam. A sensible greylisting scheme will auto-whitelist a sending IP after so many whitelisted entries (successful retries) - the only point of greylisting is that we know that the remote end won't retry in most cases. Once it's been shown that they do retry, why bother greylisting them anymore? If you do implement this sort of scheme, any extra load you place on the remote end is transient, and will go away shortly, never to be repeated. It's not really a large price to pay for a pretty effective tool. A system which didn't increase the load on the remote mail servers would be better. Having whitelisting w/ greylisting is better but I still don't like it. What about secondary MX's? How is the greylist going to work with those, a seperate list, or will they be unified? Will it correctly pick up on and whitelist a server that goes for a secondary MX after getting a temporary error at the first? Of course, I've run into people who have had secondary MX's configured incorrectly to the point where it drops mail, or refuses to forward the message on, etc. You can understand that I'd have my doubts about the ability of people to implement a scheme such as this. Let me tell you that if you use that greylisting crap against the servers that *I* run your mail will get dumped into a secondary queue which is processed at a much slower rate. I won't slow things down for others because of a few idiots who can't figure out how to configure their mail servers. Take a deep breath, and count to ten. Hey, it's how my mail servers are configured- if you're too slow to respond or the mail doesn't leave the main queue fast enough for whatever reason it'll get dumped into a slower queue that's run less often. It wasn't a threat. :) I handle some fairly large mail installations at work, and greylisting has been of tremendous benefit to us. If it's done sensibly (as above) it does transiently increase load on remote MTA's for a couple of days until the common sending IPs have been whitelisted, and then it settles back down. Perhaps it would have made sense to look at your logs and whitelist those hosts ahead of time. Sounds like you know what you're doing- that wouldn't be hard. About pipelining: what postfix does is enforce proper use of pipelining: the sender may only start pipelining requests when it has actually seen that postfix does support pipelining. Regular mail servers never notice this, but some stupid spammers just push the request out without waiting for responses at all - these are rejected. That'd be why I said that pipelineing isn't really an issue but adding in random unnecessary delays is bad, which is something that's been advocated in a number of places and ends up increasing the load on my mail servers. Introducing delays is usually only advocated for fairly egregious and obvious spam-like tactics (HELO as my IP/hostname, etc). If you're doing that, then you deserve to be a little overloaded. If you're running a reasonably sensible MTA, then you should never trip those kinds of checks. If people are delaying a sensible MTA, then they deserve to be LART'ed for doing something silly, but the practice itself isn't unreasonable. Unfortunately I had someone complain at me that my mail servers kept going to their secondary MX, turns out it was because he had a forced 2 minute delay before responding to HELO and my mail server wasn't waiting around that long. He had it because some website (the mailer was exim, iirc) was advocating it and encouraging people to do it for all incoming connections. The problem is that some people *are* silly, or stupid, and schemes like this often end up misused, misconfigured, and implemented wrong. That's why I don't like them. Stephen signature.asc Description: Digital signature
Re: murphy in sbl.spamhaus.org
This one time, at band camp, Stephen Frost said: * Stephen Gran ([EMAIL PROTECTED]) wrote: A sensible greylisting scheme will auto-whitelist a sending IP after so many whitelisted entries (successful retries) - the only point of greylisting is that we know that the remote end won't retry in most cases. Once it's been shown that they do retry, why bother greylisting them anymore? If you do implement this sort of scheme, any extra load you place on the remote end is transient, and will go away shortly, never to be repeated. It's not really a large price to pay for a pretty effective tool. A system which didn't increase the load on the remote mail servers would be better. Having whitelisting w/ greylisting is better but I still don't like it. What about secondary MX's? How is the greylist going to work with those, a seperate list, or will they be unified? Will it correctly pick up on and whitelist a server that goes for a secondary MX after getting a temporary error at the first? Of course, I've run into people who have had secondary MX's configured incorrectly to the point where it drops mail, or refuses to forward the message on, etc. You can understand that I'd have my doubts about the ability of people to implement a scheme such as this. I wouldn't really advocate using secondary MX's these days, and certainly not ones not ones not under your control. If you need redundancy, I'd use a load balancer with a server farm behind it. They can all share access to the same database for greylisting purposes that way, and you get better failover. Secondary MX's tend to just be spam targets and rarely serve any real use. If you must have a seperate secondary MX (you don't have the hardware resources, or whatever) I would really strongly advocate that you find a way to get a list of valid users from the primary onto the secondary - all the bounces when the primary comes back up and spam starts failing are part of the problem. I handle some fairly large mail installations at work, and greylisting has been of tremendous benefit to us. If it's done sensibly (as above) it does transiently increase load on remote MTA's for a couple of days until the common sending IPs have been whitelisted, and then it settles back down. Perhaps it would have made sense to look at your logs and whitelist those hosts ahead of time. Sounds like you know what you're doing- that wouldn't be hard. We did pre-whitelist about 50 or so known good hosts, determined the old-fashioned way, with grep, sed, sort, and uniq -c. As always, we missed several, but they got added automagically. This is one of those situations where it is hard to always know programatically what's going to come up, and so that's where the importance of an auto whitelister come in. For instance, we had almost no hits from Southwest airlines MX before the switchover, and then they opened a hub in Philadelphia. We started getting a ton of emails from them, since they're so cheap - they're the US answer to Ryan air. They also happen to use VERP for their notification emails, so _all_ of their mail was delayed until the auto whitelister added them after a day or two. Introducing delays is usually only advocated for fairly egregious and obvious spam-like tactics (HELO as my IP/hostname, etc). If you're doing that, then you deserve to be a little overloaded. If you're running a reasonably sensible MTA, then you should never trip those kinds of checks. If people are delaying a sensible MTA, then they deserve to be LART'ed for doing something silly, but the practice itself isn't unreasonable. Unfortunately I had someone complain at me that my mail servers kept going to their secondary MX, turns out it was because he had a forced 2 minute delay before responding to HELO and my mail server wasn't waiting around that long. He had it because some website (the mailer was exim, iirc) was advocating it and encouraging people to do it for all incoming connections. That is just stupid, and he probably shouldn't be bothering to try and run a mail server, much less complain that people are hitting his secondary. There are other good reasons for introducing delays, and they are effective, but the above idea is just retarded. The problem is that some people *are* silly, or stupid, and schemes like this often end up misused, misconfigured, and implemented wrong. That's why I don't like them. I can't disagree there. I guess what I'm trying to say is, I understand your misgivings, beause people implementing most anything can manage to do it in a really stupid, painful and harmful way. That doesn't necessarily mean the idea is unsound. Greylisting is, itself, a one-trick pony. It will lose it's effectiveness whenever spammers get around to implementing queues on their zombie clients. OTOH, admin'ing an MTA these days is an arms race, and a new weapon can be a lot of help. Take care, --
Re: murphy in sbl.spamhaus.org
Quoting Robert Vangel [EMAIL PROTECTED]: I have been seeing a few (quite a few.. due to the amount of lists I am subscribed to) messages in my postfix log's about murphy.debian.org[146.82.138.6] being blocked due to being present in spamhaus.org's SBL list. Now it is in Spamcop's list: http://www.spamcop.net/w3m?action=checkblockip=146.82.138.6 I have removed bl.spamcop.net from our RBLs. Alas Spamcop does not publish a contact mail address to tell them they have done something Stoopid(tm). BTW, outgoing.securityfocus.com and netsys.com are in Spamcop's list, too. netsys.com is running some very popular mailing lists like Full Disclosure and Sun Manager's. Security Focus is obvious. Since Spamcop does not talk to lowly insignificant users, can the listmaster please get the weenies at Spamcop to whitelist murphy? rantThis is the fourth RBL I had to remove because all those SFBs are too Stoopid(tm) to whitelist important mail servers./rant Lupe Christoph -- | [EMAIL PROTECTED] | http://www.lupe-christoph.de/ | | ... putting a mail server on the Internet without filtering is like | | covering yourself with barbecue sauce and breaking into the Charity| | Home for Badgers with Rabies.Michael Lucas | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: murphy in sbl.spamhaus.org
On Thursday 25 November 2004 10.50, Lupe Christoph wrote: Now it is in Spamcop's list: http://www.spamcop.net/w3m?action=checkblockip=146.82.138.6 spamcop does explicitly not recommend using their RBL for blocking - they know why. That's the downside of a fully automated system. Every mailserver with more than a few 1000 users are bound to end up on spamcop again and again, either because spamcop's header parsing is broken (it is, sometimes), or because some users are reporting 'spam' that isn't. rantThis is the fourth RBL I had to remove because all those SFBs are too Stoopid(tm) to whitelist important mail servers./rant Happy with - sbl-xbl.spamhaus.org - list.dsbl.org - relays.ordb.org and until recently SPEWS (dropped it because it didn't catch much that wasn't caught by the others already.) I used to use the country based blackholes list for cn and tw for a while, but I don't see the need anymore. plug And, of course, postgrey as the very first line of defense. /plug Coupled with the usual checking on HELO (blocking 'localhost' HELOs and my own IP does wonders!), SMTP protocol conformance (pipelining), sender (envelope) address checking. -- vbi -- TODO: apt-get install signify pgpv05HFyKDlf.pgp Description: PGP signature
Re: murphy in sbl.spamhaus.org
On Thu, Nov 25, 2004 at 10:50:19AM +0100, Lupe Christoph wrote: I have removed bl.spamcop.net from our RBLs. Alas Spamcop does not publish a contact mail address to tell them they have done something Stoopid(tm). [snip] Since Spamcop does not talk to lowly insignificant users, can the listmaster please get the weenies at Spamcop to whitelist murphy? I think the first response (drop spamcop) is the more effective approach. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: murphy in sbl.spamhaus.org
* Adrian 'Dagurashibanipal' von Bidder ([EMAIL PROTECTED]) wrote: plug And, of course, postgrey as the very first line of defense. /plug Coupled with the usual checking on HELO (blocking 'localhost' HELOs and my own IP does wonders!), SMTP protocol conformance (pipelining), sender (envelope) address checking. Things which increase the load on the remote mail servers are *bad*. That would include responding with temporary errors unnecessairly and adding unnecessary delays in communication. pipelining by itself isn't necessairly terrible- adding things like 2 minute delays is bad though. Stephen signature.asc Description: Digital signature
murphy in sbl.spamhaus.org
I have been seeing a few (quite a few.. due to the amount of lists I am subscribed to) messages in my postfix log's about murphy.debian.org[146.82.138.6] being blocked due to being present in spamhaus.org's SBL list. Going to spamhaus and entering 146.82.138.6 shows that it isn't in fact in the list, and I am quite confused. Has anyone else been getting this? Is there something odd going on my end... This email is also a test to see if I get it back through to myself. smime.p7s Description: S/MIME Cryptographic Signature
