mailing list archives

Hello, I'm developing IMAP proxy server to check attachments.

(mail client) <-> (my proxy) <-> (real IMAP server)

Proxy does simple work: transmitting client requests and server responses.
Problem appears when client requests some message from server, but proxy
can't response to client while it not download full message from real server
(Proxy must check attachment before transmitting it). The message may be
very large and downloading may take much time. If client has some timeout it
may decide that server failed.

I tried to send "+ OK\r\n" periodically to client before real data
preparing, and this method is helpful for some mail clients. For example:

C: f fetch 1 (body[])
S: + OK    // server send "+ OK\r\n" by timer while downloading full message
S: + OK
S: + OK
...
S: * 1 FETCH (BODY[] {9876543} ....

but I think this way is not correct.

*Is any IMAP protocol feature to simulate message downloading, to prevent
client thinking about timeout?*

---------------------------------------------------------------
Nickolay Lozhkarev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20080708/a87d5a1c/attachment.html>

You're on the correct track, but the response is wrong.  Use "* OK", not "+ OK".

"+" is for command continuation (literals, IDLE, and SASL negotiations), and will confuse clients that do not have any command continuation in progress.

"* OK" is specifically for server-originated babble.  I suggest something like "* OK wait please..." rather than leaving the payload text empty.

-- Mark --



________________________________
Date: Tue, 8 Jul 2008 19:02:25 +0400
From: lozhkarev@googlemail.com
To: imap-protocol@u.washington.edu
Subject: [Imap-protocol] IMAP server mail transfer simulation

Hello, I'm developing IMAP proxy server to check attachments.



(mail client) <-> (my proxy) <-> (real IMAP server)



Proxy does simple work: transmitting client requests and server responses.

Problem appears when client requests some message from server, but proxy can't response to client while it not download full message from real server (Proxy must check attachment before transmitting it). The message may be very large and downloading may take much time. If client has some timeout it may decide that server failed.




I tried to send "+ OK\r\n" periodically to client before real data preparing, and this method is helpful for some mail clients. For example:



C: f fetch 1 (body[])

S: + OK    // server send "+ OK\r\n" by timer while downloading full message

S: + OK

S: + OK

...

S: * 1 FETCH (BODY[] {9876543} ....



but I think this way is not correct.



Is any IMAP protocol feature to simulate message downloading, to prevent client thinking about timeout?



---------------------------------------------------------------

Nickolay Lozhkarev


_________________________________________________________________
Need to know now? Get instant answers with Windows Live Messenger.
http://www.windowslive.com/messenger/connect_your_way.html?ocid=TXT_TAGLM_WL_messenger_072008

On Jul 8, 2008, at 8:32 PM, ??????? ???????? wrote:

> Proxy does simple work: transmitting client requests and server  
> responses.
> Problem appears when client requests some message from server, but  
> proxy can't response to client while it not download full message  
> from real server (Proxy must check attachment before transmitting  
> it). The message may be very large and downloading may take much  
> time. If client has some timeout it may decide that server failed.

Also note that the IMAP client may not fetch the entire attachment at  
once. For example Thunderbird might download the message in 100 kB  
blocks (FETCH BODY.PEEK[]<100000.200000> stuff). Your proxy will also  
have to handle that case.

Were you planning on not allowing client to see some attachments (like  
viruses)? What will you then send to client if the attachment isn't  
allowed? I guess just returning the attachment as full of space could  
work.

> I tried to send "+ OK\r\n" periodically to client before real data  
> preparing, and this method is helpful for some mail clients. For  
> example:

Send "* OK" instead. "+" is a command continuation, you can't send  
those.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 201 bytes
Desc: This is a digitally signed message part
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20080708/420b29bb/attachment.sig>

On 2008-Jul-8, at 08:02 , ??????? ???????? wrote:

> Problem appears when client requests some message from server, but  
> proxy can't response to client while it not download full message  
> from real server (Proxy must check attachment before transmitting  
> it). The message may be very large and downloading may take much time

Have you observed this as a problem in the real world, or is this just  
a hypothetical scenario?

What sort of things are you doing in the proxy? And what are the time  
bounds on that work? Which clients have you observed timing out? And  
what are those timeout values?

I get the feeling that you're inventing needless complexity for an  
undemonstrated requirement.

--lyndon

On Jul 10, 2008, at 7:02 AM, Lyndon Nerenberg wrote:

>
> On 2008-Jul-8, at 08:02 , ??????? ???????? wrote:
>
>> Problem appears when client requests some message from server, but  
>> proxy can't response to client while it not download full message  
>> from real server (Proxy must check attachment before transmitting  
>> it). The message may be very large and downloading may take much time
>
> Have you observed this as a problem in the real world, or is this  
> just a hypothetical scenario?
>
> What sort of things are you doing in the proxy? And what are the  
> time bounds on that work? Which clients have you observed timing  
> out? And what are those timeout values?
>
> I get the feeling that you're inventing needless complexity for an  
> undemonstrated requirement.

I know that at least Thunderbird has a timeout that's something like  
30 seconds. My server nowadays keeps sending untagged OKs to client  
every 15 seconds if some command processing is taking longer.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 201 bytes
Desc: This is a digitally signed message part
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20080710/5c7328ef/attachment.sig>

On 2008-Jul-10, at 00:08 , Timo Sirainen wrote:

> I know that at least Thunderbird has a timeout that's something like  
> 30 seconds. My server nowadays keeps sending untagged OKs to client  
> every 15 seconds if some command processing is taking longer.

And how is your server going to scale to every fucked up client  
implementation on the planet?

On 2008-Jul-10, at 00:08 , Timo Sirainen wrote:

> I know that at least Thunderbird has a timeout that's something like  
> 30 seconds.

Absolutely fscking brilliant.

I guess perl/tcl/scrum/configure/slashdot hasn't yet met event driven  
programming. Wait a minute ... :-(