On Wed, Apr 16, 2003 at 12:27:25PM -0700, nate wrote: | Derrick dman Hudson said: | | > Trivial. (except, as someone else said, for the last Received: header | > which is added by your own machine. No one else has control over how your | > machine reports info) | | just a minor point but it came to mind so might as well mention it.. It's a good point to make. | the last Recieved: header can be incorrect(may be difficult to spoof | but it may not be accurate). | | first situation, a few years ago I was having trouble with port forwarding | on one of my firewalls for smtp, so I reverted to rinetd instead(a lovely | app, though I've only ever seen it on debian). For SMTP, the mail server | recorded every inbound message as comming from the firewall rather then | the remote system I guess due to how rinetd forwards. I have this situation right now too. I moved on campus a few weeks ago, then found out they block port 25. So, using iptables, I made the "router" at my parents' house NAT port 25 incoming to another port on my "real" machine. At the TCP/IP level, every connection _is_ from the router, though I know the connection really originated elsewhere. It also means, as you indicated, that any IP-based UCE controls don't work :-). A slightly better solution, I think, would be to get pkcipe working so that the original packets can simply be routed as-is through the tunnel. I haven't had time to experiment fully with setting up the tunnel. -D -- A)bort, R)etry, B)ang it with a large hammer http://dman.ddts.net/~dman/
Attachment:
pgpCGnU94tDId.pgp
Description: PGP signature