Re: [vchkpw] Further thoughts on my localrelay patch
On 2007-01-02, at 1018, Joshua Megerman wrote: So we now have the question: What is the best way to proceed. I think that I would like to see the following changes made to the whole roaming users functionality in Vpopmail: 1) Document that the auth-before-smtp RELAYCLIENT= functionality is deprecated, and schedule it for removal 6-12 months down the line. if i'm reading this right, you're proposing that the entire pop before smtp functionality go away? so that nothing other than POP3 happens when somebody logs into the POP3 service, and there would be no dynamic changes to the access control list of the SMTP service at all? and vpopmail's documentation would explicitly tell people thou shalt use SMTP AUTH from now on? awesome. i just became one of your biggest fans. and for the time being, i think having an access control file attached to the POP3/IMAP services, which uses variables to tell when a given IP should trigger the update process, makes a lot more sense than trying to build a bunch of logic into vchkpw.c... just have it check for the presence and/or absence of environment variables, and let the external scripting control what does and does not go into that file. for example, the script could read the static smtpd access control file and find any IP blocks with RELAYCLIENT defined on them- and then copy those blocks to the POP3/IMAP access control file... and then the logic in vchkpw.c would bypass any updating if it saw a RELAYCLIENT variable in the environment. 2) Hijack the --enable-roaming-users config line to allow a different default set of tcpserver flags to be added. For now, the default would be '--enable-roaming-users=RELAYCLIENT=\\,RBLSMTPD=\\', but once #1 is finalized the RELAYCLIENT part would be removed. there does need to be a way to set what gets added to the smtpd access control file for dynamic entries. i'm not sure that highjacking an existing option is the right way to do it, nor do i think it should be a configure option. i think it makes more sense to let it be configured at run time- something like read the first line of a ~vpopmail/etc/_ file and use that. also, you would want to add something other than just RELAYCLIENT to your dynamic lines, maybe something like VPOPMAIL_DYNAMIC=\1\, so that the script which reads the smtpd access control list would recognize that as an entry which was dynamically added, and ignore it. but the overall idea is to minimize the amount of code you're changing in vpopmail itself, and make the whole update the cdb file process an externally driven thing. (yes, i'm actually thinking of the same separation of functions idea that i used when wrote the onchange patch- when the time comes it checks for the existence of a script, and if so, it runs it. anything beyond that is up to the script, and therefore requires no further changes to vpopmail itself.) This will preserve the ability to run vpopmail in exactly the same manner as it currently is, but move in the direction of eliminating auth-before-smtp relaying as the default method AND improving the ability to use auth-before-smtp for other access control methods. Plus, it gives people options without requiring them to be set if they don't use them. Thoughts? actually, yes... i just had an even better idea, the ultimate in flexibility. just as my onchange patch calls a ~vpopmail/etc/onchange script whenever something changes about the accounts, what about calling a ~vpopmail/etc/onauth script whenever somebody authenticates, and just leaving vpopmail's direct involvement at that? look at the 5.4.18 source code for the call_onchange() function (at the end of vpopmail.c), see how it works, and how it gets called from various places in the code. then consider writing a call_onauth() function similar to that, and then calling it from the appropriate place(s?) in vchkpw.c. then the whole process of modifying the smtp server's access control, and the logic behind when you do and don't update the list, all becomes part of the external scripting. this onauth script could also be used to drive a situation where somebody wants to log authentications to some other storage media, like a database- or to update a last auth timer in a database or LDAP server, or for any number of other purposes. then, you would write some kind of external script to manage the whole process of building the smtp access control file. that scripting could do whatever checking of static entries you like, and you can play with different scenarios in terms of making it work, without having to do any further patches to vpopmail. the only thing to keep in mind is that the onauth script itself needs to run as quickly as possible, because whatever service the user is logging into, is waiting for it to finish. this is why my own onchange script simply sends its command line
Re: [vchkpw] Further thoughts on my localrelay patch
On 2007-01-02, at 1018, Joshua Megerman wrote: So we now have the question: What is the best way to proceed. I think that I would like to see the following changes made to the whole roaming users functionality in Vpopmail: 1) Document that the auth-before-smtp RELAYCLIENT= functionality is deprecated, and schedule it for removal 6-12 months down the line. if i'm reading this right, you're proposing that the entire pop before smtp functionality go away? so that nothing other than POP3 happens when somebody logs into the POP3 service, and there would be no dynamic changes to the access control list of the SMTP service at all? and vpopmail's documentation would explicitly tell people thou shalt use SMTP AUTH from now on? awesome. i just became one of your biggest fans. Whoa... I wasn't expecting that... Just don't send me flowers or anything, OK? :) and for the time being, i think having an access control file attached to the POP3/IMAP services, which uses variables to tell when a given IP should trigger the update process, makes a lot more sense than trying to build a bunch of logic into vchkpw.c... just have it check for the presence and/or absence of environment variables, and let the external scripting control what does and does not go into that file. OK, I think I'm seeing where you're going with this, and while it'll take a little design work (not to mention some help with different backends - I only use MySQL right now), I'm game. for example, the script could read the static smtpd access control file and find any IP blocks with RELAYCLIENT defined on them- and then copy those blocks to the POP3/IMAP access control file... and then the logic in vchkpw.c would bypass any updating if it saw a RELAYCLIENT variable in the environment. Maybe - we'll see what works out the best after I do a detailed design on it. 2) Hijack the --enable-roaming-users config line to allow a different default set of tcpserver flags to be added. For now, the default would be '--enable-roaming-users=RELAYCLIENT=\\,RBLSMTPD=\\', but once #1 is finalized the RELAYCLIENT part would be removed. there does need to be a way to set what gets added to the smtpd access control file for dynamic entries. i'm not sure that highjacking an existing option is the right way to do it, nor do i think it should be a configure option. i think it makes more sense to let it be configured at run time- something like read the first line of a ~vpopmail/etc/_ file and use that. Well, I was thinking that a simple way to do it under the current struction was to have --enable-roaming-users=XXX set the default, compile-time directive, and then be able to override it at runtime (thus keeping the current behavior without any changes). But forcing runtime configuration works too, as long as it's well documented . also, you would want to add something other than just RELAYCLIENT to your dynamic lines, maybe something like VPOPMAIL_DYNAMIC=\1\, so that the script which reads the smtpd access control list would recognize that as an entry which was dynamically added, and ignore it. but the overall idea is to minimize the amount of code you're changing in vpopmail itself, and make the whole update the cdb file process an externally driven thing. (yes, i'm actually thinking of the same separation of functions idea that i used when wrote the onchange patch- when the time comes it checks for the existence of a script, and if so, it runs it. anything beyond that is up to the script, and therefore requires no further changes to vpopmail itself.) If we're taking the info out of vchkpw and moving it into an external process, we can design it right from the ground up. This may involve redesigning the relay table to add more info, or have some additional tables to do lookups in, but I'm already starting to get some ideas... This will preserve the ability to run vpopmail in exactly the same manner as it currently is, but move in the direction of eliminating auth-before-smtp relaying as the default method AND improving the ability to use auth-before-smtp for other access control methods. Plus, it gives people options without requiring them to be set if they don't use them. Thoughts? actually, yes... i just had an even better idea, the ultimate in flexibility. just as my onchange patch calls a ~vpopmail/etc/onchange script whenever something changes about the accounts, what about calling a ~vpopmail/etc/onauth script whenever somebody authenticates, and just leaving vpopmail's direct involvement at that? Clean, simple, flexible. I like it. :) look at the 5.4.18 source code for the call_onchange() function (at the end of vpopmail.c), see how it works, and how it gets called from various places in the code. then consider writing a call_onauth() function similar to that, and then calling it from the appropriate place(s?) in vchkpw.c. Will do (once it's out :)) - I'm a little
Re: [vchkpw] Further thoughts on my localrelay patch
Josh just as curiosity what will they mega patch for qmail include? Thanks, Remo Joshua Megerman wrote: Whoa... I wasn't expecting that... Just don't send me flowers or anything, OK? :) OK, I think I'm seeing where you're going with this, and while it'll take a little design work (not to mention some help with different backends - I only use MySQL right now), I'm game. Maybe - we'll see what works out the best after I do a detailed design on it. Well, I was thinking that a simple way to do it under the current struction was to have --enable-roaming-users=XXX set the default, compile-time directive, and then be able to override it at runtime (thus keeping the current behavior without any changes). But forcing runtime configuration works too, as long as it's well documented . If we're taking the info out of vchkpw and moving it into an external process, we can design it right from the ground up. This may involve redesigning the relay table to add more info, or have some additional tables to do lookups in, but I'm already starting to get some ideas... Clean, simple, flexible. I like it. :) Will do (once it's out :)) - I'm a little busy working on a couple of other things, like releasing my Uber-Mega-qmail patch set (the patches are done, but documenting them takes time... :), but I'll add this to the queue. Since the patch isn't going into 5.4.18 anyway, there's time. By default, vpopmail logs the last auth for most backends. This could handle that as well. *nod* Alternatively, vpopmail could just write to the pipe itself, but the onauth script is a cleaner method. Basically, I'd send 4 tokens to the service: user, domain, IP, timestamp. It can handle the rest. It should be able to run as vpopmail, since the tcp.smtp.cdb file is owned by vpopmail, and that's what gets used by qmail-smtpd. vchkpw runs as vpopmail, and it handles it all now, so I don't see a need for root access here. Agreed. And it makes alternative development/hooks easier too. I'd appreciate the help on the daemon, although just giving me the sampe code of your daemon would probably be good enough. I have a very long history of looking at other peoples' code and taking just the parts I need for whatever I happen to be working on - it's how I learned C in the first place 15 years ago... :) Josh
Re: [vchkpw] Further thoughts on my localrelay patch
Josh just as curiosity what will they mega patch for qmail include? Funny you should ask... Will do (once it's out :)) - I'm a little busy working on a couple of other things, like releasing my Uber-Mega-qmail patch set (the patches are done, but documenting them takes time... :), but I'll add this to the ^^^ I'm writing up the real documentation now - I have my patchlog, but it's hopelessly inadequate to provide to outside persons. I'll post both here and to the qmail list when I finish the docs/setup, which will hopefully be sometime this week. Until then, I ask for your patience :) Josh -- Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
Re: [vchkpw] Further thoughts on my localrelay patch
On 2007-01-03, at 1436, Joshua Megerman wrote: look at the 5.4.18 source code for the call_onchange() function (at the end of vpopmail.c), see how it works, and how it gets called from various places in the code. then consider writing a call_onauth() function similar to that, and then calling it from the appropriate place(s?) in vchkpw.c. Will do (once it's out :)) it's out. i'm running it now. wait- rick, did you forget to announce it on this list, or is it not for general consumption yet? i downloaded it from sourceforge and it works fine, including the onchange stuff. - I'm a little busy working on a couple of other things, like releasing my Uber-Mega-qmail patch set (the patches are done, but documenting them takes time... :), but I'll add this to the queue. Since the patch isn't going into 5.4.18 anyway, there's time. so you've got a qmail mega-patch as well? i'm starting to wonder who DOESN'T have one anymore... mine: http://qmail.jms1.net/patches/combined-details.shtml the only thing to keep in mind is that the onauth script itself needs to run as quickly as possible, because whatever service the user is logging into, is waiting for it to finish. this is why my own onchange script simply sends its command line arguments to a named pipe, where an update-qmail service is waiting for the data... that service actually does all of the work while the script exits and vpopmail lets the user get back to what they were doing. Alternatively, vpopmail could just write to the pipe itself, but the onauth script is a cleaner method. Basically, I'd send 4 tokens to the service: user, domain, IP, timestamp. It can handle the rest. if you want to split user and domain apart like that, sure... my preference would be to keep them together, as one opaque item- that way if you have a hybrid mixed system of vpopmail and system accounts, the API doesn't need to change to support no such thing as a domain... and if you do need them separately, it's easy enough to split the one datum on the @ character. as for vpopmail writing the pipe directly... that was suggested for the onchange patch as well- and shot down very quickly, by myself and by tom. the argument is/was that most people understand how shell scripts work, but very few people understand named pipes- and while anybody can write a shell script, not everybody will be doing anything complex enough to need to involve pipes. some people may do things with unix sockets, TCP or UDP sockets, semaphores, mutices (plural of mutex), or any number of other things... running a shell script leaves people with the ability to choose their own IPC mechanism, rather than forcing them to run a named pipe watcher service. it's all about flexibility. and then you could write a dedicated service, to run under daemontools, which would track which IP's are authorized and their timeout values, and would rebuild the smtp access control file whenever it needs to be changed... it could even run as root if needed (which it probably would, if it's going to be updating the smtp service's access control file.) It should be able to run as vpopmail, since the tcp.smtp.cdb file is owned by vpopmail, and that's what gets used by qmail-smtpd. vchkpw runs as vpopmail, and it handles it all now, so I don't see a need for root access here. not everybody runs their entire mail system as the vpopmail user (in fact i don't run ANY of it as the vpopmail user- for clients who use vchkpw to handle SMTP AUTH, i have the vchkpw binary setuid/setgid to the vpopmail user, but that's it.) and since other programs (qmailadmin, vpopmaild, or some as-yet- unknown program in the future) might also end up calling this function, i think it's safer to not assume anything about what userid will be running the onauth script itself. if the script is signalling a service, obviously run the service as the userid which makes the most sense for the situation- but the onauth script itself needs to be executable by any userid on the system. I'd appreciate the help on the daemon, although just giving me the sampe code of your daemon would probably be good enough. I have a very long history of looking at other peoples' code and taking just the parts I need for whatever I happen to be working on - it's how I learned C in the first place 15 years ago... :) it's actually written in perl, believe it or not... but it should translate to C easily enough, if you're so inclined. i can see keeping a hash in memory, the IP pointing to an expire time, and every time an IP authenticates, the expire time is replaced with now plus 30 minutes... it would periodically build a new list, leaving out any expired IPs, and if the new list of IPs (not their timeout values) is different from the old list, it would write out new files and call tcprules as needed. part of writing out new files would be writing a cache to the
Re: [vchkpw] Further thoughts on my localrelay patch
On Jan 3, 2007, at 10:48 AM, John Simpson wrote: there does need to be a way to set what gets added to the smtpd access control file for dynamic entries. i'm not sure that highjacking an existing option is the right way to do it, nor do i think it should be a configure option. i think it makes more sense to let it be configured at run time- something like read the first line of a ~vpopmail/etc/_ file and use that. I like the idea of an environment variable -- no overhead from reading it from a file every time vchkpw runs. You can also customize it per connection if necessary. -- Tom Collins - [EMAIL PROTECTED] Vpopmail - virtual domains for qmail: http://vpopmail.sf.net/ QmailAdmin - web interface for Vpopmail: http://qmailadmin.sf.net/
Re: [vchkpw] Further thoughts on my localrelay patch
it's out. i'm running it now. wait- rick, did you forget to announce it on this list, or is it not for general consumption yet? i downloaded it from sourceforge and it works fine, including the onchange stuff. Huh - so it is. Posted 12/30/06. Maybe I misunderstood the last message about what patches would be in it, but I definitely don't remember an official announcement. I'll have to grab it and check it out. - I'm a little busy working on a couple of other things, like releasing my Uber-Mega-qmail patch set (the patches are done, but documenting them takes time... :), but I'll add this to the queue. Since the patch isn't going into 5.4.18 anyway, there's time. so you've got a qmail mega-patch as well? i'm starting to wonder who DOESN'T have one anymore... mine: http://qmail.jms1.net/patches/combined-details.shtml I'm quite familiar with it - I've even used one of the small patches on your site (the date-localtime patch), although I'm not sure if you wrote it or not (there's no credit in the file itself, and I've seen it credited to 2 different people out there, neither of them you. But nevertheless qmail.org links the patch on your site, even if the link is stale these days...). We each have our own philosophies about what we want and how we implement it. I've also written about 25% of the patches I use, either from scratch or as updates to existing patches (since often updating to a new version of someone else's patch can require restarting the whole patch process...) Alternatively, vpopmail could just write to the pipe itself, but the onauth script is a cleaner method. Basically, I'd send 4 tokens to the service: user, domain, IP, timestamp. It can handle the rest. if you want to split user and domain apart like that, sure... my preference would be to keep them together, as one opaque item- that way if you have a hybrid mixed system of vpopmail and system accounts, the API doesn't need to change to support no such thing as a domain... and if you do need them separately, it's easy enough to split the one datum on the @ character. I believe vchkpw already splits them, but I'm not sure. It's easy enough to pass them in whatever form vchkpw has them natively. as for vpopmail writing the pipe directly... that was suggested for the onchange patch as well- and shot down very quickly, by myself and by tom. the argument is/was that most people understand how shell scripts work, but very few people understand named pipes- and while anybody can write a shell script, not everybody will be doing anything complex enough to need to involve pipes. some people may do things with unix sockets, TCP or UDP sockets, semaphores, mutices (plural of mutex), or any number of other things... running a shell script leaves people with the ability to choose their own IPC mechanism, rather than forcing them to run a named pipe watcher service. it's all about flexibility. Makes sense - I was already leaning that way anyway. It should be able to run as vpopmail, since the tcp.smtp.cdb file is owned by vpopmail, and that's what gets used by qmail-smtpd. vchkpw runs as vpopmail, and it handles it all now, so I don't see a need for root access here. not everybody runs their entire mail system as the vpopmail user (in fact i don't run ANY of it as the vpopmail user- for clients who use vchkpw to handle SMTP AUTH, i have the vchkpw binary setuid/setgid to the vpopmail user, but that's it.) They don't need to - if they're using vpopmail's cdb file, it needs to be writable by vpopmail and just readable by whatever user(s) tcpserver is running as. And if the onchange script is called by vchkpw, it'll run as vpopmail since it's a child process. Now, you could choose to run the daemon as a different user for other reasons, and just give vpopmail write access to the pipe, but if you're duplicating the current onauth behavior for updating the tcp.smtp.cdb, theres no good reason not to run as vpopmail that I can see. and since other programs (qmailadmin, vpopmaild, or some as-yet- unknown program in the future) might also end up calling this function, i think it's safer to not assume anything about what userid will be running the onauth script itself. if the script is signalling a service, obviously run the service as the userid which makes the most sense for the situation- but the onauth script itself needs to be executable by any userid on the system. I'm not sure I see the onauth system being used as generically as the onchange one - I definitely see how onchange needs to be available for a variety of functions, but onauth probably is a niche function, albeit an important one... I'd appreciate the help on the daemon, although just giving me the sampe code of your daemon would probably be good enough. I have a very long history of looking at other peoples' code and taking just the parts I need for whatever I happen to be working on - it's how I learned C in
Re: [vchkpw] Further thoughts on my localrelay patch
On 2007-01-03, at 1625, Joshua Megerman wrote: ... I've even used one of the small patches on your site (the date- localtime patch), although I'm not sure if you wrote it or not (there's no credit in the file itself, and I've seen it credited to 2 different people out there, neither of them you. i didn't write it. i found it floating around on the internet years ago. i wish i did know who wrote it, i owe them a beer for saving my job a little bit easier every time i've had to tear through headers over the years... But nevertheless qmail.org links the patch on your site, even if the link is stale these days...). i didn't realize qmail.org was linking to my site at all. every time i've asked russell about adding a link to one of my scripts or patches, i've basically been ignored- i figured i wasn't a member of their good old boys club, so it wasn't worth my time to worry about it. I believe vchkpw already splits them, but I'm not sure. It's easy enough to pass them in whatever form vchkpw has them natively. vchkpw splits them internally. the checkpassword standard calls for them to be together. either way, it's a minor issue- but there may come a point in the future where a program other than vchkpw may wish to use the onauth mechanism when certain services authenticate (courier-authlib comes to mind) and they may not support the concept of separate mailbox id and domain name the same way that vpopmail does. i know that vchkpw RECEIVES them as one single opaque item from qmail- smtpd, qmail-popup, or any other checkpassword-compliant program. either way it's a minor issue at this point... unless you're writing the API in your head already? now i'm really interested in seeing where you take this... again, feel free to bounce questions or ideas off of me. Thanks - it's a little overwhelming to get so many kudos from established players when I'm still so new here (even if I have been dabbling for a long time). i recognize smart when i see it. and the fact that you've understood everything i've thrown out there, and come back with intelligent answers and counter-ideas, tells me that you're smart. that's all it is. and for the record, i don't consider myself to be established. knowledgable, yes, but... i don't even have a real link on the qmail.org site, and i'm not in google's top ten results for qmail (at least i don't *think* i am... no, i'm #22.) the only reason i'm even listed as a developer for vpopmail is because i've sent in a fair number of good patches- tom invited me (yes, i'm honored) but i have yet to actually check anything into the CVS repository at all (rick has been doing that for me, since he knows how to write the configure script and i don't.) so don't feel overhwelmed by me... i'm just some guy who wrote a web site that a lot of people find useful, who knows how to write code, who's been building, running, and now consulting for ISPs for a long time, and who's getting tired of consulting and thinking seriously about jumping back into the full-time job market (and is willing to relocate for the right offer, hint hint anybody...) | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | | http://video.google.com/videoplay?docid=-4312730277175242198 | PGP.sig Description: This is a digitally signed message part
[vchkpw] Further thoughts on my localrelay patch
I had no idea I'd be opening such a big can of worms when I posted my patch, though thankfully all of the feedback I've gotten has been polite, constructive and coherent even if it's been negative :) As I see it, this patch may fill a need that still exists, but it probably needs a little more work before it hits prime time. First off, lets (re-)examine how Vpopmail handles things without my patch, looking at it from (yet) another direction: Case #1: No auth-before-smtp (POP or IMAP, as opposed to SMTP AUTH) roaming users - tcpserver cdb is statically built. Case #2: Roaming auth-before-smtp (POP or IMAP) is used for all IPs not statically configured in the tcpserver cdb (that is, all static addresses are configured to either allow relaying or deny the connection). Case #3: Roaming auth-before-smtp (POP or IMAP) is used and some or all of the static IPs in tcpserver cdb are allowed to be overridden by pre-authenticating via a non-SMTP method. Case #1 can occur in several different cases (--disable-roaming-users, --disable-rebuild-tcpserver-file, or just not using the dynamic tcpserver file). In any case, my patch is (mostly) irrelevant, as unless you're just nor using the dynamic tcpserver file, the code to update the CDB is not even compiled in, and if that's the case you should reconfigure Vpopmail appropriately in any case. Case #2 is where my patch is most useful: you have specific, statically authorized (or denied) relay IPs that you don't want to take the time to update the cdb for, but need to dynamically allow auth'd clients to relay (for whatever reason - I agree that SMTP AUTH is preferred, but some people still need to support auth-before-smtp for legacy reasons, and I'm not one of thos people who feels that you should eliminate functionality just because you want to discourage its use, unless it's actually broken, violates some part of the official spec, or is actually dangerous. Yes, I know it's a bad idea, and if you want to deprecate it and mark it for elimination 6-12 months from now, that's OK too. But don't just yank it without warning). Also, my patch is pretty much a requirement if you're using webmail, so that the webmail server doesn't keep getting updated in the CDB with every page access... Case #3 is the difficult one - one which my patch doesn't adequately allow for at this time. There has been some discussion about how to dynamically allow for different tcpserver flags to be applied on authentication, rather than the default 'RELAYCLIENT=,RBLSMTPD=', which I think is a good idea. Currently, if you have a static IP address range set to deny a connection, Vpopmail allows clients who have pre-authenticated via POP or IMAP to connect via SMTP for the auth timeout period. Combined with custom tcpserver flags, this can be used to allow connections without necessarily automatically enabling relaying from otherwise denied IPs. It also allows RBL bypassing on authenticated IP addresses that would otherwise still have to bypass the RBL (Note - I don't use rblsmtpd at this time, so I don't know how well it really works. If you want to school me, that's fine, but please either start a new thread or take it offlist - thanks). I believe that I can adjust my patch to do this, but it will take a little thought and mapping out the possibilities to do it both correctly and efficiently. I'll probably try and tackle it this week, but no guarantees. Also, please note that this usage actually improves the standing of auth-before-smtp (if RELAYCLIENT isn't set automatically) by limiting SMTP traffic from non-approved IP addresses to known authorized users' IPs, while still requiring SMTP AUTH to relay mail (which eliminates the possibility of an IP address being hijacked after a legitimate user disconnects but before the open smtp entry expires). So we now have the question: What is the best way to proceed. I think that I would like to see the following changes made to the whole roaming users functionality in Vpopmail: 1) Document that the auth-before-smtp RELAYCLIENT= functionality is deprecated, and schedule it for removal 6-12 months down the line. 2) Hijack the --enable-roaming-users config line to allow a different default set of tcpserver flags to be added. For now, the default would be '--enable-roaming-users=RELAYCLIENT=\\,RBLSMTPD=\\', but once #1 is finalized the RELAYCLIENT part would be removed. 3) Allow the roaming tcpserver flags to be dynamically modified using either a configuration entry in a file (possibly a a second comment in the tcp.smtp file like my STATICUPDATE tweak) or an environment variable (which could be passed via tcpserver to the POP/IMAP service, coming full circle :)). 4) Implement my localrelay functionality with 2 enhancements: a) Recognize the IP address of 0.0.0.0 or NULL and skip the CDB update altogether (I though of this this morning and have already implemented it). b) Provide some sort of tcpserver flag (e.g., 'UPDATESTATIC=') on
