ErikWalthinsen sends to the list a solution using MetaCat CaptivePortal to selectively allow clients to relay only to POP/IMAP4 servers which they have already authenticated to (kinda like an alternate version of Spack:PopBeforeSmtp).

I've just successfully tested a prototype of my transparent authenticator that should allow us to open up SMTP on open nodes in a selective manner in such a way that should almost eliminate the possiblity of spam being sent.

The concept is similar to what is used by companies with mobile laptops: the SMTP port is only opened to a remote machine if it has successfully completed a POP or IMAP login to the server. A timeout disallows the host soon afterwards to avoid hijacked IPs.

The method I've developed extends this to allow a transparent proxy running on the captive portal to use the same authentication process to allow SMTP packets through the portal.

The main problem that had to be overcome was the fact that, like almost all other protocols, POP and IMAP don't send the intended destination hostname in the TCP stream like HTTP/1.1 does. This means a simple user-space only transparent proxy cannot determine where to forward the connection to once it has the client connected.

My solution was to use the QUEUE target in iptables (need to patch your kernel to get the ip_queue.o module) to send the TCP SYN packets of the attempted connection up to userspace before they continue on to be redirected to the proxy program. In userspace, the same program (the joys of MetaNet) inspects the packet and determines the intended destination, and saves that away for future use. Almost immediately it gets a regular TCP connection from the client (redirected by the kernel), and associates the client with it's recently captured intended destination. From there it establishes a straight through proxy connection.

Since the packets are now flowing through userspace, we can search through the return packets from the server for the message "OK LOGIN" or any other string that indicates a successful authentication. When we see that, we simply add a iptables rule for that client and that server, allowing future SMTP connections.

Integrated with MetaCat (so the SMTP holes will be closed when the client leaves), we can safely allow SMTP connections because they are then strictly limited to servers that the client can successfully POP or IMAP to.

Once my code is a little cleaner and my paper has been written (have about 2 days now), I'll try to clean up MetaCat and debug the problems I'm having, and make some kind of usable release of it. Then I think I'm gonna look at python....


TransparentSmtpClientRelay (last edited 2007-11-23 18:02:01 by localhost)