Kelsey Cummings writes:
> it brings up another issue to. Courier has no way of limiting > connections by userOf course it does. Courier's default configuration limits four connections from the same IP address.That is limiting connections by IP address not user. Per IP limits are of little use if you have set them high enough to allow large groups of users behind single IPs in.
There is no reliable mechanism for keeping track of individual userids logging in. It's several orders of magnitude more complex than keeping track of IP addresses. IP addresses can be easily tracked by couriertcpd, which already tracks its children processes and knows which one has which connection and from which IP address.
Since it won't be known who exactly is logging in until long after a connection gets established, and the connecting client succesfully authenticates, you can't exactly keep track of this in couriertcpd, which is protocol agnostic. Once a connection gets established, couriertcpd has no further knowledge of what happens to it, or involvement.
Per-userid tracking would be trivial only if all IMAP connections are serviced by a single monolithic process, which would have all that information available, however, of course, that's not the case here. That's the Windows way. Things here work differently.
Per user limits would mitigate the problem and at least keep an out-of-control client from affecting server performance.
It occurred to me that this situation usually happens when you're running some webmail software, that babbles IMAP, rather than doing its proper job. Some time ago, this was a fairly popular way of implementing webmail: put your brain on park, and use IMAP. Even though one's mail is stored on the same server that's running webmail, it just makes too much sense for webmail actually read the mail, and respond to client HTTP requests accordingly. That makes too much sense. Instead, one must install an IMAP server, so that the webmail can use IMAP to do the heavy lifting of parsing messages, their headers, and attachments, in response to high level requests, and produce cooked results on a silver platter. It's easier to do that, rather than to actually learn all the hodge-podge of MIME-related specifications which are needed to properly parse modern email.
So the end result one often ends up with is this Rube-Goldbergian like contraption involving webmail software sucking its content down through an IMAP straw. Its bad enough that the IMAP server needs to jump through small hoops in order to implement various IMAP-related oddities. Adding insult to injury, after expending some amount of effort to do all of that, it goes to waste because the webmail server, on the other side, gets to undo it all. What a waste.
And all because the webmail implementor doesn't want to be bothered with the actual task of parsing email content, but decides to fob it off on the IMAP server. sqwebmail may not have the eye candy of other webmail implementations, but, since it's an actual webmail server, it's anywhere from 10-20 times faster, with a fraction of the load.
Anyway, unfortunately there is no quick way to implement per-userid tracking of individual IMAP sessions right now.
pgpzgOa7RDNxK.pgp
Description: PGP signature
------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________ Courier-imap mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-imap
