Potential Contract Development Work

After reading through the NGINX MAIL module code, I emailed Evan M.
(http://evanmiller.org/nginx-modules-guide.html), George M.
(http://nutrun.com/weblog/hello-world-nginx-module/), Joshua Z.
(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
commands:

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

example:

    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

Hello!

On Tue, Nov 23, 2010 at 12:37:01AM -0500, brainjuice wrote:

there is in the HTTP modules.
Mail module currently supports extension via adding new protocols
(and this is how pop3, imap and smtp are implemented as of nginx
0.6.12+). This is clear, though somewhat limited model.

Individual protocol modules currently aren’t extendable and
designed to handle exactly one task (i.e. similar to http handler
modules).

Handling some other task (e.g. dummy smtp service which will
return “450 Try again later” to all commands) may be done via
registering additional protocol.

be written to handle desired outcomes; or
extending the MAIL API to handle additional processing via modules like

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

Intercepting IMAP commands will require nginx to understand the
whole IMAP protocol syntax and keep appropriate state when
proxying to/from backend. This is not something impossible, but this
is not something currently done. Right now nginx only tries to
understand authentication and then establishes opaque pipe to
backend.

If you want to implement intercepting IMAP proxy I would recommend
taking the following route:

  1. Start writing additional protocol handler which will be able to
    do this.

  2. Cleanup rough edges you’ll find during this work. This will
    certanly include extending ngx_mail_parse.c to understand more
    protocol details, and may include adding some extra callbacks.

Maxim D.

Maxim,
Thanks for the clarification of the abstraction on protocol extensions
within the MAIL module.

For my specific purposes, I am seeking to be able to hide special
folders (always labeled the same) that are used for administrative
purposes in mailboxes. I don’t believe that this requires statefulness
from connection to connection but rather the ability to watch for
specific IMAP commands requests (as is already the case) and modify the
behavior and/or intercept the results and manipulate them slightly
before returning the modified upstream response.

Regarding modifying NGINX code, I appreciate the concept of
encapsulating the changes needed as much as possible. As I provided in
my example (which originally contained no COPY command) I believe the
desired construct exists for what I am wanting to do but I just don’t
have the skills to effectively complete the task. So, my hope is to see
if there are others that would be served by a more generalized
abstraction model with the MAIL module and/or are there developers out
there willing to help with this project.

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

BUMP

Seeing if there are any devs out there that interested in work related
to extending IMAP functionality in NGINX.

If so, check out the full thread
http://forum.nginx.org/read.php?2,152559

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

Hello!

On Tue, Nov 23, 2010 at 06:04:54PM -0500, brainjuice wrote:

before returning the modified upstream response.
If you want to “watch for specific IMAP commands” you have to know
current state of protocol, else you won’t be able to distinguish
commands from e.g. message bodies.

Maxim D.

Dear brainjuice!

Could you contact me per mail [email protected] regarding extending
the IMAP functionality?

Thanks in advance!

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

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs