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 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.
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).
On Fri, Sep 04, 2009 at 07:03:42PM -0400, brainjuice 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”.
Basically nginx doesn’t have full-featured IMAP protocol parser
now, and after establishment of proxied connection there is no
safe way to intercept client commands or server responses.
Not event mentioning that there is no interface to do it.
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.
Mail module infrastructure is quite different. It does use the
same low-level operations for connection handling, config parsing
etc. But there is no such http-specific things as request
processing phases, filter chains and so on.
And AFAIK there is no programming documentation available except
source code.
The good thing is that mail module is small and simple enough.
Maxim D.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
