Jesse Guardiani <[EMAIL PROTECTED]> writes: > However, I was under the impression that IP-based domain support for > IMAP and POP3 proxy was working, and I couldn't get it to work.
Ok, I think I understand what the problem is. I didn't do anything to the authentication process, so this is what has always been in tmda-ofmipd. Let's assume that a particular machine has 5 IP addresses aliased to a single interface. A single instance of tcpserver has been bound to all of them. It runs qmail-popup on a successful connection, which in turn runs the VPopMail program, vchkpw. The tcpserver program sets a group of environment variables that the next programs in line can examine. The vchkpw program, if compiled to do so, will look at $TCPLOCALIP (the IP address on the server that the client connected to) and will attempt to deduce the domain based on that IP. This means that the users can use a simple username -- the left side of their email address, like 'joe' -- and doesn't have to use the whole address, like '[EMAIL PROTECTED]'. A single instance of tmda-ofmipd can also bind to all IP aliases on a machine. The problem arises when we use the -R flag (remote authentication) to connect to a POP3 or IMAP server. We can, right now, connect only to the one host specified in the -R parameter. This means that, in our example setup, only about 1/5th of the authentications will work. Here is a proposed solution. 1) Allow the -R flag to accept a host of 0.0.0.0. That will be a flag to tell tmda-ofmipd to lookup the IP to authenticate through. 2) Create an IP -> IP mapping file in ~vpopmail/.tmda/ipauthmap. It would look something like this: xxx.xxx.xxx.1:nnn.nnn.nnn.21 xxx.xxx.xxx.2:nnn.nnn.nnn.22 ... The first IP is an address that tmda-ofmipd is bound to. The second IP is the address of the authentication server that tmda-ofmipd should connect to when a client connects to the first address. Both addresses can be the same, in the case where tmda-ofmipd is running on the same machine as the POP3 or IMAP server. In fact, if the authentication servers are always bound to the same addresses that tmda-ofmipd is bound to, you don't need the ipauthmap file at all; tmda-ofmipd can simply connect to the same IP for authentication that the external client connected to when contacting tmda-ofmipd. In all cases, the 0.0.0.0 flag from (1) above is the key to look for this file and use the mapping found or, if the file is not present, to connect to the same address the client did. This scheme allows authentication to take place on the same machine or on a remote machine, just as we do today. If any other hostname or IP address is given as an argument to the -R flag, processing takes place exactly as today. So... does this make sense to those of you who understand the whole authentication proxy, tcpserver environment variables, IP-based virtual domain pile of worms? Any objections or improvements? I think I can get this done pretty quickly if I get the approval. Tim _________________________________________________ tmda-workers mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-workers
