I have a question; I've run into this particular one myself before in trying to do transparent proxying. Let's say you have client X trying to connect to server Z, and you want to transparently proxy the TCP connection through Y, which happens to know the protocol Z speaks. In this instance, we're talking SMTP.
So X connects to what it thinks is Z, but is really Y. Now what I want to do is have Y open a connection on to Z, and transparently monitor the conversation, essentially "tee"ing it off to a SA process. If SA starts noticing spam, then fire off some exception. But as far as X knows, it's just talking to Z, and as far as Z knows, it's being talked to by X. I'm assuming nothing complicated like X and Z using strong authentication here. So, I understand how I can redirect any traffic from X on port 25 to Y. But how do I get Y to know the address that X intended to connect to in the first place, so it can open the onward connection? I suppose if Y was itself the router, then you could introspect the redirection tables or something, but is there some nicer way of handling things? C On Thu, 2002-04-04 at 00:40, Nigel Metheringham wrote: > On Thu, 2002-04-04 at 05:23, Olivier Nicole wrote: > > > BTW, a serious question. Do you any of you know if on a Cisco router > > it is possible to do transparent redirection for SMTP? > > Yes - you use policy routing. You need a box to accept the SMTP > sessions as the next hop - we (when I worked at Planet Online in the UK > - who host Freeserve which is a 3 million or so user ISP) used to do > this on all dial ups which were trying to connect to SMTP ports outside > our service addresses. The intercepting servers were linux boxes using > the transparent proxy code to pick up the forwarded sessions. We ran > the policy routing on the NAS (dial in) boxes - they had plenty of spare > CPU for that sort of thing - however running it on one of the other > router sets would have been technically possible if less scalable. > > Those boxes did traffic analysis - ie bursts of mail from an IP to more > than a particular threshold of targets were held for later release. > Adding SA into that pipeline would be possible, although we tended to be > more interested in message trends rather than per message scoring - one > highly spammy message would not be interesting, 100 spammy messages are > much more interesting, as were 100+ attempted mail bomb/abuse runs. > > Nigel. > -- > [ Nigel Metheringham [EMAIL PROTECTED] ] > [ - Comments in this message are my own and not ITO opinion/policy - ] > > _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk