Andreas Aardal Hanssen wrote :
> Adds, this means if you have foo and add foo, you get foo foo. As written,
> this is completely unambiguous. If you have a set {a,b,c} and add the set
> {a} then you get {a,b,c,a}. It doesn't make sense, but it's what it says.
here, this is a set (I don't know if
Andreas Aardal Hanssen wrote :
> >> When the client deletes a mailbox does the server have to unsubscribe
> >> that mailbox from the list?
> >> Do E-Mail Clients send an unsubscribe command before send an delete command?
> >Maybe it could fix the subscription list when it knows that the mailbox
"Antonio Cambule (Stüber Software)" wrote :
> When the client deletes a mailbox does the server have to unsubscribe
> that mailbox from the list?
> Do E-Mail Clients send an unsubscribe command before send an delete command?
Maybe it could fix the subscription list when it knows that the mailbox
Rick Block wrote :
> Anyone have any suggestions for how to handle the following?
>
> The server I work on is primarily a voicemail server, although
> since it supports both IMAP and SMTP it also supports email.
> Historic voicemail UIs disallow forwarding for "private"
> messages (which doesn't
Christian Kratzer wrote :
> Hint: Display
> deleted messages in a virtual folder for your client.
Does such client exist ?
--
DINH V. Hoa,
etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan
pgp0.pgp
Description: PGP signature
Christof Drescher wrote :
> Is there any "simple" way for a client to get notified if a non-selected
> mailbox has newly arrived mail?
It seems that you want to poll this mailbox.
> Possibly best would be an update sent
> without request, a real notification then (e.g. as a response to a NOOP
>
Mark Crispin wrote :
> On Sun, 14 Dec 2003, DINH [iso-8859-1] Vi?t Ho? wrote:
> > I feel like this is a limitation in the specification due to the fact
> > that one implementation (maybe the reference implementation) will do
> > that this way even if the mailbox is already selected :
>
> An IMAP
Timo Sirainen wrote :
> On Sun, 2003-12-14 at 15:06, DINH Viet Hoa wrote:
> > the STATUS command SHOULD NOT be used on the currently selected mailbox.
> >
> > I do not see why it exists since the following statement exists :
>
> One problem is at least recent-counte
Mark Crispin wrote :
> On Sun, 14 Dec 2003, DINH Viet Hoa wrote:
> > I was wondering why there was such as statement in the RFC :
> > the STATUS command SHOULD NOT be used on the currently selected mailbox.
>
> All the information from STATUS can be obtained from the sta
I having a break in some café, drinking wine, eating foie gras, and with
my friend, I was wondering why there was such as statement in the RFC :
6.3.10. Page 43 :
<<
the STATUS command SHOULD NOT be used on the currently selected mailbox.
>>
I do not see why it exists since the following statem
Mark Crispin wrote :
> On Thu, 11 Dec 2003, Marcel Crasmaru wrote:
> > Suppose that message of sequence number 1 is unseen.
> > The client issue the command:
> > C: tag fetch 1 body[]
> > and the server fetches the message but for some reasons
> > it can not flag the message as seen (e.g., rename
Richard Bang wrote :
> Also given that I cannot predict what the next UID would be,
> what should the NEXTUID response be (omitted in above example until I
> can resolve this).
you may use the maximum value of the UID of the messages + 1.
some clients use "NEXTUID:*" to update their message list
Mark Crispin wrote :
> > I reissue my question :
> > is PERMANENTFLAGS a required response when a mailbox is selected ?
> > or can it be optional ?
>
> It is required.
If this is required, maybe the following statement should be modified :
<<
OK [PERMANENTFLAGS ()]
Mark Crispin wrote :
> (1) is the situation today. Extensions extend; they do not preserve the
> status quo. Furthermore, extensions extend client behavior.
>
> > 1 STORE 1 +FLAGS ($Junk)
> > * RECYCLEFLAGS ($Forwared $ThisFlag $AnotherOne)
> > * 1 FETCH (FLAGS (\Seen $Junk))
> > 1 OK STORE com
Mark Crispin wrote :
> In summary, I believe that the choices are:
>
> 1) Do nothing. IMAP client implementors are put on notice that servers
>which unilaterally recycle keywords (including in a session) may happen
>someday, and that client code which doesn't handle this is broken.
Inst
Richard Bang wrote :
> Should the next select return
> * PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft $test \*) ?
<<
6.3.1. SELECT Command
Arguments: mailbox name
Responses: REQUIRED untagged responses: FLAGS, EXISTS, RECENT
REQUIRED OK untagged responses: U
Andreas Aardal Hanssen wrote :
> This is the reason for me starting with Binc IMAP really. :/
I was quickly reading your document there :
http://www.bincimap.org/bincimap-tech.html
in fact, I wished I could see the picture here :
http://www.bincimap.org/bincimap-design-tiny.png
to easy my und
Andreas Aardal Hanssen wrote :
> On Wed, 3 Dec 2003, DINH Viet Hoa wrote:
> >as I found a bug in courier-imap with FETCH command (1), I would like to
> >(...)
> >It seems this is really a very very bad server (to keep polite).
>
> Be careful when reporting this bug
as I found a bug in courier-imap with FETCH command (1), I would like to
know if there is detection of syntax error in command, should the server
reply "BAD" or "NO" ?
For unknown commands, it also replies with NO, is this correct ?
I thought the response for bad syntax was "BAD" ...
Besides, I
Timo Sirainen wrote :
> On Mon, 2003-11-24 at 16:45, DINH Viet Hoa wrote:
> > > The point was that it could replace BODY and BODYSTRUCTURE fetches
> > > completely by allowing client to say exactly what fields it needs, not
> > > some specific fields forced by prot
Arnt Gulbrandsen wrote :
> IIRC, the STATUS-COUNTERS extension could have helped you do this. It's
> one of the things from the VPIM people. I don't know what its status is
> - the draft is expired. Its name used to be
> draft-neystadt-imap-status-counters.
Thanks for the information. But in f
Timo Sirainen wrote :
> The point was that it could replace BODY and BODYSTRUCTURE fetches
> completely by allowing client to say exactly what fields it needs, not
> some specific fields forced by protocol which may be more or less than
> needed by the client.
however, we still need BODY[STRUCTUR
Timo Sirainen wrote :
> Hmm. Maybe it'd work just as well without the virtual trashcan if everything
> else was there :) Currently I'm just annoyed at seeing the deleted messages
> there so I expunge them immediately (and sometimes wish I hadn't), but I'm
> afraid to just hide the deleted messages
As I could understand, in IMAP, we can keep a track of number of
messages. But what about recent or unseen messages ? should we always use
SEARCH to get the exact count ?
For example, we have some mailbox where a message is both marked \Recent
and \Deleted, we expunge the mailbox, the message i
When we want to define new flags in a client, should we use keywords or
flag extension for that ?
for example, I want to add the flag "Forwarded".
--
DINH V. Hoa,
"T'aurais pas une question sur le langage C" -- Emmanuel Delahaye
--
-
Timo Sirainen wrote :
> I would really like such user interface. With some help from server it
> would be possible:
>
> - virtual trashcan mailbox in server-side which contains all \deleted
>messages in all mailboxes
> - server-side automatic (client-configurable) expunging of messages olde
> I find this a tough question to answer. My inclination is just to close
> the connection but I cannot offer much justification for that. One
> consideration is that, if you send a LOGOUT and then immediately close the
> connection, it seems likely that the server will never see the LOGOUT.
> > > if I (as an IMAP client) have to exit quickly and have an open IMAP
> > > connection, I can't wait around for the IMAP server's responses.
> >
> > What is the reason for this ?
>
> I can think of four possible reasons right away. There might be more.
>
> 1. The user closes the MUA's windo
> if I (as an IMAP client) have to exit quickly and have an open IMAP
> connection, I can't wait around for the IMAP server's responses.
What is the reason for this ?
You have at least to wait for the IMAP response of the command you
want to send.
> In this case, should I send LOGOUT and immedia
> I've been told several times that Courier is not RFC compliant, although
> all the google references on this topic are well over 2 years old.
the most recent topic on this is 5 june 2002 (see the thread in the URL)
newsgroup comp.mail.imap
> What is the status of courier in terms of complianc
> > Given this request:
> >
> > a fetch 1 (body[header.fields (from)] body[header.fields (from to)]
> >
> > Are either of the following responses legal?
> >
> > * fetch 1 (body[header.fields (from to)] {nn}
> > From: foo bar
> > To: baz quux
> >
> > )
> >
> > * fetch 1
> We are working on the Unified messaging system and need to provide IMAP interface
>for it.
> Are there ready to use IMAP toolkits that can be used for the such purpose ?
>
> Requirements are as follows:
> 1/ C++
> 2/ full source code
> 3/ portable
> 4/ simple
> 5/ easy to use
> 6/ support most
> All IMAP servers must present the user with an INBOX. INBOX may also be
> present under another name.
>
> Is it common that IMAP servers also make INBOX available under a different
> name? Is there a way to find out whether two different names refer to the
> same mailbox?
Is there any sort of
> Apparently Outlook Express and Outlook 2000 send the append command and
> wait for the
> "+ Ready" response and I have that handled ok. The message and all its
> parts are brought down and written to a temp file. When I see the last
> four of a chunk equal to crlf + crlf or "--" + crlf, I
> At 13:41 31/05/2002 +0200, Andreas Aardal Hanssen wrote:
> >Say a mailbox has 1000 messages in it, and the highest UID is 1600. Which
> >is the correct response?
> >
> >1 UID FETCH 1601:* FLAGS
> >1 OK FETCH completed.
> >
> >or
> >
> >1 UID FETCH 1601:* FLAGS
> >* 1000 FETCH (UID 1600 FLAGS (\S
35 matches
Mail list logo