There are several things that the remote address would make possible, easier or have it as a prerequisite:
* The authdaemon could be centrally logging who is requesting which account (not so interesting by itself) * The authdaemon could throttle abusing ips (something the services can't do, as they don't have such memory) * Differenciating remote accesses and internal services (ie. webmail)... even if the webmail uses an imap backend. * Geographically limit access to the accounts (do you really access your account from several countries/continents?). * Remote ip differenciation may also allow a limited multipassword feature (albeit the real solution would be to accept several passwords). Note that there some of the above may be solved in a different way, such as running several imap servers with slightly different configuration, or maybe with some clever use of access files for every service. Still, the most appropiate (and flexible) path seems to pass by having the remote address at the account checking step. And yes, I'm aware having the ip available is just a brick towards the building some of the above functionality. PS: It indeed looked like a X Y problem request! I have answered enough misdirected questions to hope not to be completely off, though. ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
