[SM-imapproxy] Imapproxy & ID command

[Jean-Luc Wasmer]

Hi,

I use Imapproxy 1.2.7 between Roundcube & Dovecot. I installed a
Roundcube plugging that sends the web client's IP address to the IMAP
server using the ID command. This way log files contain the real IP of
the user instead of the web server IP address.

Unfortunately, Imapproxy doesn't like that:

* OK [CAPABILITY IMAP4rev1 LITERAL+ LOGIN-REFERRALS ID ENABLE
XIMAPPROXY] Dovecot ready.
A0001 ID ("x-originating-ip" "24.212.235.245")
A0001 BAD Please login first
A0002 LOGIN user1 "password"


When I by-pass Imapproxy:

* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE
IDLE STARTTLS AUTH=PLAIN] Dovecot ready.
A0001 ID ("x-originating-ip" "24.212.235.245")
* ID ("name" "Dovecot")
A0001 OK ID completed.
A0002 AUTHENTICATE PLAIN AAAABBBBBCCCCDDD==



This seems like a rather simple command to support, would it be possible
to add it?

Thanks!
Jean-Luc

[Paul Lesniewski]

Post by Jean-Luc Wasmer
Hi,
I use Imapproxy 1.2.7 between Roundcube & Dovecot. I installed a
Roundcube plugging that sends the web client's IP address to the IMAP
server using the ID command. This way log files contain the real IP of
the user instead of the web server IP address.
* OK [CAPABILITY IMAP4rev1 LITERAL+ LOGIN-REFERRALS ID ENABLE
XIMAPPROXY] Dovecot ready.
A0001 ID ("x-originating-ip" "24.212.235.245")
A0001 BAD Please login first
A0002 LOGIN user1 "password"
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE
IDLE STARTTLS AUTH=PLAIN] Dovecot ready.
A0001 ID ("x-originating-ip" "24.212.235.245")
* ID ("name" "Dovecot")
A0001 OK ID completed.
A0002 AUTHENTICATE PLAIN AAAABBBBBCCCCDDD==
This seems like a rather simple command to support, would it be possible
to add it?

It's not simple at all. Because it's a pre-auth command, the proxy server
doesn't know what to do with it. The proxy server needs the client to
authenticate/log in before it knows whether it already holds an
established server connection or has to create a new one. The best it
could do is hold a queue of pre-auth commands (offering what amount to
fake "OK" responses to each) that would be dumped into the server
connection once a auth/login command is received. That's ugly, might be
consumptive of memory, and probably wouldn't sit well with clients who
expect real responses to each command.

You could change the webmail plugin you are using to send the ID command
after the user is logged in and everything should work as-is, with only
the login command not having the remote IP address associated with it in
your logs.

You could use a plugin that logs separate data straight from the webmail
software that documents the IP address where the user logged in from (in
SquirrelMail, this is supported by the squirrel_logger plugin).

I might add a limited implementation of the preauth command queue (per
above), where it only holds one ID command. I'll reply again if I get
around to it.

[Paul Lesniewski]

Post by Paul Lesniewski

Post by Jean-Luc Wasmer
Hi,
I use Imapproxy 1.2.7 between Roundcube & Dovecot. I installed a
Roundcube plugging that sends the web client's IP address to the IMAP
server using the ID command. This way log files contain the real IP of
the user instead of the web server IP address.
* OK [CAPABILITY IMAP4rev1 LITERAL+ LOGIN-REFERRALS ID ENABLE
XIMAPPROXY] Dovecot ready.
A0001 ID ("x-originating-ip" "24.212.235.245")
A0001 BAD Please login first
A0002 LOGIN user1 "password"
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE
IDLE STARTTLS AUTH=PLAIN] Dovecot ready.
A0001 ID ("x-originating-ip" "24.212.235.245")
* ID ("name" "Dovecot")
A0001 OK ID completed.
A0002 AUTHENTICATE PLAIN AAAABBBBBCCCCDDD==
This seems like a rather simple command to support, would it be possible
to add it?

It's not simple at all. Because it's a pre-auth command, the proxy server
doesn't know what to do with it. The proxy server needs the client to
authenticate/log in before it knows whether it already holds an
established server connection or has to create a new one. The best it
could do is hold a queue of pre-auth commands (offering what amount to
fake "OK" responses to each) that would be dumped into the server
connection once a auth/login command is received. That's ugly, might be
consumptive of memory, and probably wouldn't sit well with clients who
expect real responses to each command.
You could change the webmail plugin you are using to send the ID command
after the user is logged in and everything should work as-is, with only
the login command not having the remote IP address associated with it in
your logs.
You could use a plugin that logs separate data straight from the webmail
software that documents the IP address where the user logged in from (in
SquirrelMail, this is supported by the squirrel_logger plugin).
I might add a limited implementation of the preauth command queue (per
above), where it only holds one ID command. I'll reply again if I get
around to it.

The latter has been added. Please pull from SVN or wait a day to get a
snapshot from our downloads page.