Re: Is gray-listing a one-shot anti-spam measure?
On Friday 03 December 2004 09.44, Russell Coker wrote: accept mail) on a spam-trap will be fine. The Postfix implementation of gray-listing postgrey does not send it's 450 code until after the rcpt to:, Just for completeness. Greylisting, as the term was defined in the original paper, always uses (client IP/envelope sender/envelope rcpt) triples to block on, so every greylisting implementation needs to wait until RCPT TO before it can return 450. postfix and postgrey can, additionally, return '450-if-accepted' which allows postgrey to be included early in the mail processing (so it adds all data point to its database), but if a mail would be rejected anyway by a later restriction (DNSBL, whatever), *that* rejection is the one seen by clients, and not the one from the greylisting. Note: I'm not really sure what the benefit is of this - if mail is rejected anyway on a DNSBL or whatever, there's not much point in adding the data to postgrey's database. But that's how postgrey works. (And - this to Stephen Frost, I believe - there is a patch to postgrey which I will include in the next version, and I believe which will also be included in the next upstream, to whitelist a client IP as soon as one greylisted email came through. So the load on legitimate mailservers will be even smaller.) greetings -- vbi [some people on this list have been cc:ing me in the past. Please don't.] -- Don't hit the keys so hard, it hurts. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ebtables and smp machines
I turned off the SMP stuff and it seems to work fine now. The machine no longer crashes when I reload the firewall rules. :) I think that I may have stumbled upon the limitations of interrupt requests. More specifically, SMP machines use an IRQ for each of the additional CPU. Adding to the interrupt problem, most common network cards have a very slow bus speed of only 33MHz. I think slow buses create latency. With normal server operations, interrupts are not an issue. With a bridge or firewall using two or three 33MHz cards, interrupts become an issue quickly. If you add multiple processors, you are just creating more interrupts. I found out the hard way that if two devices do an interrupt at the same time, a kernel panic results. In my case, the hardware is about 2-3 years old. Thus, the IRQ latency is high compared to newer hardware. I am not sure this would happen with newer hardware. However, I will be staying away from SMP machines for firewalls in the future. :) On 02/12/04 23:39 +0100, Arnt Karlsen wrote: On Thu, 2 Dec 2004 11:36:37 -0500, Theodore wrote in message [EMAIL PROTECTED]: Are there any dual processor firewalls out there ? I am just curious if most firewalls are single CPU machines. I put a SMP firewall in place yesterday and I think I may have mis-configured something. :) My problem is that I have been running ebtables as a kernel module in the 2.6.8 SMP kernel. The kernel is compiled for bridge support and bridging is enabled, which is very IRQ intensive. ..generally or just for smp bridges? The 700Mhz P3 dual processor machine is bridge for a T3(DS3) line to ..mine is a 1.2G single Duron, on a lazy 20MB/s line outside a ditto Duron router. No ebtables, though, and it's due for replacement by an one-box throttling router built on the same hardware. our network. Today, when I made a minor update to the firewall rules and ran the changes, it crashed. I got a kernel panics with 'fatal exception in interrupt'. So after rebooting, I figured can not safely change my firewall rules at the moment without rebooting the machine. ..my isp client's experience is, if you can do it in 15 seconds, nobody complains. ;-) I did a google search on 'fatal exception in interrupt' and I am alone. :( Could the SMP stuff in the kernel cause fatal exception errors in the kernel with applications that are very network IO intensive ? If you are not using a transparent bridge, here is definition: = Transparent bridges are becoming trendy because you can drop them on a network with out modifying the whole network topography. Most transparent bridges are uses as bandwidth shapers. But, transparent bridges can be used as firewalls and stealthy IDS systems. Similar to a router, a transparent bridge is a device that passes packets from one interface to another. Unlike a router, a transparent bridge does not need to have an IP address. Bridges works on layer 2 level of the TCP/IP stack. Layer 2 is the physical (hardware address) layer. For example, one MAC passes all the info it gets to the other MAC. Switches are new marketing term to define multiport bridges according to Radia Perlman. Perlman is the author of the 'spanning tree alogrithim' and a book calledInterconnections: bridges, routers, switches, and Internetworking Protocols. ..how much do you sell these for? ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- -- Ted Knab Chester, Maryland 21619 USA -- The perception of knowledge is an egotistical farce in which humans extrapolate from simplifications. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ebtables and smp machines
On Fri, 03 Dec 2004, Theodore Knab wrote: you are just creating more interrupts. I found out the hard way that if two devices do an interrupt at the same time, a kernel panic results. Looks like a kernel bug to me. Have you reported it yet? -- 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: Is gray-listing a one-shot anti-spam measure?
This one time, at band camp, Adrian 'Dagurashibanipal' von Bidder said: (And - this to Stephen Frost, I believe - there is a patch to postgrey which I will include in the next version, and I believe which will also be included in the next upstream, to whitelist a client IP as soon as one greylisted email came through. So the load on legitimate mailservers will be even smaller.) Is there a way to make the number of succesful retries before whitelisting configurable for postgrey? I use a different implementation of greylisting alltogether, so it doesn't really concern me too much, but it seems like a good idea. The reason for the request being that while it is quite possible for a zombie machine to accidentally resend the same mail from/rcpt to combination by accident on a second spam run, the odds of it sending 10 or 15 (or some number, depending on your circumstances, I guess) are vanishingly small. Only a mechanism with a real queue runner would get more than a few successes, and those are the ones that should be whitelisted. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpqLctW6P752.pgp Description: PGP signature
SCSI Raid Controller recommendations
Can anyone recommend a scsi raid controller for debian. I like the serveraid from IBM, but, when I last built a box with this, the monitoring software was only for Redhat and stuff. Fairly small box. Probably 3 18.6G in a RAID-5 is all I need. And, U160 would be fine, as would PCI-32. But, I would like to monitor the thing from /proc or something. Thanks, Rod -- Meddle not in the Affairs of Dragons for thou art crunchy, and good with catsup. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
