Re: [Mimedefang] Back into the loop...
Philip Prindeville wrote: Only ratware seems to like to open multiple connections in parallel. qmail does this, and short of completely redesigning it (and more or less making it not qmail), I don't think there's a fix. It's a real pain, but ratware is not the only software doing this by a long shot. :( -kgd ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Back into the loop...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 24 Oct 2006, Philip Prindeville wrote: from 192.150.1.3, then it will reject that the session... with a 5xx message... and will also blacklist incoming connections from that Add it to access_db, however, you cannot quadruple it, as you won't see it in Mimedefang anymore. Only ratware seems to like to open multiple connections in parallel. Oh, could someone please tell me, how to configure postfix to NOT open one connection per message? Another department bomb our sendmail on a regular base, when they flush their message queue. The downside of this method is that the mimedefang-filter file would have to contain all (or almost all) possible tests, and have an engine But that is exactly the reason to have a fully tweakable perl script. So we'd have to decide on a standard format for the XML test scripting, and a standard calling convention for the methods embedded in mimedefang-filter. There were a thread about to modulize the filter, maybe you should get in touch with the advocates of the idea. One other thing... about a year ago, I asked about adding a sort of IP CIDR based set of rules to Mimedefang, and was told to use rDNS instead of CIDR addresses (or alternatively, country codes) to block certain parties permanently. There had been some posts about it, but would do you ask about inb detail? http://www.mail-archive.com/search?l=mimedefang%40lists.roaringpenguin.comq=cidr http://www.mail-archive.com/search?l=mimedefang%40lists.roaringpenguin.comq=geo Bye, - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iQEVAwUBRT8+JegJIbZtwg6XAQLfqgf9FWVxLEAPx0Fnj3JrZ4NK/kLl16aQZ3KA qREQPeoP+nq4ZBH5OSPWnO6V+cqnjIdSzkdtRG+x2OdtpsFvjRj7yhXHEd/Y43GO LIu+sy3uBDIByGJZdvW8FJzNQTIXZKE8vJ2+Dy5lfBQh/hd9eRqv81ybSVsDiQMe Gau9BufLfD+CSlJJqwefMMY/lonGhPaW/dD810tqUob0FWYigAFGHCpsNuNBrW7+ byNZBH15JgUGju1sg5w71zCE+KOITRTFPrFlZgey+bxImsrpJdq+F/TmBNEeiirN mkhfHJFrhvVj3BI5SZyoGhHK5JXn++urrOOMm/UjVlzs/twQgByu8A== =50Ag -END PGP SIGNATURE- ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Back into the loop...
--On Tuesday, October 24, 2006 6:28 PM -0600 Philip Prindeville [EMAIL PROTECTED] wrote: It's easier to share XML fragments and parameters (where the parameters change more often than the actual logic that implements the test). So we could make the scripting more stable, and the fine tuning easier to ship around and share. There are Perl modules to read XML, so you could create some standard filters that are parameterized by XML and that drop into MD. It's easier to see the applicability given some examples. ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Back into the loop...
Hi. Been off working on other projects and hence haven't spent a lot of attention to this list the last few months (sniff!), but I have more free time lately (largely due to being made redundant, woo-hoo!). Anyway, if these questions have been asked before, sorry. A few issues/questions I was thinking of... First, I want to add some sort of throttling to MdF so that if the filter rejects a connection during the HELO or RCPT TO or MAIL FROM stages, that it will (for the duration of a throttling period) reject incoming connections during the CONNECT stage, and indeed if new connections come in during that period, it will double or quadruple that window. For instance, if it sees HELO localhost.localdomain from 192.150.1.3, then it will reject that the session... with a 5xx message... and will also blacklist incoming connections from that site for the next 4 hours... If another connection comes in from that address during that 4 hour period, maybe double or quadruple the wait period. One other thing I wasn't sure about doing, was adding simultaneity locking as well. That is, blacklisting additional connections from the same site during the duration of a connection. Most legitimate MTA's will open a single connection per site, and then spool multiple messages over a single connection. Only ratware seems to like to open multiple connections in parallel. On a note related to the blacklisting above... I want to persistently store the tuple of (ip-address, time-of-blacklist-expiration) into a database... and I was wondering what sort of Perl tied hash would work well that handles locking and concurrency transparently. Anyone prefer one Perl module over another? Let's see, what else? I've been wondering about coming up with a standardized format for tests, and a way to express tests in XML... and then rather than configuring the mimedefang-filter file, you just configure the XML script as a series of tests to run (I was working on a commercial H.323 gatekeeper implementation that does call admission control this way, and it seemed pretty powerful). The downside of this method is that the mimedefang-filter file would have to contain all (or almost all) possible tests, and have an engine that loaded and parsed the XML script, calling out the appropriate methods to implement that tests... tests would return one of three possible values, ACCEPT (without further processing), REJECT (without further processing), or CONTINUE (test inconclusive, proceed to next test). So we'd have to decide on a standard format for the XML test scripting, and a standard calling convention for the methods embedded in mimedefang-filter. One other thing... about a year ago, I asked about adding a sort of IP CIDR based set of rules to Mimedefang, and was told to use rDNS instead of CIDR addresses (or alternatively, country codes) to block certain parties permanently. At the time, I grudgingly accepted this bit of common wisdom, but a year later, I've noticed that this isn't a complete solution. A lot of providers don't provide rDNS for their clients... or else the clients run their own rDNS, and it's either flaky or there are way too many domains to blacklist them all... and while the country- code test also works nicely most of the time, there are instances where the data is missing or wrong (a lot of entries say eu that aren't, for example). The bottom line is that rDNS and country-codes alone aren't sufficient. There's still a place for CIDR-based tests. Thanks, -Philip ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Back into the loop...
Philip Prindeville wrote: HELO localhost.localdomain from 192.150.1.3, then it will reject that the session... with a 5xx message... and will also blacklist incoming connections from that site for the next 4 hours... If another connection comes in from that address during that 4 hour period, maybe double or quadruple the wait period. I do a similar thing, but I feed data into a Perl script that plays with my iptables rules. Obviously, to fiddle with iptables rules requires root privileges, hence the separate script. One other thing I wasn't sure about doing, was adding simultaneity locking as well. That is, blacklisting additional connections from the same site during the duration of a connection. Most legitimate MTA's will open a single connection per site, and then spool multiple messages over a single connection. Sendmail 8.13 can do all of that (and more) with its conncontrol and ratecontrol features. [...] I've been wondering about coming up with a standardized format for tests, This is explicitly *not* a goal of MIMEDefang. My belief is that in order to combat current and future e-mail threats, you need a proper programming language, and Perl is about as good as any. In my opinion, going to something like XML would be a massive step backward. [... rest elided - I have no comments on it ...] Regards, David. ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Back into the loop...
David F. Skoll wrote: Philip Prindeville wrote: HELO localhost.localdomain from 192.150.1.3, then it will reject that the session... with a 5xx message... and will also blacklist incoming connections from that site for the next 4 hours... If another connection comes in from that address during that 4 hour period, maybe double or quadruple the wait period. I do a similar thing, but I feed data into a Perl script that plays with my iptables rules. Obviously, to fiddle with iptables rules requires root privileges, hence the separate script. I thought about this too... It would be nice to have a Perl module that allows modifying the IPtable on the fly... Of course, that's Linux specific... Similarly, you could use dynamic ACL's on a Cisco firewall if that's what you're sitting behind... One other thing I wasn't sure about doing, was adding simultaneity locking as well. That is, blacklisting additional connections from the same site during the duration of a connection. Most legitimate MTA's will open a single connection per site, and then spool multiple messages over a single connection. Sendmail 8.13 can do all of that (and more) with its conncontrol and ratecontrol features. [...] I just read the README in /usr/share/sendmail-cf/ and couldn't tell the difference between one knob and the other. I've been wondering about coming up with a standardized format for tests, This is explicitly *not* a goal of MIMEDefang. My belief is that in order to combat current and future e-mail threats, you need a proper programming language, and Perl is about as good as any. In my opinion, going to something like XML would be a massive step backward. It's easier to share XML fragments and parameters (where the parameters change more often than the actual logic that implements the test). So we could make the scripting more stable, and the fine tuning easier to ship around and share. [... rest elided - I have no comments on it ...] Any preferences on a favourite lockable/concurrent database (hash) module? -Philip Regards, David. ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Back into the loop...
Philip Prindeville wrote: Sendmail 8.13 can do all of that (and more) with its conncontrol and ratecontrol features. I just read the README in /usr/share/sendmail-cf/ and couldn't tell the difference between one knob and the other. conncontrol limits the maximum number of concurrent SMTP connections from an IP address or net block. ratecontrol limits the maximum rate at which new connections can be created. [...] It's easier to share XML fragments and parameters (where the parameters change more often than the actual logic that implements the test). So we could make the scripting more stable, and the fine tuning easier to ship around and share. Possibly. However, I'm not sure that we can come up with a standard framework that will be generally useful, yet still flexible enough. We've been working on our (commercial) CanIt product for 4+ years and are still doing a fair bit of tweaking to the framework. Any preferences on a favourite lockable/concurrent database (hash) module? Our commercial product uses PostgreSQL (which I really like... www.roaringpenguin.com is running Drupal back-ended on PostgreSQL.) For Bayes data, we use Berkeley DB, but we avoid locking by journalling Bayes training and then running the journal against a database.new.db file. We then atomically rename database.new.db to database.db. As long as we guarantee there won't be more than one writer (which we do), no locking is required. Regards, David. ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
