Jesse Guardiani <[EMAIL PROTECTED]> writes: > On Tuesday 21 January 2003 22:30, Tim Legant wrote: > > > 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. > > Well, I think you'd only need to worry about $TCPLOCALIP in the tmda code.
There is no $TCPLOCALIP when tmda-ofmipd runs, since it isn't run from tcpserver. It handles binding to the desired ports itself. > And even then just to figure out which IP tmda-ofmipd (or whatever > app we apply the code to) is being called from. That's already part of the socket data. We figure it out the same way that tcpserver does. > If you're using the flat file to reference calling IPs and IMAP/POP3 IPs > then you don't really care about whether or not $TCPLOCALIP is consulted > in the VPopMail authentication modules. *I* don't care, but if you want VPopMail authentication to work for IP-based domains, you need to care!! :) The vchkpw program won't authenticate IP-based domains properly unless that variable is set. When vchkpw gets called from qmail-popup, $TCPLOCALIP has already been set. This is true whether a client connects directly to the POP3 server or whether tmda-ofmipd connects to the POP3 server (to authenticate). The issue is not that the variable isn't set, because it is set. The issue is, what IP address is it set to, and right now, because tmda-ofmipd can only authenticate to a POP3 server on one IP address (the one given to the -R flag), it will only ever be set to that one address. As soon as tmda-ofmipd learns to connect to different IP addresses, then $TCPLOCALIP will vary based on which address tmda-ofmipd connects to, which will have the effect of allowing vchkpw to work correctly. I hope that made sense... > > 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. > > Works for me. > > > > > 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 > > ... > > I like that idea, but we could possibly take this a step further. > > Does VMailMgr have IP domain support too? Yes. > Do any IMAP/POP3 servers support VMailMgr's version of IP domains? Again, here, it's the VPopMail/VMailMgr authentication code that figures out the domain from the IP address, not the IMAP/POP3 server. That's why you can use the qmail-pop3d POP3 server with either of these VDMS. > VPopMail defines IP domains using the 'vipmap' command. > > If VPopMail is defined with SQL support, then these IP maps are written to > the vpopmail database. And if it's not build with SQL support, it's a file on disk. > We could include a hook to read this table directly, thus eliminating > another maintenance item and further tightening integration with VPopMail. This is exactly what I don't want to do, because I can't deduce how VPopMail was configured on any given system. I would have to introduce more and more command line options to tell tmda-ofmipd how VPopMail was configured/compiled. I would also get stuck in the business of modifying tmda-ofmipd everytime the VPopMail code changed. This has the effect of, when someone upgrades VPopMail, tmda-ofmipd stops working until I (or someone) gets the time to figure out what changed and fix it. No thanks. > This would facilitate your ideal of having the tmda-ofmipd proxy on one > machine, and the IMAP server on another, but it may create tmda-ofmipd > maintenance issues if VPopMail ever decides to change their IP table > structure. Yup. And I'm not trying to sell the idea of running tmda-ofmipd on a different machine than the IMAP or POP3 servers, but I certainly don't want to write code that prevents someone from doing so. As a general software philosophy, I dislike pointlessly limited solutions. > A partial solution would be to parse the output of the 'vipmap' command > to retrieve our IP table. > > But maybe we should again include a hook to an external script that returns > the proper info? That way quirky situations could be handled by Perl or SH > literate administrators on a case-by-case basis, and we wouldn't have to > deal with it as frequently. > > Or, maybe we should just use the flat file and forget SQL and external script > hooks, requiring the user to write a wrapper to 'vipmap' that would sync the > VPopMail IP table with the tmda-ofmipd IP flat file? Or even possibly include > a such wrapper in the distribution? I think providing a useful script to convert 'vipmap' data to our format would be the best solution. That way, we can use the same flat file for both VDMs. The script could be called from any other script that the mail admin cares to write and could also be called on its own to create the 'ipauthmap' file the first time around. Wanna take a crack at it? Tim _________________________________________________ tmda-workers mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-workers
