NGINX and IMAP

[Joshua Zhu]

Hi,

On Sat, Sep 5, 2009 at 7:03 AM, brainjuice<nginx-forum at nginx.us> wrote:
> Hello all,
> I am writing to ask that you consider if you have any knowledge to share regarding creating Filter or Upstream Handlers for NGINX or, more specifically, in extending the Mail Modules.
>
> My goal is to be able to build code capable of filtering IMAP commands that the user is sending to the upstream IMAP server (through an NGINX proxying the IMAP commands) as well as the responses the upstream server would send back to those specific commands; all other traffic would pass unaltered as it does in existing IMAP proxy module.  This would, in effect, be the makings of what one might call an "IMAP Rewrite Module" but that seems quite ambitious at this point.  I am at a point where, from day-to-day, I switch from thinking that "yeah, I can probably do this" to "ugh, why am I wasting my time".
>
> I am new to writing modules for NGINX and googling has brought me to George Malamidis' "Hello world nginx module" (http://nutrun.com/weblog/hello-world-nginx-module/), and Evan Miller's "Emiller's Guide To Nginx Module Development" (http://www.evanmiller.org/nginx-modules-guide.html); I have read them both as well as parts of Evan's "Advanced Topics In Nginx Module Development" (http://www.evanmiller.org/nginx-modules-guide-advanced.html); and I have also searched the Nginx Mailing List, all in an attempt to better understand the structure of module development and the overall architecture in NGINX.
>
> I am still learning my way through and trying to make sense of all the internals of NGINX.  Though a bit thick, I do like what I have read thus far about how things are structured.  Fortunately I don't have to just rely on documentation as there are those that have gone before me in developing other modules and serve as a reference.  Some Modules that I have found promising / interesting:
>
> * ngx_http_rewrite_module - example of string replacement with regex patterns in the user request
> * ngx_mail_imap_module - capturing user requests sent to IMAP server (ex. login) instead of simply passing them upstream (as it does with all other requests)
> * ngx_http_ssi_filter_module - filtering response before returning to the end user
> * ngx_http_sub_filter_module - another example of filtering response before returning to the end user
>
> I have some questions that linger that I am hoping one of you on the list might know how to answer or might be familiar enough with the code to point me in the right direction.  If you would, I have the following question:
>
> How are Mail / IMAP requests characterized in the NGINX model / event chain?  Meaning, do they follow a similar pattern as Web / HTTP requests and responses with Header and Body content parts or is there a different model for these?  I am guessing they follow a different model but some clarification, if you have any, would be helpful.  So far, most, if not all, documentation I have found has a heavy focus (rightfully so) on handling or modifying Web / HTTP requests so I am finding that reading code has been my only hint in finding the context and callbacks needed but so far that has been VERY slow going.  Any help you would have in differentiating the Mail / IMAP request-response model from the somewhat well documented Web / HTTP model would greatly appreciated.


No, they _are_ quite different. As far as I know, the mail module
model is less developer friendly than the HTTP module model, since
there are no facilities like handlers or filter chain. However, you
can modify your redirect server to add load balancing and
username/password rewriting support.

Not all the commands would be parsed, i.e., after the authentication
phase between nginx and backend server, nginx just simply relay the
packets between client and backend. Therefore, filtering all IMAP/POP3
commands might not be an easy task, since you need to hack the
ngx_mail_proxy_handler() function and the FSMs, not impossible though.

I draw a sequence diagram to illustrate the flow of messages (see the
attachment).

Regards,

-- 
Joshua Zhu
http://www.zhuzhaoyuan.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mail_seq.png
Type: image/png
Size: 41460 bytes
Desc: not available
URL: <http://nginx.org/pipermail/nginx/attachments/20090905/685e1310/attachment.png>