Potential Contract Development Work

brainjuice nginx-forum at nginx.us
Tue Nov 23 08:37:01 MSK 2010

After reading through the NGINX MAIL module code, I emailed Evan Miller
(http://evanmiller.org/nginx-modules-guide.html), George Malamidis
(http://nutrun.com/weblog/hello-world-nginx-module/), Joshua Zhu
(http://blog.zhuzhaoyuan.com/tag/nginx/) and the mailing list
(http://forum.nginx.org/read.php?2,5651,5651#msg-5651) as well as a few
other module developers for some clarity on how to extend the MAIL
modules.  Based on the feedback I have received, I see that there isn't
a clear model for easily extending the MAIL modules like there is for
the HTTP modules. I want to be able to create a module to extend the
MAIL functionality to include regex rewrite-like functionality like
there is in the HTTP modules.

I realize that Igor is a busy man but eventually I wrote to him to ask
if he has plans to add chain output buffers or similar structure to the
MAIL module API to allow for more easily extending the functionality. He
has yet to respond.

With the state of things in the MAIL API, there are two routes to
address modifying the requests and responses proxied by NGINX:

1) add a chained out buffers and a structure to allow for registering
additional modules of functionality, to which additional modules could
be written to handle desired outcomes; or

2) modify the existing source code to scan line by line through the
requests and responses (like NGINX does today for the NOOP, LOGIN,
AUTHENTICATE commands) and handle each case individually.

I would prefer to see the option #1 taken so as to open up a whole new
front for NGINX development but I am not certain there is community
support for this.  I would like to hear from you if you have interest in
extending the MAIL API to handle Modules like the HTTP API does. Given
the lack of interest thus far I am sceptical of community interest in
extending the MAIL API to handle additional processing via modules like
the HTTP API. If you have an interest in helping with this model, please
speak up.

Short of community support for extending the MAIL API materializing, I
would be interested in knowing if there are any developers
willing/interested in modifying the source in ngx_mail_parse.c (and
other locations as needed) to accommodate additional proxied commands. 
In particular, I need to at least handle intercepting the following IMAP

 (IMAP commands listed in order of priority) 
[*] list <4> - response - substitute text during response from upstream
[*] select <6> - request - substitute text during request
examine <7> - request - substitute text during request
[*] status <6> - request & response - substitute text during request and
[*] copy <4> - request - substitute text during request


    switch (p - c) {
    case 4:
        vif ((c[0] == 'N' || c[0] == 'n')
                        && (c[1] == 'O'|| c[1] == 'o')
                        && (c[2] == 'O'|| c[2] == 'o')
                        && (c[3] == 'P'|| c[3] == 'p'))
                        s->command = NGX_IMAP_NOOP;

                    } else if ((c[0] == 'C' || c[0] == 'c')
                        && (c[1] == 'O'|| c[1] == 'o')
                        && (c[2] == 'P'|| c[2] == 'p')
                        && (c[3] == 'Y'|| c[3] == 'y'))


Any takers?

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,152559,152559#msg-152559

More information about the nginx mailing list