> i am confused as to why anyone would want to make a setup like > this, unless they were being shady. if you are going to be
Yeah, it does make a perfect man-in-the-middle attack kit I must admit, but no, that's not what I'm working on :-) > installing a transparent filter/proxy/etc., shouldn't you have > enough control over the networking environment to work around > the DHCP problems? Nope. This is to be used in a spamfilter, which can be pre-configured and given to someone to install at their site, with the only requirement being that they get the ethernet wires in the right sockets. (And even that I can probably work around with a bit of hackery) > it seems to me that working on the setup as it is currently > posited is a poor time investment. i would think harder about > how to change other things to work around this issue. unless, > of course, you were being shady ;). I've already thought hard about it. I got the spam filter part working over a year ago, but for the target users (high-schools, colleges, and universities plus any other govt-funded organisations in Texas - and anyone else that wants it) anything that is as complex to configure as the system currently is, is a non-starter. It has to be idiot proof and basically just an appliance like a commercial one. When you buy a linksys router for your home cable, you don't have to edit header files and recompile (or even just tweak params in a GUI) - you just plug it in and use it. That's what I need to make in order to get wide distribution of this thing. Hence the requirement for true transparency. If you don't have that (i.e. your MTA sees connections as coming from your spam filter appliance) then it will treat *all* incoming mail as either internal or external depending on where your appliance sits - rather than being able to determine internal addresses from external ones by looking at the incoming IP. For something like an FTP proxy or a transparent squid cache, this is not so much of an issue, but for email where you have to reject third-party spams while allowing local users to mail successfully, it's a requirement. (The other requirements are that it is MTA-agnostic, as the users could have any mailer and it will undoubtedly be one that they can't tweak because they have no source code; and that it does *not* store-and-forward, because that brings in a whole new set of data management issues that I'm not willing to handle. It has to pass connections through to the target MTA in real time.) Graham
