Proxsmtp (Email capture package like imspector) {$200}
-
Similar to imspector but for email. It uses a BSD type license. Allows the monitoring of all smtp email traffic. Would like to have a gui which would allow me to capture in a similar fashion to imspector.
http://memberwebs.com/stef/software/proxsmtp/
-
The biggest issue I see with this software is the requirement for ipfw for transparent mode. I'm betting it's not worth the asking price to you without that.
–Bill
-
Looks like a standard NAT port redirect, doesn't seem like it would require ipfw, though they used it and iptables as an example.
It probably just needs a NAT rule like:
LAN TCP 25 (SMTP) 127.0.0.1 / (ext.: any) 10025
Sort of like what squid and the FTP proxy do behind the scenes.
-
The biggest issue I see with this software is the requirement for ipfw for transparent modeThe biggest issue I see with this software is the requirement for ipfw for transparent mode
Sorry but I don not understand what you mean by that. I don't know what ipfw is and how it relates to this being possible or not. I will look it up.
Thanks
-
Looks like a standard NAT port redirect, doesn't seem like it would require ipfw, though they used it and iptables as an example.
It probably just needs a NAT rule like:
LAN TCP 25 (SMTP) 127.0.0.1 / (ext.: any) 10025
Sort of like what squid and the FTP proxy do behind the scenes.
In transparent mode the daemon needs to know where the connection was intended to go to forward it on. The way it does that on FreeBSD is to use a socket option that as far as I can tell IPFW (which is built into FreeBSD by default) exposes. PF has an ioctl that daemons can use to access this data - proxsmtp does not use that ioctl, therefore one of three options are a requirement for this bounty.
-
1. Transparent mode is not a requirement
-
2. IPFW is used somehow - I'm positive there will be conflicts with other stuff using this method
-
3. The source code to the daemon will need to be updated to support PF - I've looked at the code, it's pretty simple, but I don't fully understand what needs to be done to implement PF support (and it really needs to be maintained by the author anyway)
If nobody has snagged this by the hackathon, I will consider spending more time on it then.
–Bill
-
-
Its just a proxy it is not intended to be run without the routing layer running!
It behaves the same as spamd AFAIK just happens to provide some services that the poster sees as better ones. -
Some companies I work for have made the request to capture all email traffic passing through the firewall. This was the only thing I could find that would allow me to capture and archive for further inspection. Mostly its to make sure that no one is sending out confidential information.
-
In transparent mode the daemon needs to know where the connection was intended to go to forward it on. The way it does that on FreeBSD is to use a socket option that as far as I can tell IPFW (which is built into FreeBSD by default) exposes. PF has an ioctl that daemons can use to access this data - proxsmtp does not use that ioctl, therefore one of three options are a requirement for this bounty.
-
1. Transparent mode is not a requirement
-
2. IPFW is used somehow - I'm positive there will be conflicts with other stuff using this method
-
3. The source code to the daemon will need to be updated to support PF - I've looked at the code, it's pretty simple, but I don't fully understand what needs to be done to implement PF support (and it really needs to be maintained by the author anyway)
If nobody has snagged this by the hackathon, I will consider spending more time on it then.
–Bill
You're quite right about it not being as simple as I'd hoped. I had forgotten that ipfw fwd does not rewrite the destination address, whereas pf's rdr rules do.
A quick google search turns up that some people do in fact use ipfw on top of pf to accomplish such things, but that doesn't seem like an ideal solution.
-
-
is there any news about this package?
im interested too -
-
Please remove bounty
