mailing list archives

Has anyone implemented some kind of a IP forwarding extension? So
backend servers could see the original IPs instead of the proxy's. So
login would go something like:

1 XFORWARD lip 1.2.3.4 lport 143 rip 4.5.6.7 rport 35353
2 LOGIN user pass

I guess I could just implement it like that, but at least trying to be
interoperable with another implementation would be nice. :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20080601/25aea545/attachment.sig>

Timo Sirainen writes:
> Has anyone implemented some kind of a IP forwarding extension? So 
> backend servers could see the original IPs instead of the proxy's. So 
> login would go something like:
>
> 1 XFORWARD lip 1.2.3.4 lport 143 rip 4.5.6.7 rport 35353
> 2 LOGIN user pass

Login referrals? Cyrus Murder?

> I guess I could just implement it like that, but at least trying to be
> interoperable with another implementation would be nice. :)

I've done such things as an administrator on the TCP level, using 
transparent proxying and load balancing. Sufficiently advanced hackery 
is indistinguishable from magic. Sufficiently advanced hackery is 
easily distinguished from a good idea. (Login referrals IMO have the 
same characteristics.)

Arnt

On Sun, 2008-06-01 at 20:45 +0200, Arnt Gulbrandsen wrote:
> Timo Sirainen writes:
> > Has anyone implemented some kind of a IP forwarding extension? So 
> > backend servers could see the original IPs instead of the proxy's. So 
> > login would go something like:
> >
> > 1 XFORWARD lip 1.2.3.4 lport 143 rip 4.5.6.7 rport 35353
> > 2 LOGIN user pass
> 
> Login referrals? 

No, not what I meant.

> Cyrus Murder?

Maybe. I tried to look into the Cyrus code but I couldn't find what
commands it uses.

> > I guess I could just implement it like that, but at least trying to be
> > interoperable with another implementation would be nice. :)
> 
> I've done such things as an administrator on the TCP level, using 
> transparent proxying and load balancing. Sufficiently advanced hackery 
> is indistinguishable from magic. Sufficiently advanced hackery is 
> easily distinguished from a good idea. (Login referrals IMO have the 
> same characteristics.)

The idea would be that there's a frontend IMAP proxy that looks up the
backend IMAP server based on the username, tells the backend server the
user's IP and then logs in using the provided user+password. Currently
the IP isn't forwarded, so some IP-based user access checks don't work.

Kernel-level transparent proxying wouldn't be enough ?because this isn't
just dummy proxying/load-balancing, but is it possible (with Linux) to
somehow do transparent proxying with userspace doing the actual proxying
(it'd also have to decode SSL sessions)?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20080601/d0c18bca/attachment.sig>

On 2008-Jun-1, at 12:20 , Timo Sirainen wrote:

> The idea would be that there's a frontend IMAP proxy that looks up the
> backend IMAP server based on the username, tells the backend server  
> the
> user's IP and then logs in using the provided user+password. Currently
> the IP isn't forwarded, so some IP-based user access checks don't  
> work.

Why can't you do the access checks at the front-end server? You're  
already going out-of-band to discover which back-end server to use.  
You're already passing the account name, so why not also pass the  
network address and do the access check there?

At 2008-06-01 22:20:43 +0300, tss@iki.fi wrote:
>
> is it possible (with Linux) to somehow do transparent proxying with
> userspace doing the actual proxying (it'd also have to decode SSL
> sessions)?

Yes, using libnetfilter_queue.

-- ams

On Sun, Jun 1, 2008 at 12:20 PM, Timo Sirainen <tss@iki.fi> wrote:

> On Sun, 2008-06-01 at 20:45 +0200, Arnt Gulbrandsen wrote:
> > Timo Sirainen writes:
> > > Has anyone implemented some kind of a IP forwarding extension? So
> > > backend servers could see the original IPs instead of the proxy's. So
> > > login would go something like:
> > >
> > > 1 XFORWARD lip 1.2.3.4 lport 143 rip 4.5.6.7 rport 35353
> > > 2 LOGIN user pass
> >
> > Login referrals?
>
> No, not what I meant.
>
> > Cyrus Murder?
>
> Maybe. I tried to look into the Cyrus code but I couldn't find what
> commands it uses.


Its been a while but as far as I remember the murder code just uses normal
IMAP all the way (to do the proxy auth, it uses a SASL mech that supports
it), but the IP is not passed.

-Rob

-- 
Rob Siemborski | PGP:0x5CE32FCC | robsiemb@google.com
Software Engineer | | 650-623-6925
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20080623/c2282e47/attachment.html>

On Jun 1, 2008, at 11:30 PM, Lyndon Nerenberg wrote:

> On 2008-Jun-1, at 12:20 , Timo Sirainen wrote:
>
>> The idea would be that there's a frontend IMAP proxy that looks up  
>> the
>> backend IMAP server based on the username, tells the backend server  
>> the
>> user's IP and then logs in using the provided user+password.  
>> Currently
>> the IP isn't forwarded, so some IP-based user access checks don't  
>> work.
>
> Why can't you do the access checks at the front-end server? You're  
> already going out-of-band to discover which back-end server to use.  
> You're already passing the account name, so why not also pass the  
> network address and do the access check there?

Well, that's a good question. :) Actually Dovecot already allows doing  
the check on the frontend, but it's also possible to do it on the  
backend as well. I don't know why the people who originally requested  
this feature don't want to do this on the frontend, but I can think of  
at least one specific use case:

Backends all share the mailbox data using NFS, so it's not critical  
which is the destination server. It's just better from performance  
point of view that simultaneous connections from the same user are  
directed to the same server. So the backend server lookup could be as  
simple as md5(username) MOD number_of_servers (or maybe something a  
bit more complex but still not an external expensive up-to-date  
database lookup).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 201 bytes
Desc: This is a digitally signed message part
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20080601/7b6cfa4a/attachment.sig>