On 6/6/2013 1:25 AM, Sam Varshavchik wrote: > Jakob Bohm writes: > >> On 6/5/2013 1:21 PM, Taavi Kald wrote: >> > Hi, >> > >> > would be nice if Courier Imap server supported Proxy Protocol >> > (http://haproxy.1wt.eu/download/1.5/doc/proxy-protocol.txt) >> >> Interesting proposed protocol somehow not submitted as an internet >> draft for proper standardization. >> >> In reading the document I note that the original proposer has tested >> it against only one IMAP implementation, seen it fail and ignored the >> issue. >> >> I also note that the protocol, as fundamentally designed, is never >> going to work with any server whose layer 6 protocol parser code >> cannot be changed (such as any previously shipped close source >> products, such as those from MS and Apple). >> >> I also find that the protocol will be hard to implement in kernel or >> hardware level proxies, such as the NAT features in the Linux and BSD >> kernel, nor in similar high speed hardware implementations. >> >> Another specification flaw (but purely a specification issue) is that >> the specification suggests that servers are set up with extra IP >> addresses to receive proxied requests, plus extra firewall rules to >> prevent direct Internet access to the redundant listens. This is an >> extremely high overhead in a world with IPv4 exhaustion and protocol >> stacks that make it exceedingly difficult to properly handle multiple >> IP addresses (both Linux and NT fail miserably in this department). >> Only as a vague note late in the specification does it even mention >> the saner option of looking for proxy information only if the source >> IP is that of the proxies used. > > Another specification flaw is the requirement that the server wait > until it receives the proxy header. The first thing an IMAP server > does is send its greeting; so this would only be applicable in 100% > proxy environments, where all connections come from proxies, since the > server won't send its greeting until it reads the header. > The (otherwise flawed) specification actually handles this by specifying that if the connection comes from a trusted proxy, always insist on a proxy header, then send the greeting, if the connection does not come from a trusted proxy, do not wait for, expect, nor accept a proxy header (as that would be a spoofed header or a misconfiguration).
But I still think an out-of-band path for this data is a better solution, as it would not require people like the OP to have to contact server authors such as you and convince them to individually implement the protocol du jour. > This is not unique to IMAP. Ditto for SMTP, POP3, etc… > > Furthermore, Courier-IMAP had its own built-in proxy, for a number of > years. Which is far more sophisticated that generic protocol-level > proxies. You need to run the server on the proxies themselves, and it > will look up the server to proxy from the login ID, and then proxy the > actual IMAP session to the server that the account really lives on. > You can move mailboxes between servers, with no change to client-side > configuration. So, just install a bunch of proxy servers that share > the same DNS hostname, balance the load on the front end, and balance > the back end by moving accounts (during downtime, of course). > I seriously think the proxy type for which this kind of protocol is relevant serves purposes different from what a bunch of DNS balanced layer 5 proxies can ever do. For instance I believe the ha-proxy software from which this protocol originated can make multiple proxies respond to the same IP address in such a way that things work even if clients fail to try more than the first IP address returned by DNS. Other proxies that could use a generic proxy transparency protocol like this would be those that run mostly at layer 3 or below, such as Linux iptables or high end switches with most of the proxying done in silicon. > You can take your logs from the proxy server directly. > Only if the proxy box has the capacity and security to actually run your layer 5 proxy with all its unneeded (for the OP) user name lookups and state management. So I still suggest that for all manner of troubleshooting, connection tracing etc. it would be a Good Thing(tm) if you logged the full address details of incoming connections, not just the bare client IP address. I have myself had other problems with this limited logging, for instance one of my servers is multihomed, and the current logging does not tell me if a connection was routed via the "left" or "right" network. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j _______________________________________________ Courier-imap mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-imap
