Potential Contract Development Work

[Maxim Dounin]

Hello!

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

> 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.

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.

> 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]

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 Dounin