MBOX-Line: From tss at iki.fi  Tue Jul  8 08:15:08 2008
To: imap-protocol@u.washington.edu
From: Timo Sirainen <tss@iki.fi>
Date: Fri Jun  8 12:34:42 2018
Subject: [Imap-protocol] IMAP server mail transfer simulation
In-Reply-To: <56b1f8870807080802p4bea379bi5185e9aff1b33585@mail.gmail.com>
References: <56b1f8870807080802p4bea379bi5185e9aff1b33585@mail.gmail.com>
Message-ID: <802114B0-2D22-4785-A18E-C6BFB736B2FA@iki.fi>

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>
