imap_client_buffer not being obeyed

Maxim Dounin mdounin at mdounin.ru
Mon Oct 8 10:57:31 UTC 2012


Hello!

On Sat, Oct 06, 2012 at 01:53:54AM -0400, iceman wrote:

> I have imap_client_buffer set to 64k(as required by imap protocol) in the
> nginx.conf file
> However when an imap client sends a very long command, post authentication,
> the length gets truncated at 4k(the default page size of the linux operating
> system) 
> 
> how can i debug this problem? i have stepped through the code using gdb. as
> far as i can see, in mail_proxy module, the value of the conf file(120000
> for testing) was correctly seen
> 
> gdb) p p->upstream.connection->data 
> $24 = (void *) 0x9e4bd48
> (gdb) p s
> $25 = (ngx_mail_session_t *) 0x9e4bd48
> (gdb) p p->buffer->end
> Cannot access memory at address 0x1c
> (gdb) p s->buffer->end - s->buffer->last
> $26 = 120000
> (gdb) p s
> $27 = (ngx_mail_session_t *) 0x9e4bd48
> (gdb) n
> 205         pcf = ngx_mail_get_module_srv_conf(s, ngx_mail_proxy_module);
> (gdb) n
> 207         s->proxy->buffer = ngx_create_temp_buf(s->connection->pool,
> (gdb) p pcf
> $28 = (ngx_mail_proxy_conf_t *) 0x9e3c480
> (gdb) p *pcf
> $29 = {enable = 1, pass_error_message = 1, xclient = 1, buffer_size =
> 120000, 
>   timeout = 86400000, upstream_quick_retries = 0, upstream_retries = 0, 
>   min_initial_retry_delay = 3000, max_initial_retry_delay = 3000, 
>   max_retry_delay = 60000}
> 
> When the command below is sent using telnet, only 4 k of data is accepted,
> then nginx hangs until i hit enter on keyboard......after which the
> truncated command is sent to the upstream imap server.
> 
> I am using nginx 0.78, is this a known issue?

I would recommend the following:

a) Test with something better than telnet.  While telnet is 
generally usable for testing, it might have issues with testing 
things buffer sizes as telnet usually have it's own buffers.  
Moreover, usually telnet works in line-at-a-time mode, which means 
it's telnet who is responsible for handling of the command until 
you hit enter.

b) If you still see the issue, upgrade to at least latest stable 
version of nginx, 1.2.4, before further testing.  There is no such 
version "0.78", but as long as it starts with "0." it's really 
old.


-- 
Maxim Dounin
http://nginx.com/support.html



More information about the nginx mailing list