Re: Understanding Reference Names
At 2004-06-02 13:15:18 +0200, [EMAIL PROTECTED] wrote: I've never seen that I can create an directory in the meaning of reference with an Client. I think you're confused: the reference name is simply an argument that tells LIST which results to return. For example, consider a hypothetical server with this mailbox hierarchy: /users/a/INBOX /users/a/foo /users/b/INBOX /users/b/xyzzy /pub/support #news.comp.protocols.imap If you're logged in as user a, INBOX refers to /users/a/INBOX; foo refers to /users/a/foo. /pub/support refers to /pub/support, as does ~b/xyzzy refer to /users/b/xyzzy. You can think of this as having a current working directory of /users/a. Just as a current working directory provides a context to interpret a file name, the reference name provides a context for LIST to interpret its mailbox name. That's all it does. Now read Mark's reply to you again. It'll probably make more sense. (You may also wish to glance at the examples in RFC 2342 as well.) -- ams
Re: Understanding Reference Names
At 2004-06-02 16:25:07 +0200, [EMAIL PROTECTED] wrote: So If I'm connected with user a, I will always have the current directory /users/a and the incoming client Reference Name will always be The client can send whatever reference name it wants. OK, let me try to explain this differently. When you login as user a, suppose your current working directory is /users/a. Think of LIST as the equivalent of ls(1). Saying LIST /foo bar is like doing cd /foo; ls bar. That's the same as LIST / foo/bar: cd /; ls foo/bar. That's the same as «LIST /foo/bar»: cd ~; ls /foo/bar. That's the same as LIST /users/b/x /foo/bar: cd ~b/x; ls /foo/bar. And so on. You can think of the reference name argument to LIST as allowing you to change directory before doing the ls, thus providing a context for the interpretation of the mailbox name. Obviously, if the mailbox name is already fully-qualified (as in examples 3 and 4 above), the reference name does not affect its interpretation. -- ams
Re: literal
At 2004-02-18 14:14:40 +0100, [EMAIL PROTECTED] wrote: Is that text(example) above correct for the type literal??? The length is wrong: There should be 1234567890 characters (a little over 1GB). But please don't post the correct example to the list. :-) -- ams
Re: How to parse Incoming Client Requests?
At 2004-01-16 11:33:31 +0100, [EMAIL PROTECTED] wrote:
But now I've got recursive Rules and I'm not shure if I can reproduce
them using constants respectively in Regular Expressions.
Which recursive rules are you talking about?
So those who had the same Problem parsing the incoming requests maybe
could tell me, if Regular Expressions are a good way, or making to
much problems.
I'd strongly recommend against trying to parse IMAP requests solely with
regular expressions. To cite just one obvious problem, you need to parse
arbitrarily-nested SEARCH expressions, and a regular expression can't do
that.
Maybe there's a better way. I'm not shure how to handle the incoming
messages.
Why not just write a simple recursive-descent parser by hand? You could,
for example, write functions to remove each type of token from the input
string, and then write things like:
if ( command() == RENAME )
parse_rename();
...
parse_rename( char **src, char **dst )
{
space();// Eat a space after the command name.
src = astring();// Eat a mailbox name.
space();// ...
dst = astring();
}
With suitable (simple) error handling, and translated to the language of
your choice. The grammar is small enough for this to be both easy to do,
and to maintain.
-- ams
Re: AUTH types
At 2003-12-27 09:57:38 +0100, [EMAIL PROTECTED] wrote: I've seen many Servers give an AUTH=LOGIN capability too; what is this? Could not find it in any specs... draft-murchison-sasl-login-00.txt -- ams
Re: What about /Recent?
At 2003-12-15 22:47:30 +0100, [EMAIL PROTECTED] wrote: So, I definitely need someone explain to me, what EXACTLY the behavior of this mysterious /Recent flag is. Most important to me - when is it cleared by the server? \Recent messages stay recent from the time of their announcement (by the untagged RECENT response) until the end of that client session (or until they are EXPUNGEd, of course). -- ams
Re: BODY.PEEK[HEADER] Server-Response
At 2003-12-09 14:19:40 +0100, [EMAIL PROTECTED] wrote:
S: * 1 FETCH (FLAGS (\FLAGGED) UID 4827313)
S: 003 OK UID FETCH completed
You're saying that MSN #1 has UID 4827313. OK.
(You might want to return UID before FLAGS. Some clients depend on UID
being the first item returned.)
After that the Netscape-Client send an another UID command:
C: 004 fetch 4827313 (UID RFC822.SIZE BODY.PEEK[HEADER] FLAGS)
and I thought 4827313 was the UID
Are you sure that's what the client sends?
It should either send tag FETCH 1 ... or tag UID FETCH 4827313 ...
in this case. The argument to plain FETCH is always an MSN, not a UID.
(The argument to UID FETCH is a UID, of course.)
the answer to this was :
S: * 4827313 FETCH (UID 4827313)
That contradicts the first (* 1 FETCH (UID ...)) response unless the
client send a UID FETCH.
S: * 4827313 FETCH (BODY.PEEK[HEADER]
S: Return-path: [EMAIL PROTECTED]
As others have pointed out, you need to send a literal and specify the
length {} before sending the header data, and there should be an
empty line at the end.
perhaps I should read it again.
Yes, perhaps you should.
-- ams
Re: PERMANENTFLAGS
At 2003-12-04 20:54:06 +0100, [EMAIL PROTECTED] wrote: is PERMANENTFLAGS a required response when a mailbox is selected ? Yes. -- ams
Re: Difference about LSUB and LIST
At 2003-12-02 13:20:04 +0100, [EMAIL PROTECTED] wrote: We're using RFC3501 to understand the protocol but we've got problems understanding the difference between LSUB and LIST. LSUB and LIST both return a list of mailboxes that match the specified condition. LIST considers all available mailboxes during the matching, while LSUB considers only those mailboxes that the user has SUBSCRIBEd to. There is no other difference. We're not shure how to reproduce the folder structure with the commands. I'm not sure I understand the question. Could you please explain? For more about LIST/LSUB, see RFC 2683 §3.2.1.1 and §3.2.1.2. -- ams
Re: SEARCH response(s)
At 2003-11-05 11:10:39 +0100, [EMAIL PROTECTED] wrote: Example:C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)]) S: * 4 FETCH S: * 8 EXPUNGE (Deleted from another client) S: * 2 FETCH S: * 3 FETCH S: A654 OK FETCH completed Servers are not allowed to send EXPUNGE while a FETCH/STORE/SEARCH is in progress (because they invalidate MSNs). See RFC 3501 §5.5 and §7.4.1. (Good examples are always a useful addition, of course.) -- ams
Re: Unusual behaviour
At 2003-10-29 09:41:14 -, [EMAIL PROTECTED] wrote: 006 STATUS INBOX (UNSEEN RECENT MESSAGES UIDVALIDITY UIDNEXT) * STATUS INBOX (UNSEEN 4 RECENT 0 MESSAGES 8 UIDVALIDITY 70 UIDNEXT 9 ) 006 OK STATUS completed That extra space before the closing ) in the STATUS response is wrong. -- ams
Re: Correct response when fetching an invalid message
At 2003-10-10 09:44:36 +0200, [EMAIL PROTECTED] wrote: Should the server send an untagged NO response and continue with processing the sequence with the final tagged OK response, or should it stop the processing immediately and issue a tagged NO response? I prefer the former behaviour in the interests of sending as much useful information to the client as possible in response to each question. Good clients will be happy. -- ams
Re: a synchronization issue
At 2003-09-11 08:39:20 -0700, [EMAIL PROTECTED] wrote: c2: aa store 2 +flags.silent (\Deleted) s : * 1 FETCH (FLAGS (\Deleted) UID 3) s : aa OK store The FETCH response is wrong. The change was to message 2, not message 1. Presumably you meant: c2: aa store 2 +flags.silent (\Deleted) s : * 2 FETCH (FLAGS (\Deleted) UID 4) s : aa OK store No. Note that C2 STOREs +FLAGS.SILENT, and is thus not sent an update of message #2's flags. The FETCH response is telling it about the change to message #1 by C1. -- ams
invalid search text
At 2003-08-27 12:53:21 +0900, [EMAIL PROTECTED] wrote: First, it seems that RFC 3501 is missing the definition of 'CHAR'. I think it defers to the definition in RFC 2234 (ABNF) for this and some other terminals (CR, LF, DIGIT, etc.). B1 SEARCH CHARSET UTF-8 TEXT 0x80 ? (Mozilla 1.4 is sending requests like the above). Should the server respond with a tagged BAD response? I think so. -- ams
Re: IMAP : Attachment Information
At 2003-08-20 16:38:56 +0530, [EMAIL PROTECTED] wrote: I am quite new to the IMAP protocol. RFC 3501 is your new best friend. Read it carefully; for answers to your questions, search for BODYSTRUCTURE and partial in the RFC. -- ams
Re: adult and spam/junk keywords
At 2003-07-03 09:07:21 -0700, [EMAIL PROTECTED] wrote: . $spam should not be used; SPAM is a trademark of Hormel Corp. (a fine company) for their highly-addictive lunch meat (which goes quite when when consumed with Dom Perignon) Hormel does not object to the use of spam as long as it's not all in upper case. http://www.spam.com/ci/ci_in.htm -- ams
Re: regarding email client design and IMAP commands.
At 2003-06-02 01:30:47 -0700, [EMAIL PROTECTED] wrote: I am designing an E-mail client and I am unable to give good design. That seems to be a common problem. :-) Your question, however, is not specific enough to answer usefully (and it is probably not entirely relevant to this list anyway). Perhaps the following pages will help you with the IMAP parts: * http://www.washington.edu/imap/documentation/commndmt.txt.html * http://dovecot.procontrol.fi/imap-client-coding-howto.html After deleting message, things are going on like this... 1. a copy of message is copied to trash from inbox. 2. a delete flag is set to inbox message. 1. The messages with delete flag in inbox will not be displyed. Is my understaing ok? What are you trying to understand? Your description, possibly along with expunge/undelete features, is one way for a client to behave in deleting messages. (But I suspect I'm misunderstanding your question somehow.) 1. when can i use CLOSE command? See RFC 3501, §6.4.2. You can use CLOSE whenever a mailbox is selected. If you don't want to expunge \Deleted messages, just select a different mailbox (or LOGOUT, or read about UNSELECT). 2. if i delete message from trash, what will happen? The same thing that happens when you delete messages in another mailbox. -- ams
Re: Why is a message immutable?
At 2003-03-19 07:32:25 -0800, [EMAIL PROTECTED] wrote: Newer clients will be able to make use of an update capability. To what end? -- ams
Re: Mairdir drag and drop
At 2003-03-09 12:39:52 +0100, [EMAIL PROTECTED] wrote: does the IMAP-standard allow a traditional unix hiearchie? IMAP requires only the left-to-right hierarchical nomenclature, and the single-character separator between levels (RFC 2060, section 5.1.1). The UNIX filesystem fits this model well, but servers may choose a different on-disk representation or separator as they wish. (Maildir and IMAP are not ideally suited to each other. For details, see http://www.washington.edu/imap/IMAP-FAQs/index.html#6.9) To what extent is drag and drop supported by the IMAP standard? It is not. Drag-and-drop is a matter purely for clients. -- ams
Re: Doubt on FETCH command
At 2003-02-10 20:11:01 -0800, [EMAIL PROTECTED] wrote: NIL is defined in RFC 2060, section 4.5. And the ENVELOPE response format is described in section 7.4.2. -- ams
Re: INTERNALDATE format
At 2003-02-02 15:00:38 +0530, [EMAIL PROTECTED] wrote: Is there any restriction on the format in which the string representing INTERNALDATE attribute of the message should be stored ? If yes, could someone help me find it on the RFC ? The date may be stored in any format, but the INTERNALDATE response must be a date_time, as defined by the grammar in RFC 2060. (Look for msg_att in the Formal Syntax section.) -- ams
Re: IMAP Store Query
At 2002-08-19 18:20:27, [EMAIL PROTECTED] wrote: RFC2060 has an error in the definition of data-value. The syntax allows the value to be empty, since '#flag' includes zero instances of flag. The only valid way to indicate no flags is to use an empty flag-list, that is, '()'. So should a IMAP server support an empty value? No. Has there been any updates on this part of RFC2060 after this? The latest draft (draft-crispin-imapv-17.txt) updates the grammar thus: flag-list = ( [flag *(SP flag)] ) store-att-flags = ([+ / -] FLAGS [.SILENT]) SP (flag-list / (flag *(SP flag))) - ams
