RE: FETCH Failure
Ah, but sequence numbers ARE a session characteristic. They can only be considered to be valid in the context of a single session. That's why there are so many silly rules about when you can change the session numbers and the consequences of that. Consider the EXISTS and EXPUNGE responses for example. EXISTS can be sent at any time - why? Because EXISTS adds entries to the end of the per-session set of sequence numbers, and you can always add to the end of an array without changing the meaning of the existing entries of the array. On the other hand, EXPUNGE can only be sent at a time when the server KNOWS the client is not evaluating a sequence number. Why? Because the EXPUNGE response changes the sequence number for every message in the mailbox FOR THAT SESSION. Those are the silly, nonsensical rules to which Mark was referring - they don't make any sense in the context of global sequence numbers, but make perfect sense when you consider sequence numbers as being a session characteristic. UIDs are cross session, IF (and only IF) the UIDVALIDITY is unchanged. And there ARE existing, compliant servers which will give a different UIDVALIDITY for every session (if the underlying message store is incapable of implementing UIDs). Larry Osterman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Wener Sent: Wednesday, September 29, 2004 5:27 AM To: [EMAIL PROTECTED] Subject: Re: FETCH Failure On Tue, 2004-09-28 at 22:00, Barry Leiba wrote: Why is this a better question? I consider one of the goals of specification to be reduced ambiguity. I would think that if there was expected behavior then it would be better to be written down? Hm. So, let's see: You'd expect to be able to open two FTP sessions to the same server, set the mode to binary in one session, transfer a file in the other session, and expect the mode to be binary, yes? I don't think the FTP spec says otherwise, so No. This is a classic apples to oranges comparison. A transfer mode is clearly a session characteristic. The session uses this information to operate on the data in transit. A better comparison would be state stored central to FTPs objects of operation, i.e. files. In the case of FTP the server is mirroring state about files on the server's file system. File state, while it can not be relied on to be correct the minute the server responds to an ls for example, it can be relied on to be consistent between sessions. I could envision multiple FTP clients working in concert where one did an ls and concurrent sessions then did gets. Note, I'm not arguing SNs should be session state. I'm convinced they are not. My consideration at the moment is only coordinated sessions. Sessions that are aware of each others logic and are behaving in concert. And do you know ANY Internet protocols where that happens? I'm not sure exactly what you are looking for, but I would point out RFC1990 goes in this direction. It is more important to note I'm not looking for, nor expecting, protocol help to share sessions. Mike
RE: FETCH Failure
Absolutely right, that's a subtlety I missed in my response. In particular, just because you have two sessions with the same UIDVALIDITY doesn't mean that you can use a UID from session 1 in session 2 - if you haven't seen the EXISTS response for that message, it doesn't exist. This is actually REALLY important - I suspect that some IMAP servers will let you get away with doing this, even though it's a violation of the protocol (in particular, I'm not sure that the Exchange 5.5 IMAP server would catch this protocol violation - it might, but it might not). Larry Osterman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Crispin Sent: Wednesday, September 29, 2004 12:34 PM To: Larry Osterman Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: FETCH Failure On Wed, 29 Sep 2004, Larry Osterman wrote: UIDs are cross session, IF (and only IF) the UIDVALIDITY is unchanged. And there ARE existing, compliant servers which will give a different UIDVALIDITY for every session (if the underlying message store is incapable of implementing UIDs). However, this cross-session characteristic is much less than Mike seems to expect. The fact that a UID is known to a session does not mean that it is known to another (even a simultaneous) session. There are many ways that a message can be known to one session but not another. UIDs only promise that a particular UID will not refer to two different messages. In other words, UIDs are a means by which an application can synchronize itself in a session using data from another (typically chronologically earlier) session. Sessions do not synchronize on their own, although simultaneous sessions will tend towards synchronization over time. File state, while it can not be relied on to be correct the minute the server responds to an ls for example, it can be relied on to be consistent between sessions. I just noticed this comment of Mike's. It's false, as anyone who has spent any non-trivial amount of time dealing with NFS can testify. Sad, but true. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
RE: how to set keyword ($Forwarded) on specific message?
That seems to be a protocol violation - PERMANENTFLAGS is always a
subset of FLAGS, no? My reading of that is that the only custom flag
that's supported on that folder is $Forwarded, I don't know what the \*
is doing there.
Larry Osterman
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of John Owens
Sent: Tuesday, September 14, 2004 4:25 PM
To: [EMAIL PROTECTED]
Subject: how to set keyword ($Forwarded) on specific message?
Greetings,
I am trying to migrate mail folders from standard mbox format into
IMAP. I would like to preserve their flags if possible (replied,
forwarded, etc.). I have been able to preserve replied, but I have not
been able to preserve forwarded.
First, I'm confident that my server supports forwarded:
* FLAGS ($Forwarded \Answered \Flagged \Deleted \Draft \Seen)
* OK [PERMANENTFLAGS ($Forwarded \* \Answered \Flagged \Deleted \Draft
\Seen)] Permanent flags
and even on other mailboxes that don't have a forwarded message, \* is
defined in PERMANENTFLAGS, so I think I'm good to go.
Now, in my migration code (a python script) I log into the IMAP
reading one message at a time. I log into the IMAP server,
then parse a mbox and read one message at a time. I have not SELECTed
a particular mailbox, but I'm not sure I have to. I'm then using the
APPEND command to append the message to the mailbox. APPEND takes the
mailbox name as an argument, and also the flag list and the message.
I can set that flag list to \Answered and it works fine:
\Answered
('OK', ['APPEND completed'])
But I can't set it to $Forwarded:
$Forwarded
('NO', ['APPEND failed: Unknown flag: $Forwarded'])
and I'm at a loss as to what to do. I believe this has something to do
with $Forwarded being a keyword, but I don't know how to set a
keyword. I'd like to at least try to use STORE to set the flag
manually, but I don't have the UID for the message I just APPENDed.
Since I'm an IMAP rookie, I'm happy to have help from this community;
if you could a) offer suggestions to fix what I've done wrong so I can
store $Forwarded, and b) offer suggestions as to how you'd accomplish
this task in a better way than I've designed, I'd be much obliged.
Thanks!
JDO
--
-
For information about this mailing list, and its archives, see:
http://www.washington.edu/imap/imap-list.html
-
--
-
For information about this mailing list, and its archives, see:
http://www.washington.edu/imap/imap-list.html
-
RE: strange response to message part fetch command
That's highly unlikely given how the Exchange 2000 store treats MIME messages. Was the message in question a pure MIME message (in other words did it come from an SMTP client) or did it originate with an Outlook (MAPI) client? Larry Osterman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete Maclean Sent: Wednesday, August 25, 2004 8:20 AM To: Pawel Salek; [EMAIL PROTECTED] Subject: Re: strange response to message part fetch command At 04:30 AM 8/25/2004, Pawel Salek wrote: Hi, I encountered a strange response to message part fetch command. It looks like a bug in the server to me but I would like to get a second opinion. Suggestions how to work around this problem are welcome too. The problem is the server promises to send 23824 octects long literal but sends 4040+ characters and happily announces the processing has finished (sanitized log below). Any clues? Could it be that the server is counting 23824 as the size of the body part prior to base64 encoding? Encoding 23824 octets in base64 would typically result in slightly less than 4040 characters but it depends of course on the line length used. It would be a bad bug but, in a sense, an understandable one. Pete Maclean
RE: strange response to message part fetch command
Yup, that's enough. It came from an external client. It might be interesting to see if you could get the entire original message. I know there are Exchange people on the list. Larry Osterman -Original Message- From: Pawel Salek [mailto:[EMAIL PROTECTED] Sent: Thursday, August 26, 2004 1:23 PM To: Larry Osterman Cc: [EMAIL PROTECTED] Subject: Re: strange response to message part fetch command On 08/26/2004 10:03:59 PM, Larry Osterman wrote: That's highly unlikely given how the Exchange 2000 store treats MIME messages. Was the message in question a pure MIME message (in other words did it come from an SMTP client) or did it originate with an Outlook (MAPI) client? I see there headers: Received: from xxx ([yyy]) by with Microsoft SMTPSVC (5.0.2195.5329); Mon, 23 Aug 2004 16:09:23 +0100 Received: from [vvv] (Not Verified[uuu]) by xxx with NetIQ MailMarshal (v5.5.6.7) id Ba8cc7; Mon, 23 Aug 2004 16:09:22 +0100 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Is it enough to answer your question? I see NetIQ MailMarshal is available in both SMTP and for Exchange variants. Pawel -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete Maclean Sent: Wednesday, August 25, 2004 8:20 AM To: Pawel Salek; [EMAIL PROTECTED] Subject: Re: strange response to message part fetch command At 04:30 AM 8/25/2004, Pawel Salek wrote: Hi, I encountered a strange response to message part fetch command. It looks like a bug in the server to me but I would like to get a second opinion. Suggestions how to work around this problem are welcome too. The problem is the server promises to send 23824 octects long literal but sends 4040+ characters and happily announces the processing has finished (sanitized log below). Any clues? Could it be that the server is counting 23824 as the size of the body part prior to base64 encoding? Encoding 23824 octets in base64 would typically result in slightly less than 4040 characters but it depends of course on the line length used. It would be a bad bug but, in a sense, an understandable one. Pete Maclean
RE: shared mailbox permanent flags?
Title: RE: shared mailbox permanent flags? Ah, you're right - I forgot about \Recent. \Recent is "special" since it's not a "real" flag. From: Pete Maclean [mailto:[EMAIL PROTECTED]Sent: Wed 8/18/2004 2:48 PMTo: Larry Osterman; petite_abeille; [EMAIL PROTECTED]Subject: RE: shared mailbox permanent flags? I think that either what you say is not quite correct or I am notunderstanding it right. RFC 3501 gives an example of a FLAGS response thatdoes not include all the system/built-in flags:Example: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)In this case, \Recent is missing. As I read the spec, if you do notinclude a particular system flag in this response, it means that you do notsupport it for the mailbox. Incidentally, some versions of my server donot support \Recent at all.Pete MacleanAt 05:09 PM 8/18/2004, Larry Osterman wrote:You MUST support ALL the built-in flags on every mailbox. You might notbe able to persist those flag settings, but you MUST support them on aper-session basis.-Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of petite_abeilleSent: Wednesday, August 18, 2004 2:00 PMTo: [EMAIL PROTECTED]Subject: Re: shared mailbox permanent flags?Hi Timo,On Aug 18, 2004, at 22:37, Timo Sirainen wrote: FLAGS list shouldn't be empty. It should contain at least the system flags.Ok. So FLAGS should always returns \Answered \Deleted \Draft \Flagged\Recent and \Seen? Even if they are not applicable for such mailbox? But this doesn't seem to help :/ Yep. I doubt there's a way to make it work many (if any) clients.Sigh :/PA.
RE: shared mailbox permanent flags?
The simplest way of doing this is to turn the system flags into bit fields and add a 6 or so bits per message to your per-session in-memory list of messages (you do have an in-memory list of messages, right?) Then as the user does store and fetch of the flags, you just flip the bits on and off in the per-session in-memory list. Larry Osterman From: Pete Maclean [mailto:[EMAIL PROTECTED] Sent: Thursday, August 19, 2004 1:29 PM To: Larry Osterman; [EMAIL PROTECTED] Subject: RE: shared mailbox permanent flags? Thanks, Larry. I too forgot about the specialness of \Recent when I wrote that message. My misunderstanding about the other flags is a different matter though. For the entire four or so years that I have been working with IMAP up until yesterday I was confidently convinced that a server was not obliged to handle system flags that it could not manage as PERMANENTFLAGS. I was quite distressed to realize my error. Fortunately, in spite of this, my server does handle such flags correctly (well, I hope correctly -- see below) with the exception of \Recent. And that I shall fix. I am now struggling to make sure that I properly understand all the implications of system-flag handling so that I can confirm that my code is indeed correct. For a start, a server must list all the system flags (except \Recent) in a FLAGS response to every successful SELECT or EXAMINE (even though that seems redundant). RFC 3510 section 7.1 states that, If the client attempts to STORE a flag that is not in the PERMANENTFLAGS list, the server will either ignore the change or store the state change for the remainder of the current session only. Now, I suppose that ignoring such a change could be deemed a reasonable strategy because one could argue that it is effectively equivalent to storing the change only to have another party immediately do a STORE that reverses it. However, if a server adopts that strategy, it is equivalent to its not handling the flag at all (except to the extent that it does not consider a STORE for the flag to be an error). So it must advertise that it supports the flag even though it really does not. Now, what if a server stores the state change for the remainder of the current session only. Does that mean it stores it *for* the current session only? I presume so because anything else could be a nightmare. This suggests that, if the same client creates a second session and selects the same mailbox, it could see different flag states from the first. Granted, opening such a second session is probably an ill-advised venture to begin with (although I have seen it happen) so this inconsistency is hardly a big deal -- never mind that it is something that a properly functioning client should be prepared for. By contrast to all this, my reading of the RFC is that, when the \Seen flag is set implicitly (by virtue of an appropriate FETCH), it must be indeed be set; there is no option. Now, a server could choose not to set it and hold forth the same argument as above (that the flag could be instantly reset by a third party) but that argument breaks down because, if the flag is effective only for the session involved, then in practice nothing external could sensibly change it. This all seems a bit of a mess. What I have said may sound somewhat critical and that may be because I am rather peeved at my own misunderstanding. My prime intention in writing this message though is solely to make sure that I now do understand this well. Pete Maclean At 12:01 PM 8/19/2004, Larry Osterman wrote: Ah, you're right - I forgot about \Recent. \Recent is special since it's not a real flag. From: Pete Maclean [mailto:[EMAIL PROTECTED]] Sent: Wed 8/18/2004 2:48 PM To: Larry Osterman; petite_abeille; [EMAIL PROTECTED] Subject: RE: shared mailbox permanent flags? I think that either what you say is not quite correct or I am not understanding it right. RFC 3501 gives an example of a FLAGS response that does not include all the system/built-in flags: Example: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) In this case, \Recent is missing. As I read the spec, if you do not include a particular system flag in this response, it means that you do not support it for the mailbox. Incidentally, some versions of my server do not support \Recent at all. Pete Maclean At 05:09 PM 8/18/2004, Larry Osterman wrote: You MUST support ALL the built-in flags on every mailbox. You might not be able to persist those flag settings, but you MUST support them on a per-session basis. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of petite_abeille Sent: Wednesday, August 18, 2004 2:00 PM To: [EMAIL PROTECTED] Subject: Re: shared mailbox permanent flags? Hi Timo, On Aug 18, 2004, at 22:37, Timo Sirainen wrote: FLAGS list shouldn't be empty. It should contain at least the system flags. Ok. So FLAGS should always returns \Answered \Deleted \Draft \Flagged
RE: shared mailbox permanent flags?
Actually if you set FLAGS to non empty and PERMANENTFLAGS to empty, all the clients should work. You need to maintain flags in-memory even if you can't persist them (it's in the spec), but most (if not all) clients handle the non persistence correctly (if you think about it, they won't know the difference typically). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Timo Sirainen Sent: Wednesday, August 18, 2004 1:37 PM To: petite_abeille Cc: [EMAIL PROTECTED] Subject: Re: shared mailbox permanent flags? On 18.8.2004, at 23:28, petite_abeille wrote: Returning empty PERMANENTFLAGS list is your best bet. Although probably no clients actually do it. I already do that for anonymous access: * FLAGS () * OK [PERMANENTFLAGS ()] FLAGS list shouldn't be empty. It should contain at least the system flags. But this doesn't seem to help :/ Yep. I doubt there's a way to make it work many (if any) clients.
RE: shared mailbox permanent flags?
You MUST support ALL the built-in flags on every mailbox. You might not be able to persist those flag settings, but you MUST support them on a per-session basis. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of petite_abeille Sent: Wednesday, August 18, 2004 2:00 PM To: [EMAIL PROTECTED] Subject: Re: shared mailbox permanent flags? Hi Timo, On Aug 18, 2004, at 22:37, Timo Sirainen wrote: FLAGS list shouldn't be empty. It should contain at least the system flags. Ok. So FLAGS should always returns \Answered \Deleted \Draft \Flagged \Recent and \Seen? Even if they are not applicable for such mailbox? But this doesn't seem to help :/ Yep. I doubt there's a way to make it work many (if any) clients. Sigh :/ PA.
RE: FLAGS vs PERMANENTFLAGS
Honestly, it looks like it could be Exchange 5.5, but I'm not sure - the UIDVALIDITY value seems higher than I'd expect for Exchange. Also, I don't remember 5.5 supporting UID+ so... Larry Osterman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Arnt Gulbrandsen Sent: Friday, August 06, 2004 4:58 AM To: Stuart Nicholson Cc: [EMAIL PROTECTED] Subject: Re: FLAGS vs PERMANENTFLAGS Stuart Nicholson writes: However I would expect folders that can't be modified to have the READ-ONLY property surely? We see things like this (taken from a user log): 0003 SELECT INBOX[0x0D][0x0A] * 40 EXISTS * 0 RECENT * OK [UIDVALIDITY 1012731894] UID validity status * OK [UIDNEXT 7880] Predicted next UID * FLAGS (\Answered \Flagged \Deleted \Draft \Seen) * OK [PERMANENTFLAGS ()] Permanent flags * OK [UNSEEN 8] first unseen message in INBOX 0003 OK [READ-WRITE] SELECT completed And the user complains that other clients allow FLAGS to be set and they are set permanently (over sessions) which seems to violate the RFC, at least as I understood it. May I ask which server that is? I'm beginning to think given our short session times and rigid session model (i.e. we always sync the message flags at start of session), there's really little point in us honouring PERMANENTFLAGS at all. Does your client refuse to set session flags? Why? Arnt
RE: FLAGS vs PERMANENTFLAGS
That behavior (empty permanentflags but flags) is explicitly allowed. And if you read the spec VERY carefully you'll find it's REQUIRED if the user can't modify the folder. The server maintains flags, but they aren't persisted. Think of it this way: FLAGS is the set of flags supported by the server. PERMENANTFLAGS is the set of flags that will be persisted in the server's database. FLAGS is necessarily a superset of PERMENANTFLAGS, but they are different and have different meanings. Larry Osterman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stuart Nicholson Sent: Friday, August 06, 2004 11:16 AM To: [EMAIL PROTECTED] Subject: FLAGS vs PERMANENTFLAGS Greetings, my first post here so an brief intro: I'm the developer building IMAP client support for SnapperFish. We're responsible for 'SnapperMail' (www.snappermail.com) a wireless email client for PalmOS based devices. Question: How well honoured are FLAGS vs PERMANENTFLAGS in the IMAP community? Is PERMANENTFLAGS overdesign that actually isn't used in the wild that often? Do other clients actually only honour FLAGS and disregard PERMANENTFLAGS? Is ask beause our IMAP client is currently coded closely to RFC3501 in this respect however we've received a number of reports from users of servers that persistently return empty (i.e. PERMANENTFLAGS ()) responses while still allowing the flags in FLAGS to be permanently set on messages in the mailbox. This seems in direct violation to the RFC however other IMAP clients happily set flags on these particular servers. Is it worth just relaxing our client on this point hence disregarding PERMANENTFLAGS and simply relying on FLAGS and the READ-WRITE/READ-ONLY folder property? Thanks, Stuart Nicholson www.snappermail.com -- - For information about this mailing list, and its archives, see: http://www.washington.edu/imap/imap-list.html - -- - For information about this mailing list, and its archives, see: http://www.washington.edu/imap/imap-list.html -
RE: UIDVALIDITY response optional?
Thanks for correcting me Mark :) It's been too many years :( Larry Osterman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Crispin Sent: Thursday, May 27, 2004 4:43 PM To: Larry Osterman Cc: Pete Maclean; [EMAIL PROTECTED] Subject: RE: UIDVALIDITY response optional? On Thu, 27 May 2004, Larry Osterman wrote: I believe that if you don't return UIDVALIDITY, it means that the server doesn't support persistent UID's. UIDs are still supported, but they won't persist from one select to another. No, UIDVALIDITY is required from an IMAP4 and IMAP4rev1 server. If UIDs are not persistent, then UIDVALIDITY is returned as a session-specific value which is undefined but is greater than the value returned from a previous session. The 32-bit UNIX format date/time of SELECT time is a good value to use for this. Note that since UIDVALIDITY is unsigned, this doesn't need to be fixed in 2038 but can wait until 2106. Since I fully intend to be dead in 2106 (I'd be 150 years old otherwise) I'm not going to worry about how to fix it... :-) -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
RE: Content-type and Exchange 2000
At a first blush, it looks like the 5.5 server's configured to render MAPI messages in text/plain by default and the Exchange 2000 server's configured to render MAPI messages in text/html, but I may be wrong. Larry Osterman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of HEARSON, CHRIS Sent: Tuesday, April 20, 2004 5:55 AM To: '[EMAIL PROTECTED]' Subject: Content-type and Exchange 2000 I open a mail message (.msg file) in Outlook 2000 pointing to an Exchange 5.5 server, the BODYSTRUCTURE command returns: (TEXT PLAIN (charset iso-8859-1) NIL NIL QUOT ED-PRINTABLE 149 3 NIL NIL NIL)) The exact same .msg file, opened in the same client but now pointing to an Exchange 2000 mail server, and the BODYSTRUCTURE command returns: (TEXT HTML (charset iso-8859-1) NIL NIL QUOT ED-PRINTABLE 149 3 NIL NIL NIL)) What is going on here? _ *** E-Mail confidentiality notice *** This message and any attachments are intended for the addressee only. It is private and confidential. If you have received this message in error, please reply to this e-mail and highlight the error and then remove it from your system. You must take no action based on this, nor must you copy or show this to anyone. _ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Scanning Service. For further information visit http://www.star.net.uk/stats.asp or alternatively call Star Internet for details on the Virus Scanning Service. -- - For information about this mailing list, and its archives, see: http://www.washington.edu/imap/imap-list.html -
RE: Unsolicited messages vs. NOOP
This is totally correct - part of the contract for IDLE is that the client guarantees that there is a recv() outstanding. 5.3 isn't superfluous however, it's what spells this behavior out in protocol terms (my comment was in sockets terms, which doesn't apply if IMAP is implemented on protocols other than TCP/IP) Larry Osterman -Original Message- From: Christof Drescher [mailto:[EMAIL PROTECTED] Sent: Thursday, January 08, 2004 12:30 PM To: Larry Osterman Cc: [EMAIL PROTECTED] Subject: Re: Unsolicited messages vs. NOOP Hi, thank you for your message. Makes things clearer (technically). The problem is that a server can't send data to a client until it can GUARANTEE that the client has a recv() outstanding on the socket. Otherwise it's possible that the servers send() command will block (this happens when the TCP buffers on the client fill up, which causes the client to flow control the connection, then the TCP buffers on the server fill up, then sockets will cause the send() command to hang until all the downstream buffers are freed up). Just wondering: A server can never GUARANTEE that a client as a recv() outstanding on the socket while no command is in progress, can it? Since no client can tell the server that it DOES a recv() by any means, it must assume that there is NO outstanding recv(), right? If so, the whole paragraph 5.3 about it would simply be superfluous, wouldn't it? I really don't mind, I have my answer (sending updates just as a response to client commands in progress seems the way). In addition, you about the only unsolicited status updates you can send to the client are EXISTS, RECENT and FLAGS updates, EXPUNGE updates are absolutely verboten. And if you ever get to the point where you would want to send an EXPUNGE update, you need to stop sending updates to the client because the sequence numbers would get out of date with after this. Wow, we just had the topic about EXPUNGE, which must not be sent at FETCH/EXISTS/SEARCH, but may be sent on any other command. This was never doubted. Do you? Christof
RE: Unsolicited messages vs. NOOP
Please define unsolicited server status updated? Do you mean that your server is simply sending the message to the client unilaterally (not in response to a user command)? If that's the case, you're going to deadlock your server pretty darned soon if you keep on doing it. The problem is that a server can't send data to a client until it can GUARANTEE that the client has a recv() outstanding on the socket. Otherwise it's possible that the servers send() command will block (this happens when the TCP buffers on the client fill up, which causes the client to flow control the connection, then the TCP buffers on the server fill up, then sockets will cause the send() command to hang until all the downstream buffers are freed up). In addition, you about the only unsolicited status updates you can send to the client are EXISTS, RECENT and FLAGS updates, EXPUNGE updates are absolutely verboten. And if you ever get to the point where you would want to send an EXPUNGE update, you need to stop sending updates to the client because the sequence numbers would get out of date with after this. Larry Osterman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christof Drescher Sent: Wednesday, January 07, 2004 3:30 PM To: [EMAIL PROTECTED] Subject: Unsolicited messages vs. NOOP Hi, When testing with a couple of clients, I found that some do not really work well with unsolicited server status updates, e.g. flag updates or an * n EXISTS message. It seems their preferred way is their regular update via NOOP. Is this a general thing? Should the strategy be to only send immediate notification to clients which use the IDLE command, and none to those which do not (i.e., wait for them to poll via NOOP?) E.g. Mulberry or PC-Pine (those I just tested) do simply ignore those messages, and even worse, they are lost for the next noop (pine catches up fine, but mulberry never gets it, only at re-login). So what would you suggest? - sending unsolicited commands nevertheless, because the clients are weird? :) - sending no unsolicited commands at all, only at noop? - sending unsolicited commands, and repeating them at the next noop (uhm...) Any comments would be appreciated. Christof -- - For information about this mailing list, and its archives, see: http://www.washington.edu/imap/imap-list.html - -- - For information about this mailing list, and its archives, see: http://www.washington.edu/imap/imap-list.html -
RE: Multiple command clarification.
Christof, as the author of the well-known server (there, I gave it away), the ghost messages that it returns are valid w.r.t. FLAGS, but when you attempt to fetch a body part, it returns NIL (or an envelope containing only NILs) etc. Our problem was that our message store doesn't have the ability for the IMAP server to add a reference to a message when it hands the message out to the IMAP clients, thus if another user using another client (maybe a POP3 client, maybe a MAPI/RPC client, maybe a HTTP/DAV client, maybe an OLEDB client) deletes the message, then it's gone. There's no way to hold onto the message for the IMAP client, given the store limitations. If it were possible in the message store, we would have done this, the server caches the mailbox state (flags, message list, message UIDs) for eache client connecting to the server so adding the reference wouldn't have been a big deal, and I'd have put code in to fix this in a heartbeat. Btw, you were earlier objecting to maintaining per-client state of the messages that have been given to the client, this is a flat-out requirement of IMAP - the server MUST maintain a list that contains: The messages that the client has been told about The message sequence #s of those messages The UIDs of those messages The FLAGS for those messages (this is critical for read-only mailboxes) This isn't called out explicitly in the specification, but there are MUST requirements in several places that add up to this requirement. I don't know of ANY successful IMAP server that doesn't do this. Larry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christof Drescher Sent: Friday, January 02, 2004 1:50 PM To: Mark Crispin Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Multiple command clarification. Hi, A well-known server implements 4.1.3 (dummy messages), and in practice, it seems to work out. Either the client caches and doesn't ask questions that would show the server is inconsistent, or the client doesn't cache and doesn't know the server is inconsistent. That is, there's a problem, but both of the likely client implementations tend to cover it up quite nicely. I agree that 4.1.3 is less objectionable than 4.1.2; it delivers less of a surprise, and most clients probably wouldn't even recognize that they were surprised. Though it might seem so, I'm not a stubborn dumb mule. I just want a usable solution. So I could also live with these ghost messages. What about stating something like ghost messages (as defined in RFC2180) are a valid response, which should force clients to NOOP to catchup. I just want clarification for the issue, be it a NO [NOOPFIRST] Fetch response or valid NIL message response. Huh? Christof
RE: Assumption of hierarchy?
Absolutely. It's entirely possible that you can have hierarchy without there being folders in the middle. Consider Netnews. Alt.Fan doesn't exist, but Alt.Fan.Mark.Crispin might. With Exchange, this could happen if you have access to Public Folders/Busi 3923C2/Carisa Lloyd but you don't have access to Public Folders/Busi 3923C2 - if you can't SELECT the mailbox, Exchange won't show it to you. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Harris Sent: Tuesday, January 06, 2004 2:12 AM To: [EMAIL PROTECTED] Subject: Assumption of hierarchy? OK, this one has me stumped. Imagine that as a client you get this as part of a response to a LIST command: -- Cut here * LIST () / Public Folders/Busi 3923C2/Carisa Lloyd -- Cut here Is it legal to receive this response without also at some point receiving this as well? -- Cut here * LIST () / Public Folders/Busi 3923C2 -- Cut here In other words, can a LIST response implicitly create a level of hierarchy? If so, how can you know what attributes the implicit hierarchy element has without specifically re-querying for it? I'm currently seeing this behaviour from Exchange Server 2003, and it's throwing out my code quite severely. Before I add a lot of code to handle this, I want to be sure that it's legal and that I'm not just creating a rod for my back at some later stage. If this *is* legal, I really think the RFC needs to be updated to reflect it, because I hardly think it can be considered intuitive. Cheers! -- David -- -- David Harris -+- Pegasus Mail -- Box 5451, Dunedin, New Zealand | e-mail: [EMAIL PROTECTED] Phone: +64 3 453-6880 | Fax: +64 3 453-6612 Sign seen at a tailor's in Rhodes: Order your summers suit. Because is big rush, we will execute customers in strict rotation. -- - For information about this mailing list, and its archives, see: http://www.washington.edu/imap/imap-list.html -
RE: Children flags, RFC3348.
Because at the first IMC face-to-face, a number of client authors said: Hey, it would be REALLY nice if you added this feature to the protocol, Mike Gharns said Sure, I'll write it up, and I said Ok, I'll put it in. So we did. And a couple of people added support for it and. It turns out that the documentation for LIST explicitly says that you can have whatever flags you wanted (read the spec carefully) so there was no need for a new variant of LIST. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Harris Sent: Saturday, January 03, 2004 2:52 PM To: [EMAIL PROTECTED] Subject: Children flags, RFC3348. OK, Arnt Gulbransen has pointed me at RFC3348, which covers the CHILDREN extension (thanks Arnt). What I want to know now is why is the Exchange server using this extension?. Consider this text from RFC3501 section 7.2.1 (CAPABILITY response, page 67 in my copy): -- Cut here Other capability names indicate that the server supports an extension, revision, or amendment to the IMAP4rev1 protocol. Server responses MUST conform to this document until the client issues a command that uses the associated capability. -- Cut here Now, I have issued *no* command other than LIST in this session: am I wrong in thinking that the Exchange server is behaving improperly by sending LIST responses that contain HasChildren and HasNoChildren flags in them? Surely I should need to issue the command CHILDREN (or whatever) before this extension is enabled? RFC3348 does not appear to me to be a formal revision of RFC3501 (or of 2060, for that matter) - its status is informational. I don't want to sound anal about this, but it seems to me that a major aspect of IMAP has always been ensuring interoperability, and injudicious use of extensions in this manner is not conducive to that. In this case it's probably relatively harmless, but I can think of plenty of situations where it would not be. Or am I simply misunderstanding this issue? Is it in fact legal for a server to issue any response it wants in this case? Cheers! -- David -- -- David Harris -+- Pegasus Mail -- Box 5451, Dunedin, New Zealand | e-mail: [EMAIL PROTECTED] Phone: +64 3 453-6880 | Fax: +64 3 453-6612 Thought for the day: Erotic (adj): using a feather as a sex aid. Kinky (adj): using the whole duck. -- - For information about this mailing list, and its archives, see: http://www.washington.edu/imap/imap-list.html -
RE: Trailing hierarchy delimiter in name
The trailing / indicates that the mailbox in question is a hierarchy-only mailbox, it can't contain messages iirc. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Harris Sent: Sunday, January 04, 2004 6:23 PM To: [EMAIL PROTECTED] Subject: Trailing hierarchy delimiter in name I'm sure that this must be covered somewhere in RFC3501, but I can't find it, so I'd appreciate some guidance... Consider the following LIST response from an IMAP server, where the hierarchy delimiter is '/': * LIST (\\Noselect) / Public Folders/ How should the trailing hierarchy delimiter on the mailbox name be interpreted? Does it have a special meaning of some kind? I can find the section covering the semantics of this for CREATE commands, but I can't see anything indicating what this would mean in a LIST response. Any assistance would be appreciated. Cheers! -- David -- -- David Harris -+- Pegasus Mail -- Box 5451, Dunedin, New Zealand | e-mail: [EMAIL PROTECTED] Phone: +64 3 453-6880 | Fax: +64 3 453-6612 On the menu in a Chinese Restaurant: We hope you will enjoy our hostility. -- - For information about this mailing list, and its archives, see: http://www.washington.edu/imap/imap-list.html -
RE: Assumption of hierarchy?
Before someone mentions \NoSelect - you not might have folder visibility access to Public Folders/Busi 3923C2 - which means that even though the folder exists, you can't enumerate it. Exchange has the concept of per-folder (and per-message) visibility as enforced by the Visible ACE flag, what that means is that it's possible that if the following folder hierarchy exists: a - User:RV a\b - User: a\b\c - User:RV a\d - User:RV The user will only see a and a\b\c in the folder hierarchy, a\b won't show up, since the client can't see it. If you were using Outlook, then if you opened a, you'd see only d. If, however someone mailed you a link to a\b\c you'd be able to navigate to that folder. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Larry Osterman Sent: Tuesday, January 06, 2004 7:14 AM To: David Harris; [EMAIL PROTECTED] Subject: RE: Assumption of hierarchy? Absolutely. It's entirely possible that you can have hierarchy without there being folders in the middle. Consider Netnews. Alt.Fan doesn't exist, but Alt.Fan.Mark.Crispin might. With Exchange, this could happen if you have access to Public Folders/Busi 3923C2/Carisa Lloyd but you don't have access to Public Folders/Busi 3923C2 - if you can't SELECT the mailbox, Exchange won't show it to you. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Harris Sent: Tuesday, January 06, 2004 2:12 AM To: [EMAIL PROTECTED] Subject: Assumption of hierarchy? OK, this one has me stumped. Imagine that as a client you get this as part of a response to a LIST command: -- Cut here * LIST () / Public Folders/Busi 3923C2/Carisa Lloyd -- Cut here Is it legal to receive this response without also at some point receiving this as well? -- Cut here * LIST () / Public Folders/Busi 3923C2 -- Cut here In other words, can a LIST response implicitly create a level of hierarchy? If so, how can you know what attributes the implicit hierarchy element has without specifically re-querying for it? I'm currently seeing this behaviour from Exchange Server 2003, and it's throwing out my code quite severely. Before I add a lot of code to handle this, I want to be sure that it's legal and that I'm not just creating a rod for my back at some later stage. If this *is* legal, I really think the RFC needs to be updated to reflect it, because I hardly think it can be considered intuitive. Cheers! -- David -- -- David Harris -+- Pegasus Mail -- Box 5451, Dunedin, New Zealand | e-mail: [EMAIL PROTECTED] Phone: +64 3 453-6880 | Fax: +64 3 453-6612 Sign seen at a tailor's in Rhodes: Order your summers suit. Because is big rush, we will execute customers in strict rotation. -- - For information about this mailing list, and its archives, see: http://www.washington.edu/imap/imap-list.html -
RE: Extension for status updates of non-selected mailboxes?
TCP connections are NOT cheap, and do not scale infinitely. When you have 30,000 clients connected to your IMAP server (a very reasonable number for a large farm), and each of them is opening 10 mailboxes, you're talking 300,000 sockets in use. That will tax the limits of ANY operating system. Microsoft puts 8K users on each of it's Exchange servers, so seeing 30,000 clients on a single box is NOT unreasonable, especially at ISP email levels (Microsoft people tend to receive 100+ emails a day and send 30+, which is significantly higher than ISP clients). Larry Osterman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Arnt Gulbrandsen Sent: Wednesday, December 17, 2003 2:34 AM To: Christof Drescher Cc: IMAP protocol mailing list; DINH Viet Hoa Subject: Re: Extension for status updates of non-selected mailboxes? Christof Drescher writes: Why not select all the interesting mailboxes to poll (in different sessions) and NOOP them or use IDLE extension. Because this creates an enourmous overhead in connections, server workload etc. Let's assume we have only 10 mailboxes shared with a workgroup of 20 users, you'd have 200 open connections on the server for simple new-mail-notification?! And these are small numbers... TCP connections are cheap, once opened. And even opening can be cheap, depending on whether you're using TLS or not and what sort of authentication you're using. A worse problem is that a client can use this method only if it knows the server supports concurrent access to all of the relevant mailboxes. If the server doesn't, only one of the 20 users can observe new mail in each shared folder. --Arnt
RE: Extension for status updates of non-selected mailboxes?
There are servers that can't support concurrent access to mailboxes - read Barry Lieba's best practices document on concurrent mailbox accesses. Larry Osterman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christof Drescher Sent: Wednesday, December 17, 2003 2:56 AM To: Arnt Gulbrandsen Cc: [EMAIL PROTECTED] Subject: Re: Extension for status updates of non-selected mailboxes? Arnt Gulbandsen wrote: TCP connections are cheap, once opened. And even opening can be cheap, depending on whether you're using TLS or not and what sort of authentication you're using. It might be cheap for modern pc systems and only concerning the Network overhead. But for one, there are much smaller systems today (PDS's, Smartphones, Embedded Devices) which certainly use IMAP, and for the other, the server has to keep this number of connections open as well, which might - depending on implementation - be much mor costly than the mere network connection. A worse problem is that a client can use this method only if it knows the server supports concurrent access to all of the relevant mailboxes. If the server doesn't, only one of the 20 users can observe new mail in each shared folder. Puzzles me: Isn't a server broken if it does not?!?! Christof
RE: Extension for status updates of non-selected mailboxes?
On NT, 300,000 TCP connections that are idle means that 300,000 socket handles are open. On *nix, it means that 300,000 processes are running. This is a big deal. There's more to large systems engineering than network bandwidth. Larry Osterman -Original Message- From: Arnt Gulbrandsen [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 17, 2003 11:48 AM To: Larry Osterman Cc: Christof Drescher; IMAP protocol mailing list; DINH Viet Hoa Subject: Re: Extension for status updates of non-selected mailboxes? Larry Osterman writes: TCP connections are NOT cheap, and do not scale infinitely. When you have 30,000 clients connected to your IMAP server (a very reasonable number for a large farm), and each of them is opening 10 mailboxes, you're talking 300,000 sockets in use. That will tax the limits of ANY operating system. I'm not saying the total cost of IMAP clients is low, merely that the cost of idle TCP connections is. (Note: Idle.) 300,000 TCP connections with an average of four packets per hour is not a very difficult task, if that's all there is. Now, if you talk about watching 300,000 mailboxes on behalf of 30,000 users using one piece of hardware, that's a much more challenging job. --Arnt
RE: fetch + seen flag
Title: Re: fetch + seen flag Remember my comment the other day about flags being maintained? It was on a read-only mailbox that this became obvious - iirc, Outlook Express had fits when it tried to set the \Seen flag on a message and the change didn't take (because the mailbox was read-only). If you look very carefully at the spec (and you need to look VERY carefully), it turns out that you MUST maintain the flags on a read-only mailbox even if they're not persisted. From: [EMAIL PROTECTED] on behalf of Mark CrispinSent: Thu 12/11/2003 4:29 PMTo: DINH Viet HoaCc: [EMAIL PROTECTED]Subject: Re: fetch + seen flag On Fri, 12 Dec 2003, DINH Viet Hoa 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 of a file failes). What should the server respond: 0. whatever, the server is already broken; 1. tagged OK without status of the flags; 2. tagged OK with status of the flags but with flag \seen unset; 3. tagged NO or 4. other response? (0) is the answer. :-) and in the case the mailbox is readonly, what is the answer ?Readonly doesn't matter. Only PERMANENTFLAGS matter.A mailbox can be readonly but still allow the user to set and clear flags(e.g. per-user flags for a public mailbox).-- Mark --http://staff.washington.edu/mrcScience does not emerge from voting, party politics, or public debate.Si vis pacem, para bellum.
RE: BODY.PEEK[HEADER] Server-Response
Of course it doesn't work. Since when has ANY penis enlargement product sold over the internet ever worked? Sorry, I just HAD to get this in :) I apologize for cluttering your inboxes with lame attempts at humor. Larry Osterman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chun-Ping Man Sent: Tuesday, December 09, 2003 2:42 AM To: [EMAIL PROTECTED] Subject: BODY.PEEK[HEADER] Server-Response Hello, I get the following UID client-command: C: 004 fetch 4827313 (UID RFC822.SIZE BODY.PEEK[HEADER] FLAGS) and my server-response is: S: * 4827313 FETCH (UID 4827313) S: * 4827313 FETCH (RFC822.SIZE 123456) S: * 4827313 FETCH (BODY.PEEK[HEADER] S: Return-path: [EMAIL PROTECTED] S: From: [EMAIL PROTECTED] S: Date: Fri, 24 Oct 2003 15:23:25 +0100 S: To: [EMAIL PROTECTED] S: Subject: Penis Enlargement up to 5000% S: ) S: * 4827313 FETCH (FLAGS ()) S: 004 OK UID FETCH completed is this correct? because it doesnt work. thanx for the support chun-ping -- - For information about this mailing list, and its archives, see: http://www.washington.edu/imap/imap-list.html - -- - For information about this mailing list, and its archives, see: http://www.washington.edu/imap/imap-list.html -
RE: FLAGS clarification
There are clients that rely on the fact that flags can be set and later retrieved on the same session. The flags don't need to be persisted but they DO need to be maintained for the current session. Larry Osterman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Bang Sent: Wednesday, December 10, 2003 3:32 AM To: [EMAIL PROTECTED] Subject: RE: FLAGS clarification Hi, Thanks for the clarification, but does returning read only allow me to return the suggested response to the attempt to change the flags? i.e. 005 STORE 1 FLAGS (\seen) 005 OK STORE Completed but I ignored you because this is read only Or does read only not apply to flags and I need to create a session flag store. Thanks for your help Richard Bang Floosietek Ltd [EMAIL PROTECTED] http://www.floosietek.com -Original Message- From: Mark Crispin [mailto:[EMAIL PROTECTED] Sent: 09 December 2003 17:18 To: Richard Bang Cc: [EMAIL PROTECTED] Subject: Re: FLAGS clarification On Tue, 9 Dec 2003, Richard Bang wrote: * FLAGS () Not compliant. System flags are mandatory-to-implement. The PERMANENTFLAGS list can be empty though. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
RE: FLAGS clarification
No, see my previous mail. The correct sequence is: 004 STORE 1 FLAGS (\seen) * 1 FETCH (FLAGS (\seen)) 004 OK STORE Completed but I ignored you because this is read only 005 STORE 1 +FLAGS.silent (\seen) 005 OK STORE Completed but I ignored you because this is read only 006 UID STORE 25 FLAGS (\seen) * 2 FETCH (UID 25 FLAGS (\seen)) 006 OK STORE Completed but I ignored you because this is read only Larry Osterman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Bang Sent: Wednesday, December 10, 2003 5:12 AM To: [EMAIL PROTECTED] Subject: RE: FLAGS clarification Hi, I have tweaked my responses. Would the following be compliant now? 003 SELECT Folder * FLAGS (\Answered \Flagged \Deleted \Seen) * 2 EXISTS * 0 RECENT * OK [UNSEEN 1] Message 1 is the first unseen * OK [UIDVALIDITY 1] UIDs VALID * OK [UIDNEXT 26] UIDs VALID * PERMANENTFLAGS () 003 OK [READ-ONLY] SELECT COMPLETED 004 STORE 1 FLAGS (\seen) * 1 FETCH () 004 OK STORE Completed but I ignored you because this is read only 005 STORE 1 +FLAGS.silent (\seen) 005 OK STORE Completed but I ignored you because this is read only 006 UID STORE 25 FLAGS (\seen) * 2 FETCH (UID 25) 006 OK STORE Completed but I ignored you because this is read only Thank you for your time, it is greatly appreciated. Regards Richard Bang Floosietek Ltd [EMAIL PROTECTED] http://www.floosietek.com
RE: FLAGS clarification
That looks pretty good to me :) Larry Osterman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Bang Sent: Wednesday, December 10, 2003 8:54 AM To: [EMAIL PROTECTED] Subject: RE: FLAGS clarification Hi, Here is the final version, thanks for all the feedback on this. I hope that this proves to be acceptable and is compliant. 003 SELECT Folder * FLAGS (\Answered \Flagged \Deleted \Seen) * 2 EXISTS * 0 RECENT * OK [UNSEEN 1] Message 1 is the first unseen * OK [UIDVALIDITY 1] UIDs VALID * OK [UIDNEXT 26] UIDs VALID * PERMANENTFLAGS () 003 OK [READ-ONLY] SELECT COMPLETED 004 STORE 1 FLAGS (\Seen) * 1 FETCH (FLAGS (\seen) UID 12) 004 OK STORE Completed but only for this session 005 STORE 1 +FLAGS.silent (\dEleted) 005 OK STORE Completed but only for this session 006 UID STORE 25 FLAGS (\seen) * 2 FETCH (FLAGS (\seen) UID 25) 006 OK STORE Completed but only for this session 007 STORE 2 +FLAGS.silent (\answered) 007 OK STORE Completed but only for this session 008 UID fetch 1:* (FLAGS) * 1 FETCH (FLAGS (\seen \deleted)) * 2 FETCH (FLAGS (\seen \answered)) 008 OK FETCH Completed 009 close 009 OK CLOSE completed 010 SELECT Folder * FLAGS (\Answered \Flagged \Deleted \Seen) * 2 EXISTS * 0 RECENT * OK [UNSEEN 1] Message 1 is the first unseen * OK [UIDVALIDITY 1] UIDs VALID * OK [UIDNEXT 26] UIDs VALID * PERMANENTFLAGS () 010 OK [READ-ONLY] SELECT COMPLETED 011 UID fetch 1:* (FLAGS) * 1 FETCH (FLAGS ()) * 2 FETCH (FLAGS ()) 011 OK FETCH Completed Regards Richard Bang Floosietek Ltd [EMAIL PROTECTED] http://www.floosietek.com
RE: FLAGS clarification
I can't possibly imagine a correctly written client that would assume that flags would persist across a close/expunge command - When the client issues the SELECT command it should completely reset its internal state for the mailbox. Larry Osterman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Bang Sent: Wednesday, December 10, 2003 10:12 AM To: [EMAIL PROTECTED] Subject: RE: FLAGS clarification Hi, Why did you issue a CLOSE command? Did the server expunge message 1 (UID 12) as a result? It's actually alright if the server didn't expunge message 1 (UID 12); the server has the right to disregard an EXPUNGE. But the client intent is different. I was trying to show that the server did not EXPUNGE because it was read only and subsequently the flags were cleared. Larry Osterman wrote: There are clients that rely on the fact that flags can be set and later retrieved on the same session. The flags don't need to be persisted but they DO need to be maintained for the current session. Hmm, I considered the session to be closed from the point of view of the folder when the folder is deselected, as per my example. Is this incorrect and does this mean that in theory I should maintain sessions flags for all the folders until a logout? Thanks Richard.
RE: Exchange server has a broken SASL implementation
Yup, if there were a test suite (or if we were told about clients that implemented SMTP/SASL) we'd have used it. The test team goes through a fair amount of effort to ensure that we interoperate with just about any clients that we know about. And we run any tests we can find, internal or external. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Arnt Gulbrandsen Sent: Monday, October 27, 2003 9:15 AM To: Ken Murchison Cc: IMAP Interest List; Mark [EMAIL PROTECTED] Subject: Re: Exchange server has a broken SASL implementation Ken Murchison writes: Mark Crispin wrote: Yet more proof that the SASL specifications as currently constituted are too complex, and why IMAP should not add initial-response until the SASL specifications are fixed. Or its more proof that M$ doesn't care about specs and choose to [re]define then as they see fit. Do not attribute to malice that which can be adequately explained by ignorance/release pressure/lack of time/blah/blah. So far, every Microsoft programmer I've spoken to seemed to try hard. (I'm not saying they succeed, but I _am_ saying they don't seem a malicious bunch.) We're talking about a set of interrelated documents that are light on examples and free of a test suite. I'm not greatly surprised that people have trouble implementing them correctly. (Larry: if there were a test suite for SMTP/SASL, would Microsoft have used it?) --Arnt
Interesting bounce mail (Warning, OT)
I just received the attached bounce message from the mail I sent. I dont know who generated it, but it may possibly be the WORST bounce message Ive ever seen. Heres the headers as received by our email system: Microsoft Mail Internet Headers Version 2.0 Received: from df-snowy.platinum.corp.microsoft.com ([10.197.0.106]) by DF-DINGO.platinum.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 27 Oct 2003 09:36:25 -0800 Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by df-snowy.platinum.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 27 Oct 2003 09:36:24 -0800 Received: from 10.197.0.48 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 27 Oct 2003 09:36:24 -0800 Received: from mx0.ftgate.com ([195.224.16.237]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 27 Oct 2003 09:36:23 -0800 Date: Mon, 27 Oct 2003 17:34:05 + Message-Id: [EMAIL PROTECTED] from: Mail Daemon to: [EMAIL PROTECTED] subject: Delivery Failed: RE: Exchange server has a broken SASL implementation Mime-Version: 1.0 Content-Type: multipart/mixed; boundary==_NextPart_f031027173405599F Return-Path: X-OriginalArrivalTime: 27 Oct 2003 17:36:23.0946 (UTC) FILETIME=[D7751EA0:01C39CB0] --=_NextPart_f031027173405599F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --=_NextPart_f031027173405599F Note that there is almost NOTHING that identifies which email system originated the email message all Ive got is that it came from mx0.ftgate.com. Sigh. Why on earth did this company waste the bandwidth on a spam announcement that had NO information of value in it. ---BeginMessage--- Title: Delivery Failed: RE: Exchange server has a broken SASL implementation Hi, This is an automated message. Your message: %subject% has been rejected bacause it passed through an internet server known to be an open relay to SPAM and it did not contain any references to any of our products. If this is an error please resubmit your message and include the name of the product you are refering to. Thank you. ---End Message---
RE: Exchange server has a broken SASL implementation
Hmm. I just realized I forgot my normal caveat: I don't work in Exchange, and haven't for about 4 years now, and it's been 6 years since I worked on IMAP products in Exchange. So anything I said isn't a commitment for the Exchange organization, it's just my personal opinion, based on what I know about the people in Exchange who are doing the testing/development of Exchange. I certainly take SIGNIFICANT offense at Ken's comment; I'd love for him to give a real-world example of a WILLFUL misinterpretation of the specifications from Microsoft, as he implied by his comment. I've seen lots of instances of stupidity/ignorance, but none of WILLFUL misinterpretations. His comment is a slap at the integrity of the developers of Exchange/SMTP (at least in E2K, the SMTP service used by Exchange was a deliverable of the NT group, not Exchange). I'll be the first to say that Microsoft hasn't been NEARLY as forthcoming with it's specifications (I've been trying to get a NTLM SASL profile published for 7 years now, only to be rebuffed at every turn), and we've certainly screwed up enough (not fixing the the AUTH= stuff for SMTP auth is a good example). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Larry Osterman Sent: Monday, October 27, 2003 9:35 AM To: Arnt Gulbrandsen; Ken Murchison Cc: IMAP Interest List; Mark [EMAIL PROTECTED] Subject: RE: Exchange server has a broken SASL implementation Yup, if there were a test suite (or if we were told about clients that implemented SMTP/SASL) we'd have used it. The test team goes through a fair amount of effort to ensure that we interoperate with just about any clients that we know about. And we run any tests we can find, internal or external. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Arnt Gulbrandsen Sent: Monday, October 27, 2003 9:15 AM To: Ken Murchison Cc: IMAP Interest List; Mark [EMAIL PROTECTED] Subject: Re: Exchange server has a broken SASL implementation Ken Murchison writes: Mark Crispin wrote: Yet more proof that the SASL specifications as currently constituted are too complex, and why IMAP should not add initial-response until the SASL specifications are fixed. Or its more proof that M$ doesn't care about specs and choose to [re]define then as they see fit. Do not attribute to malice that which can be adequately explained by ignorance/release pressure/lack of time/blah/blah. So far, every Microsoft programmer I've spoken to seemed to try hard. (I'm not saying they succeed, but I _am_ saying they don't seem a malicious bunch.) We're talking about a set of interrelated documents that are light on examples and free of a test suite. I'm not greatly surprised that people have trouble implementing them correctly. (Larry: if there were a test suite for SMTP/SASL, would Microsoft have used it?) --Arnt
RE: LIST
Sorry, was off the list for a bit and just came back. One really simple example of a store that has \NoSelect name with children is the NNTP store. An IMAP server that exposes an NNTP hierarchy exposes comp.mail.imap even though there is no comp newsgroup - such a store has to expose comp as a \NoSelect mailbox with children. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Crispin Sent: Tuesday, September 16, 2003 7:37 AM To: Rob Siemborski Cc: Lawrence Greenfield; IMAP protocol mailing list Subject: Re: LIST On Tue, 16 Sep 2003, Rob Siemborski wrote: I suppose this depends on your definition of harmless. I wouldn't want a server that doesn't do this declared at all noncompliant. Agreed; there is no harm in not doing this if the server does not have have such a thing as a \NoSelect name without children. Such servers aren't noncompliant (sorry for the double negative). But we do have to consider the case when a server has \NoSelect names without children. I do not believe it is harmless in pathological cases like LIST */% where the output could be needlessly doubled by such behavior. Of course, this is a pathological case. I don't think that we need to consider pathological cases; a client which invoked this gets what it deserves. Indeed, I'd argue such a server (which does not have the \NoSelect with no children case) is equally correct with an implementation that does not omit foo/ from the list, since none of this special treatment of trailing hierarchy delimiters (outside of CREATE) is discussed in the protocol specifications. That is a problem; doing so creates ambiguity and misleads clients into incorrect behavior. We should not be recklessly making IMAP more ambiguous and less useful. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
RE: a synchronization issue
On Thu, 11 Sep 2003, Marcel Crasmaru wrote: c1: a store 1 +flags (\Deleted) s : * 1 FETCH (FLAGS (\Deleted) UID 3) s : a OK store So far, so good. 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 c1: b expunge Mark, are you sure? On the c2 command, it's a flags.silent store, the * 1 FETCH response is retrieving the change from c1's store 1 +flags (\Deleted) command, so it should be retrieving the fact that 1's flags changed. Larry Osterman
RE: a synchronization issue
Never mind this - enough other people have heaped on this issue already :) Sorry bout that... Larry Osterman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Larry Osterman Sent: Thursday, September 11, 2003 10:35 AM To: Mark Crispin; Marcel Crasmaru Cc: [EMAIL PROTECTED] Subject: RE: a synchronization issue On Thu, 11 Sep 2003, Marcel Crasmaru wrote: c1: a store 1 +flags (\Deleted) s : * 1 FETCH (FLAGS (\Deleted) UID 3) s : a OK store So far, so good. 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 c1: b expunge Mark, are you sure? On the c2 command, it's a flags.silent store, the * 1 FETCH response is retrieving the change from c1's store 1 +flags (\Deleted) command, so it should be retrieving the fact that 1's flags changed. Larry Osterman
RE: \NoSelect
Uh yeah - what he said :) I just can't type. Larry Osterman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Crispin Sent: Wednesday, September 10, 2003 3:13 PM To: Larry Osterman Cc: [EMAIL PROTECTED] Subject: RE: \NoSelect On Wed, 10 Sep 2003, Larry Osterman wrote: My take is that this is a bug of Mozilla - \NoSelect means exactly what it says - the mailbox has no inferiors. can not be selected -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
RE: which server implements IMAP referals these days RFC2193?
And the exchange server of course does it as well - for login referrals at a minimum. Larry Osterman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Siemborski Sent: Wednesday, September 03, 2003 10:32 AM To: Arnaud Taddei Cc: [EMAIL PROTECTED] Subject: Re: which server implements IMAP referals these days RFC2193? The Cyrus IMAP Aggregator frontends use it when the client makes it clear that it will support it (for example, by issuing an RLIST/RLSUB command). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * [EMAIL PROTECTED] * 412.268.7456 -BEGIN GEEK CODE BLOCK Version: 3.12 GCS/IT/CM/PA d- s+: a-- C$ ULS$ P+++$ L+++() E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? --END GEEK CODE BLOCK-
RE: IMAP not good enough?
You're confusing a protocol and an interoperable protocol. Both are protocols, a protocol is just another word for format of bits on the wire. -Original Message- From: Arnt Gulbrandsen [mailto:[EMAIL PROTECTED] Sent: Friday, August 15, 2003 4:18 AM To: Pete Maclean Cc: Larry Osterman; IMAP protocol mailing list Subject: Re: IMAP not good enough? Pete Maclean writes: The Exchange protocol is orders of magnitude richer than IMAP, but it's not standard (which is why it's totally proprietary :)). But is it fair to say that the Exchange protocol is a protocol in the same sense as IMAP, or even a true protocol at all? Not in the same sense. Making two programs from the same organization talk to each other is easy peasy compared with making many and different programs from many independent and competing organizations interoperate. Both technically and politically. Whether it's a protocol at all... I guess that hinges on the definition of protocol. Doesn't really matter, does it? --Arnt
RE: IMAP not good enough?
Actually I've got to point out that the two teams in this case aren't close together - in fact their ship cycles are radically different, which is why the Exchange RPC protocol is essentially unchanged after 8 years :) -Original Message- From: Arnt Gulbrandsen [mailto:[EMAIL PROTECTED] Sent: Friday, August 15, 2003 4:23 AM To: Larry Osterman Cc: IMAP protocol mailing list Subject: Re: IMAP not good enough? Larry Osterman writes: My statement was intended to be a value-neutral statement - the proprietary protocols have more features than the open standard protocols. Naturally. It's much easier for two teams sitting in adjacent offices to agree on how to add a feature and get it done than it is for n independent, competing organizations. Nothing in life is free. If I (as customer) buy tighter integration, it becomes harder to change one component later. On the other hand, if I buy interoperability, tighter integration is hard/expensive. --Arnt
RE: IMAP not good enough?
Ok, mine agrees with mine :) http://dictionary.reference.com/search?q=protocol pro·to·col( P ) Pronunciation Key (prt-kôl, -kl, -kl) n. Computer Science. A standard procedure for regulating data transmission between computers. The only part of disagreement is the bit about standard. It doesn't say open standard. :) -Original Message- From: Arnt Gulbrandsen [mailto:[EMAIL PROTECTED] Sent: Friday, August 15, 2003 9:21 AM To: Larry Osterman Cc: Pete Maclean; IMAP protocol mailing list Subject: Re: IMAP not good enough? Larry Osterman writes: You're confusing a protocol and an interoperable protocol. I'm not. I'm saying X and Y aren't protocols in the same sense of the word. Both are protocols, a protocol is just another word for format of bits on the wire. My dictionary disagrees with you. Personally I don't have an opinion. --Arnt
RE: IMAP not good enough?
Trust Larry to stick his foot squarely in his mouth and reply to this one :) IMHO, Steve's exactly right. Remember that Steve's comparing the proprietary Exchange MAPI RPC protocol with the IMAP protocol. The Exchange protocol is orders of magnitude richer than IMAP, but it's not standard (which is why it's totally proprietary :)). For example, it natively supports calendaring, threading, asynchronous notifications, multiple message stores, incremental content synchronization (at the property level), multiple simultaneous client access, public and private message folder stores, etc. It also supports compression of the wire format, encryption of the datastream, etc. It allows message submission with rich message send options (deferred send, etc). It allows for message filtering, client and server side rules, etc. It allows for content indexing, dynamic searching and sorting of the message store. It allows for notifications of new folder creation and deletion. Many of these things can be done with IMAP, but rely on extensions to both IMAP and SMTP. So Steve's 100% right - IMAP isn't NEARLY as rich as the proprietary Exchange protocol. But that shouldn't be a surprise to anyone. Open standards are almost never as rich as the proprietary ones (x.400 is just about the only one I can think of - almost nobody implements all of x.400 :)). Open standards almost always are written to the lowest common denominator. As a really simple example, how many times has MRC mentioned that a particular feature can't be implemented because the legacy Unix message store can't support that feature? As a corollary, how many times has a client vendor wanted to implement some cool feature but discovered that the protocol didn't allow it? Proprietary systems don't have that problem - since it's a proprietary system, the protocol can simply be changed (if you care about legacy clients, you need to make sure that the change is upwards compatible, but...). The single major advantage of open protocols is that they're open. It means that you're not locked into a single vendor or a single client. In addition, it is feasible for there to be open source implementations of open standards; open source implementations of proprietary standards are extremely hard to do (ask Jeremy Allison about that sometime :)). In general, open standard protocols tend to be better documented than closed standards. The price you pay for that flexibility is that your client experience usually isn't as rich as it is with the proprietary solutions. Btw, in case anyone thinks that I'm just touting Exchange because I'm Microsoft, this exact same argument can be made about Lotus Notes, or Groupwise, or any of the other large scale proprietary email systems - with their proprietary clients, they all support a significantly richer user experience than they do with their open standard clients. Larry Osterman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Timo Sirainen Sent: Thursday, August 14, 2003 9:29 AM To: Cyrus Daboo Cc: [EMAIL PROTECTED] Subject: Re: IMAP not good enough? On Thursday, Aug 14, 2003, at 18:56 Europe/Helsinki, Cyrus Daboo wrote: I don't want to start a flame war of any kind but I think the following quote (which I saw quoted on comp.mail.imap) deserves some response from the IMAP community, if only to re-evaluate IMAP's strengths and weaknesses: IMAP is just not a very rich protocol, Steve Conn, Exchange Server product manager, told ZDNet Australia during the company's Tech Ed conference. I find that pretty strange argument against IMAP, assuming rich means featureful. I'd say IMAP's biggest weakness is that the protocol is too difficult to understand and there's too many ways to mess up implementations accidentally. I've been thinking about writing some pretty detailed guide to client writers, so that it would actually say what you're supposed to send to server, reasons why it can fail and how you're supposed to handle potential failures. But it's quite a lot of work and I don't know when I have time for it.
RE: IMAP not good enough?
It was not my intent to disparage IMAP. I i love / IMAP. I really do. But if you believe that IMAP is as flexible/feature rich as the proprietary protocols, then you're not facing reality. IMAP is great for what it does, and I actually agree with Timo - in many ways it's too complicated. But it doesn't have the feature set of a proprietary protocol. My statement was intended to be a value-neutral statement - the proprietary protocols have more features than the open standard protocols. Oh, and I can't resist: Btw, Exchange and the Exchange proprietary protocol don't support worms or Word macro viruses either :) It's the broken clients that support them. I could write an IMAP client that supports worms and Word macro viruses if I wanted to. It wouldn't even be that hard (all I'd have to do is to run mime/html mail in the trusted sites zone). Larry Osterman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andreas Aardal Hanssen Sent: Thursday, August 14, 2003 10:21 AM To: IMAP protocol mailing list Subject: RE: IMAP not good enough? On Thu, 14 Aug 2003, Larry Osterman wrote: Trust Larry to stick his foot squarely in his mouth and reply to this one :) The Exchange protocol is orders of magnitude richer than IMAP, but it's not standard (which is why it's totally proprietary :)). There evidently goes a fine line between richness and bloat. Anyone can put anything into a protocol, and if they are paid to do so they will not hold back. After all, when all is done inside one company, nobody has to think about interoperability and design. Some protocols even have obfuscation layers to prevent reverse engineering. IMAP is a mail protocol. In that respect, it is very rich and very extensible. No, IMAP does not support calendaring. I doesn't even support worms or Word macro viruses! Still so many find it useful. I have worked with a multitude of proprietary protocols that suck big time, while still being rich and full of features. So I don't support your implicit distinction between marvelous proprietary protcols and poor open ones. Andy -- Andreas Aardal Hanssen http://www.bincimap.org/
RE: IMAP not good enough?
I did say that most of these features are available with extensions, didn't I? Please, I'm not trying to start an Exchange protocol vs IMAP protocol. I'd have used the Lotus Notes feature set if I knew it. The discussion is ONLY about Steve Conn's comments about IMAP not being as feature rich as IMAP (which was used as a part of a justification for ceasing forward development of Outlook Express). And any responses I'm making are in the context of what Outlook Express needs to support, NOT what a hypothetical tightly linked open protocol client/server solution would require. Also, for clarifications on Timo's comments: asynchronous notifications, Of what? Sieve + [ALERT]s could be a nice kludgy way to do that :) Anyway, probably more related to calendaring than emails. The IMAP equivilant extension for what I was describing is actually IDLE. multiple simultaneous client access, As does IMAP. Only with certain message stores and only with certain servers. You can't guarantee the feature. And Outlook Express (the client in question) can't assume a single IMAP server - it can only use the features available in ALL the servers. And since not every server supports simultaneous client access, it technically shouldn't support it. It allows for message filtering, client and server side rules, etc. What does client side rules have to do with protocol? Sieve for server side. Nothing - but your client side rules are actually stored on the server with Exchange so even though they are executed on the client, they're available for all clients. dynamic searching There's SEARCH? (though I still wish for the non-exact text searching extension) Actually I'm referring to Exchange's search folders - basically you can create a search folder on the store, and whenever a message is created that matches the search criteria, the message gets added to the folder, and the client is notified about the new message automagically. SEARCH is static. Larry Osterman
RE: IMAP not good enough?
Thank you Cyrus, you make really good point. And also, to bring this
back to Outlook Express (since that was the original client
mentioned)...
In order to provide the same experience you can get with Outlook in
proprietary mode, you'd need to have an email server that implemented
ALL of the below mentioned protocols and extensions.
And Outlook Express is a consumer product - it's intended for Abby (a
persona that represents the typical AOL mom). The OE team can't deploy
a feature set that depends on protocol extensions that may or may not
exist on the server, it also has to code for the lowest common
denominator - which means that it's stuck with the base IMAP
specification (which is what it knows exists). Most ISPs don't offer
ACAP, or SIEVE (heck, most ISPs don't offer IMAP).
Larry Osterman
-Original Message-
From: Cyrus Daboo [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 14, 2003 10:43 AM
To: Larry Osterman; Timo Sirainen
Cc: [EMAIL PROTECTED]
Subject: RE: IMAP not good enough?
Hi Larry,
--On Thursday, August 14, 2003 10:03:46 AM -0700 Larry Osterman
[EMAIL PROTECTED] wrote:
| The Exchange protocol is orders of magnitude richer than IMAP, but
it's
| not standard (which is why it's totally proprietary :)).
|
| For example, it natively supports calendaring, threading, asynchronous
| notifications, multiple message stores, incremental content
| synchronization (at the property level), multiple simultaneous client
| access, public and private message folder stores, etc. It also
supports
| compression of the wire format, encryption of the datastream, etc. It
| allows message submission with rich message send options (deferred
send,
| etc). It allows for message filtering, client and server side rules,
| etc. It allows for content indexing, dynamic searching and sorting of
| the message store. It allows for notifications of new folder creation
| and deletion.
|
| Many of these things can be done with IMAP, but rely on extensions to
| both IMAP and SMTP.
|
I think the problem here is that the comparison shouldn't be between
Exchange and IMAP, but rather Exchange and {the set of open standards
protocols designed to implement messaging and collaboration - i.e. IMAP,
POP, SMTP, ICAP, SIEVE etc with corresponding standard extensions}. Even
with those others added in, its true that Exchange is still ahead in
terms
of features, but the gap isn't as wide as one might think.
The real question is whether the current design of multiple open
standards
protocols for implementing messaging and collaboration is the best
approach, as opposed to having a single modularized monolithic protocol
to
do all that. As an implementor, it is a pain to have to add support for
a
completely new protocol to just add calendaring (something I'm actually
having to do right now). We're also beginning to see the need for a
certain
amount of 'overlap' between protocols (c.f. lemonade WG issues with
submission via IMAP).
So what are the real pro's and con's between monolithic protocol vs
multiple task-specific protocols? And is that the real limitation in
terms
of 'richness' that we are seeing here?
--
Cyrus Daboo
RE: IMAP not good enough?
It's a true protocol because it's a wire format. In Exchange's case, the Exchange RPC interface consists of Send this buffer filled with opaque bits to the server and get me a response buffer. All the smarts are packed into the buffer with opaque bits. So yeah, it's a protocol. RPC is used for authentication, encryption, transport independence and session management but that's about it. Larry Osterman -Original Message- From: Pete Maclean [mailto:[EMAIL PROTECTED] Sent: Thursday, August 14, 2003 10:51 AM To: Larry Osterman Cc: [EMAIL PROTECTED] Subject: RE: IMAP not good enough? IMHO, Steve's exactly right. Remember that Steve's comparing the proprietary Exchange MAPI RPC protocol with the IMAP protocol. The Exchange protocol is orders of magnitude richer than IMAP, but it's not standard (which is why it's totally proprietary :)). But is it fair to say that the Exchange protocol is a protocol in the same sense as IMAP, or even a true protocol at all? I am not meaning to suggest these things, I am really asking. The reason is because, it seems to me, RPC is really the protocol and what you can do over RPC is so unlimited it seems hardly appropriate to call that a protocol. Am I off base here? Pete Maclean
RE: Outlook, ipop3d, filed mail
Ok, I'm going to bite here. So it appears to me that you're complaining that when you enable the Leave a copy of the message on the server that the POP3 client leaves a copy of the message on the server? The default behavior for IMAP is to download the message from the server, the Leave a copy of the message on the server option is in the client to allow you to run POP3 clients from multiple locations - in which case each location gets its own copy of the email. But a corollary of this behavior is that none of the clients delete the mail from the server unless they are instructed to manually delete the mail. Back when I was testing Eudora, Netscape, et al, they all had an option to do this and they all seemed to do just about the same thing. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Toby Wahlers Sent: Friday, August 01, 2003 1:35 PM To: [EMAIL PROTECTED] Subject: Outlook, ipop3d, filed mail I was wondering if anyone else had run into this problem: When an Outlook (or OE) POP3 user files mail locally, the message disappears from the local Inbox. But remains in their server mail file. Eventually, hundreds, thousands (millions?) of messages reside on the server, none of which are shown in Outlook. Eudora, Mozilla, etc don't appear to exhibit this...er...behavior. It only happens when you have the POP3 account set to leave a copy of the message on the server. IMAP in Outlook works correctly, it seems. The workaround for POP3 is to set the account to Remove from server when deleted from Deleted Items, copy/paste messages into the desired local mailbox when filing, delete the messages out of the Inbox, then select Empty Deleted Items folder. I wouldn't think that ipop3d would be involved, since messages do get deleted correctly with the procedure above. -- - For information about this mailing list, and its archives, see: http://www.washington.edu/imap/imap-list.html -
RE: Recent flags
Several people have pointed out in the past that the \Recent flag doesn't work when you have more than one client accessing a mailbox simultaneously, you've just pointed out another problem where this occurs. The bottom line is that you can't rely on \Recent to highlight messages, you need to rely on \Seen, since it is a persistent flag (\Recent isn't, it's more of a virtual flag). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Timo Sirainen Sent: Saturday, August 02, 2003 5:19 PM To: [EMAIL PROTECTED] Subject: Recent flags A month ago here was this discussion about new mail notification in mailboxes. I started thinking about it some more how I'd want the client's user interface to behave. Recent counters are actually quite good. They do exactly what I want, but only as long as there's only one client having mailboxes SELECTed at a time, which is usually not the case with me. The multiclient behaviour for \Recent simply sucks. Is there any real reason why it was specified as it was, except just to standardize some kind of server behaviour? I think the wanted \Recent flag behaviour is: Message arrived the mailbox after last user interaction in the same mailbox. Problem is how the server would know which is user interaction and which is client doing things itself. I believe these rules should work quite well: - When mailbox is SELECTed, all the current messages will be non-recent for subsequent sessions - When a message is marked \Seen (most likely a user interaction), all the current messages will be non-recent for subsequent sessions (possibly \Deleted flag as well? I'm not sure) - In all other cases the messages will be marked \Recent for all the sessions that have the mailbox selected, but also for next session(s) That gives the following behaviour: Client A has INBOX SELECTed, client B has FOOBOX SELECTed - A new mail arrives to INBOX - Client A notices it via NOOP, sees it as \Recent and notifies user about it by highlighting the mailbox name - Client B notices it via STATUS (RECENT), or with some new mail notification extension. Client B highlights the mailbox name as well a) User opens some of the new mails with client A, which changes it's \Seen flag. - Client A removes the highlight - Sometimes later Client B issues STATUS (RECENT) which now returns 0. The highlight is removed. b) User notices the new mails with client B, and selects the INBOX. - New mails are still seen as \Recent - Client B removes the highlight - Oops, problem: Client A doesn't know that the highlight should be removed. b's problem can be solved in a few ways: - Don't just mark the mail to be non-recent for subsequent sessions, also do it for all the current sessions by removing the \Recent flag and sending decreased * n RECENT. I'd like this, but I suspect this might break something. - Client could create a separate session to ask STATUS (RECENT) for the selected mailbox. Kludgy. - Client could re-SELECT the mailbox. Kludgy and expensive. - Client could issue LIST for the current mailbox and check if it has \Unmarked flag. LISTing would probably be the best thing to do, but if server shows neither \Marked nor \Unmarked, it doesn't solve the problem. Luckily it's not too bad - it's only for selected mailbox. Note that I don't consider any of these \Recent flag behaviour changes to be non-compliant with current RFC, since it has this nice clause: If it is not possible to determine whether or not this session is the first session to be notified about a message, then that message SHOULD be considered recent. My server just doesn't happen to always know when the recent notification was sent :) -- - For information about this mailing list, and its archives, see: http://www.washington.edu/imap/imap-list.html -
RE: Recent flags
My inbox also has lots of unseen messages, I feel your pain :) I think you're right - the protocol behavior change you are proposing (to change the behavior of the \Recent flag to be more persistant) is almost certain to break clients, all the other changes might work, but they require client changes and thus can't be fixed on the server. Also, LIST is very expensive, as is status (for some mailbox formats). -Original Message- From: Timo Sirainen [mailto:[EMAIL PROTECTED] Sent: Monday, August 04, 2003 12:52 PM To: Larry Osterman Cc: [EMAIL PROTECTED] Subject: RE: Recent flags On Mon, 2003-08-04 at 22:26, Larry Osterman wrote: Several people have pointed out in the past that the \Recent flag doesn't work when you have more than one client accessing a mailbox simultaneously, you've just pointed out another problem where this occurs. What other problems are there beside what I described? I think my solution would fix it to behave reasonably well. The bottom line is that you can't rely on \Recent to highlight messages, you need to rely on \Seen, since it is a persistent flag (\Recent isn't, it's more of a virtual flag). \Seen isn't really useful for me. I often leave mails unseen to indicate that it needs some further action. I guess some other flags would work as well but \Seen is the only flag that works with all clients. My INBOX has 142 unseen mails currently. Also I don't read mails in some high volume mailing lists, so unseen counters are useless there as well. Recent counters would work very well with both cases to indicate when new mail has arrived.
RE: Recent flags
The biggest problem with LIST is that LIST with wildcards can be insanely expensive on some servers. List without a wildcard should be relatively inexpensive, but if you use wildcards, some mail stores (like the Exchange store) need to iterate over ALL the mailboxes in the message store to determine if the mailbox name matches the search criteria. -Original Message- From: Timo Sirainen [mailto:[EMAIL PROTECTED] Sent: Monday, August 04, 2003 1:57 PM To: Larry Osterman Cc: [EMAIL PROTECTED] Subject: Re: Recent flags On Monday, Aug 4, 2003, at 23:29 Europe/Helsinki, Larry Osterman wrote: My inbox also has lots of unseen messages, I feel your pain :) I think you're right - the protocol behavior change you are proposing (to change the behavior of the \Recent flag to be more persistant) is almost certain to break clients, all the other changes might work, but they require client changes and thus can't be fixed on the server. No, I don't see how they would require any client changes, assuming client already uses recent-counters. There's only small behavioural change in when recent counts would be dropped, it wouldn't require any specific support. Also, LIST is very expensive, as is status (for some mailbox formats). STATUS can be, but LIST? It's specifically said in RFC that list should be very inexpensive and I haven't yet heard of a server where this wouldn't be the case. The ideal implementation from performance point of view would probably be: LIST all visible mailboxes every n minutes - If mailbox is \Marked, it's known to have new messages. Highlight it. - If mailbox is \Unmarked, it's known not to have new messages. If it's highlighted, remove it. - otherwise issue STATUS (RECENT), unless it's the active mailbox. Based on the result do like above. The evil implementation I'm planning to use myself is just to issue STATUS (UNSEEN RECENT) for all mailboxes since I want unseen-counts as well :)
RE: EXAMINE, SELECT, and FETCH FLAGS
One of the clients requires that if you do: C: 1 STORE 1 +FLAGS (\Seen) S: 1 OK Store completed And then do: C: 1 FETCH 1 FLAGS The server respond with: S: * 1 FLAGS (\Seen) S: 1 OK Fetch completed As opposed to failing the STORE. It's been over 6 years since I worked on an IMAP server, so I'm not sure which client it was that depended on the behavior. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Timo Sirainen Sent: Tuesday, July 15, 2003 3:14 AM To: [EMAIL PROTECTED] Subject: RE: EXAMINE, SELECT, and FETCH FLAGS On Tue, 2003-07-15 at 01:34, Larry Osterman wrote: There are clients out there (I believe PINE is one of them, I know that Outlook Express is another) that require flags updates on read-only mailboxes, and if you carefully read the spec's language on READ-ONLY and FLAGS, it's clear that the server needs to maintain a dynamic shadow copy of the flags in the mailbox on READ-ONLY mailboxes (which is what a mailbox opened with EXAMINE is). Really? I was worried about that before, but then I noticed this in PERMANENTFLAGS: If the client attempts to STORE a flag that is not in the PERMANENTFLAGS list, the server will either ignore the change or store the state change for the remainder of the current session only. And what do you mean OE/Pine would require flags updates? They do try to set them, but I don't notice any problems with actually using them. Although my server does send: * NO Mailbox is read-only, ignoring store.. Which Pine displays all the time.. Maybe I shouldn't send it, or at least more than once.
RE: EXAMINE, SELECT, and FETCH FLAGS
#3 is clearly bogus. I'd actually argue that #2 is the correct behavior. When the first FLAGS response is generated, the message isn't yet \Seen. When the FETCH is executed, the message is marked as being \Seen, and an untagged FLAGS response is queued. I can't explain why they don't generate a 3rd untagged FLAGS response, my guess is that they are attempting to be smart and collapse the 3rd FLAGS response with the 2nd FLAGS response (which was auto-generated by the fetch BODY[]. #1 is more confusing - it also seems to be a bug in that the \Seen flag is permanent but isn't included in PERMANENTFLAGS.\ The fact that the \Seen flag changes state on a fetch on an EXAMINE'ed isn't a bug (actually it would be a bug if the \Seen flag DIDN'T change state on read-only mailbox). There are clients out there (I believe PINE is one of them, I know that Outlook Express is another) that require flags updates on read-only mailboxes, and if you carefully read the spec's language on READ-ONLY and FLAGS, it's clear that the server needs to maintain a dynamic shadow copy of the flags in the mailbox on READ-ONLY mailboxes (which is what a mailbox opened with EXAMINE is). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim Showalter Sent: Monday, July 14, 2003 3:13 PM To: [EMAIL PROTECTED] Subject: EXAMINE, SELECT, and FETCH FLAGS Recently one of our customers migrating to one of our servers discovered that another IMAP server had some interesting (mis)interpretations of the IMAP spec. I'd like to get a clarficiation and perhaps badger the unnamed into making a change. (1) The \Seen flag was changed by FETCH [seq] (FLAGS BODY[] INTERNALDATE) while the mailbox was being EXAMINEd. \Seen is not advertised in PERMANENTFLAGS in EXAMINE, but the change appears permanent. (2) FETCH [seq] (FLAGS BODY[] FLAGS) returns a FETCH response with the obvious three items in that order. The first FLAGS is (). The second flags is (\Seen). No implicit FLAGS response is returned in this case under either SELECT or EXAINE. (3) As an extra bonus, I'm not sure how to turn \Seen flags off. STORE [seq] -FLAGS (\Seen) seems like it ought to work, but it doesn't. Well, the server claims it does, but the flags are immediately re-set. A workaround for the first two this is to BODY.PEEK[] even in EXAMINE mode, or to send FLAGS before BODY[]. Either would have worked around the bug, but only the former would have avoided changing \Seen. Potential workarounds for (3) are more drastic. Thanks! Tim -- - For information about this mailing list, and its archives, see: http://www.washington.edu/imap/imap-list.html -
RE: Out of range sequence sets in SEARCH
Actually I always assumed that the lack of a BAD response was simply that the search untagged response was empty indicating that no message was available that met the search criteria specified. I remember MarkPu and I having a long debate about this when Mark was implementing search in the Exchange server - we went back and forth and decided that there was noting wrong in a client specifying an invalid message ID number. There is clearly something wrong with a client specifying an invalid message sequence number in a fetch (since the client knows at all times the number of messages in a mailbox), but that does not necessarily hold true for search (although the reason for this currently escapes me). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Crispin Sent: Wednesday, July 09, 2003 10:28 AM To: Timo Sirainen Cc: [EMAIL PROTECTED] Subject: Re: Out of range sequence sets in SEARCH On Wed, 9 Jul 2003, Timo Sirainen wrote: Giving out of range sequence set for FETCH returns BAD error with most IMAP servers, but why not with SEARCH? Is there a reason, which I can't see in RFC, or is it just lack of error detection? The latter (lack of error detection). It is also possible to think that SEARCH does not actually reference a message the way FETCH does, and therefore failing to detect an out of range sequence in SEARCH is less of a problem. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
RE: date vs. date-time
IIRC, the reason is that for searches, it is very often useful to have a search whose criteria is received on Tuesday as opposed to received on Tuesday at 3:17PM Larry Osterman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Arnt Gulbrandsen Sent: Wednesday, June 04, 2003 10:46 AM To: [EMAIL PROTECTED] Subject: date vs. date-time date-time is used a few times in the grammar, but in SEARCH date is used, e.g. SINCE date, not SINCE date-time. Is there any particular reason for that? Just curious. --Arnt -- - For information about this mailing list, and its archives, see: http://www.washington.edu/imap/imap-list.html -
RE: date header semantics of bulletin board messages
A couple of comments below on E2K: 3. Based on the above, and despite immutability of messages and associated UIDs at the IMAP protocol level, a compliant IMAP client may nevertheless choose to implement a user-level model of editable body content for bulletin board posts. The Exchange 2000 IMAP server is an example of this behavior: when post contents change, a new UID is generated, but the original internal date is preserved and the original date is also retained in the Date: field in the RFC2822 header. Note that while in the recent mutability thread Larry Osterman mentioned changing message content only in the context of unsent messages, post editability is a first-class feature in Exchange, and has nothing to do with draft/unsent messages. In Outlook2000/Exchange2000, if the command New Post in This Folder was used to create an item, then the command Revise Contents is available whenever that item is opened (the similar command Edit Message is available for mail messages, in certain circumstances, but the post scenario is my primary concern). While Outlook/Exchange may implement post editability through proprietary means, it could be implemented solely via IMAP using DELETE/EXPUNGE/APPEND, where the APPEND command has a date/time string. My message immutability comments were in the context of a users private mail store and not the public store. For the public store, when a message is modified, a number of things happen to the message. First, obviously the message gets a new UID. In addition, the \Seen flag is removed from the message for all other users, as a way of informing other clients that the message has been modified. This actually falls out from the fact that per user read/unread state is kept in a per-user CNSET (change number set, which is a data structure that allows for the server to keep track of change numbers for internal messages). When a message is modified (the client calls SaveChanges() on an open message), the change number on the message is bumped (and thus it's no longer in the cnsetseen for the message). That's also the thing that causes the UID to be updated, fwiw. Larry Osterman
RE: Why is a message immutable?
of such a hypothetical table. The table in question was written in 1982, and it's STILL a part of NT. This got WAY more long winded than I expected. My point here is that you can't just change the rules of a protocol on the fly after it's been deployed, just like you can't change the rules for DOS applications after the operating system has shipped. It's too late, the cow's out of the barn and the barn's long since burned down. Similarly, you can't change the semantics of the \Recent flag, because you'd break every existing client AND server implementation out there. There's a mechanism defined in IMAP for indicating non-metadata changes to a message, it's * n EXPUNGE/* m EXISTS. If you want something about the message to change that's lightweight, then you need to change the message metadata, NOT the contents of the message. Larry Osterman
RE: Attachment message flag
One thing to keep in mind is that bodystructure may be quite expensive to compute, but for a given UID, it's immutable, which means that the server can cache the value of the bodystructure. That in fact is what the Exchange server does - since it's expensive to compute it, it only ever computes the bodystructure on a message once. Which means that after an initial relatively expensive parse of the message, body and bodystructure are both absolutely trivial to transmit to the client. Don't forget that many message stores (including the exchange store) don't/can't support custom message flags :) Larry Osterman -Original Message- From: Timo Sirainen [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 4:26 PM To: Larry Osterman Cc: [EMAIL PROTECTED] On Wed, 2003-03-05 at 01:46, Larry Osterman wrote: You're missing my point. This mailing list is about the PROTOCOL. Discussions should be about are about what's best for the clients that are engineered to use the protocol and the servers that implement, not for those that are using subsets of the protocol. As such, clients like OE and Evolution are poor choices to consider when discussing protocol design. Ah, sure. I was getting off topic there (or earlier), I just meant that just make the server cache the bodystructure may not be the best behaviour for server in all cases. Still, even if client does use BODYSTRUCTURE, I don't think it's optimal behaviour to fetch it for all messages before it's actually needed. I think it was Lyndon who pointed out that it's the client that's best suited to determine if a message has attachments or not - the server will almost always get it wrong. Right, it can't always say if the message has an attachment, but for many cases it can say that it doesn't have attachment (Content-Type: text/*). But I think I'll just use custom message flags for this if I decide to not use BODYSTRUCTURE.
RE: LIST issues
In fact, the Exchange store returns the list of folders in a semi-random order (actually they're roughly listed in the order of creation but that's an artifact of the enumeration mechanism more than anything else). Any client that depends on ordering will absolutely break when they hit the Exchange IMAP server. Larry Osterman -Original Message- From: Mark Crispin [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 18, 2003 3:43 PM To: Timo Sirainen Cc: [EMAIL PROTECTED] On Tue, 19 Feb 2003, Timo Sirainen wrote: Must parent mailboxes be listed before their children? I don't see this defined anywhere, but I know some clients will break if they're not. There is no such requirement; and clients which presume such are broken. UW imapd always lists parents before their children, but that's an artifact of how it is implemented; in most of its supported mail stores it is unaware of children until it is aware of the parent. However, there is nothing that precludes a mail store from working differently. Consider a mail store in which the names are flat, but by convention . is a hierarchy delimiter and % breaks on .. Unless that mail store is careful to sort its names, a child could conceivably be listed before a parent. Requesting LIST mail/% from UW imapd shows also mail/ in the reply, is this required? Yes. RFC 2060, bottom of page 31: [...] If the % wildcard is the last character of a mailbox name argument, matching levels of hierarchy are also returned. If these levels of hierarchy are not also selectable mailboxes, they are returned with the \Noselect mailbox name attribute (see the description of the LIST response for more details). Although the intent of this rule was for directories within mail/ the zero or more characters matching rule for wildcards requires that mail/ also match. I think this falls into the server implementations are permitted to hide.. clause? Are there any clients that break if this isn't sent? And is there any point in sending it anyway? I'd just have to add extra code for that. I don't know if any clients would break. I think that most clients would ignore it. However, do you really want to take a chance that some client won't break, and have that section of RFC 2060 flung at you as proof of your non-compliance? It also does something useful. It differentiates between the mail/ exists and is empty and mail/ does not exist. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate.
RE: What is Outlook waiting for?
If I had to hazard a guess, it's because you didn't send a PERMANENTFLAGS response on the select. If that's the case, it's probably an outlook bug because I don't believe that PERMANENTFLAGS is a manditory response to select, but Larry Osterman -Original Message- From: John Doty [mailto:[EMAIL PROTECTED]] Sent: Monday, February 10, 2003 12:05 AM To: [EMAIL PROTECTED] Subject: What is Outlook waiting for? So, I'm monkeying around with a (minimal) IMAP server implementation, and I'm trying to get Outlook XP to talk to it. When I point it at the server and hit F5, it hangs at Check for new mail. Apparently, it is waiting for some information from my server that I don't think I have. Here is our conversation (S is the server, C is Outlook XP): 127.0.0.1:2088: S: * OK HELLO 127.0.0.1:2088: joined 127.0.0.1:2088: C: 000H CAPABILITY 127.0.0.1:2088: S: * CAPABILITY IMAP4rev1 127.0.0.1:2088: S: 000H OK CAPABILITY completed 127.0.0.1:2088: C: 000I LOGIN john john 127.0.0.1:2088: S: 000I OK LOGIN completed 127.0.0.1:2089: S: * OK HELLO 127.0.0.1:2089: joined 127.0.0.1:2089: C: 000J CAPABILITY 127.0.0.1:2089: S: * CAPABILITY IMAP4rev1 127.0.0.1:2089: S: 000J OK CAPABILITY completed 127.0.0.1:2089: C: 000K LOGIN john john 127.0.0.1:2089: S: 000K OK LOGIN completed 127.0.0.1:2088: C: 000L SELECT INBOX 127.0.0.1:2088: S: * 0 EXISTS 127.0.0.1:2088: S: * 0 RECENT 127.0.0.1:2088: S: * OK [UIDVALIDITY 512553089] UIDs valid 127.0.0.1:2088: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 127.0.0.1:2088: S: 000L OK [READ-WRITE] SELECT completed 127.0.0.1:2089: C: 000M LSUB * 127.0.0.1:2089: S: * LSUB () / INBOX 127.0.0.1:2089: S: * LSUB () / Sent Items 127.0.0.1:2089: S: * LSUB () / Drafts 127.0.0.1:2089: S: * LSUB () / INBOX/Baz 127.0.0.1:2089: S: * LSUB () / INBOX/Baz/Bar 127.0.0.1:2089: S: 000M OK LSUB completed 127.0.0.1:2089: C: 000N STATUS Drafts (UNSEEN) 127.0.0.1:2089: S: * STATUS Drafts (UNSEEN 0) 127.0.0.1:2089: S: 000N OK STATUS completed 127.0.0.1:2089: C: 000O STATUS INBOX/Baz (UNSEEN) 127.0.0.1:2089: S: * STATUS INBOX/Baz (UNSEEN 0) 127.0.0.1:2089: S: 000O OK STATUS completed 127.0.0.1:2089: C: 000P STATUS INBOX/Baz/Bar (UNSEEN) 127.0.0.1:2089: S: * STATUS INBOX/Baz/Bar (UNSEEN 0) 127.0.0.1:2089: S: 000P OK STATUS completed 127.0.0.1:2089: C: 000Q STATUS Sent Items (UNSEEN) 127.0.0.1:2089: S: * STATUS Sent Items (UNSEEN 0) 127.0.0.1:2089: S: 000Q OK STATUS completed 127.0.0.1:2088: C: 000R NOOP 127.0.0.1:2088: S: 000R OK NOOP completed It logs in, selects INBOX, then does a NOOP, and sits. (It makes another connection, checks out the subscriptions, and asks for the count of UNSEEN messages on all the other mailboxes.) I'm guessing that it wants me to send something with that NOOP, but I just can't figure out what. I've already told it I don't have any messages for it, and that hasn't changed... john -- - For information about this mailing list, and its archives, see: http://www.washington.edu/imap/imap-list.html -
RE: What is Outlook waiting for?
AFAIK PERMANENTFLAGS is only optional when you have NO flags that persist. PERMANENTFLAGS is the set of flags that persist beyond the lifetime of the SELECT command. FLAGS is the set of flags that are legal on the current mailbox. They are not necessarily the same set. Larry Osterman -Original Message- From: John Doty [mailto:[EMAIL PROTECTED]] Sent: Monday, February 10, 2003 10:13 AM To: Larry Osterman; [EMAIL PROTECTED] Subject: RE: What is Outlook waiting for? I modified it to return a PERMANENTFLAGS response, but that didn't seem to help. (Just so that I can believe I understand the RFC, PERMANENTFLAGS is optional when it does not differ from the set of flags you returned with the FLAGS status, right? It would gall me to have to include it just because uw-imap does...) john -Original Message- From: Larry Osterman [mailto:[EMAIL PROTECTED]] Sent: Monday, February 10, 2003 9:32 AM To: John Doty; [EMAIL PROTECTED] If I had to hazard a guess, it's because you didn't send a PERMANENTFLAGS response on the select. If that's the case, it's probably an outlook bug because I don't believe that PERMANENTFLAGS is a manditory response to select, but Larry Osterman -Original Message- From: John Doty [mailto:[EMAIL PROTECTED]] Sent: Monday, February 10, 2003 12:05 AM To: [EMAIL PROTECTED] Subject: What is Outlook waiting for? So, I'm monkeying around with a (minimal) IMAP server implementation, and I'm trying to get Outlook XP to talk to it. When I point it at the server and hit F5, it hangs at Check for new mail. Apparently, it is waiting for some information from my server that I don't think I have. Here is our conversation (S is the server, C is Outlook XP): 127.0.0.1:2088: S: * OK HELLO 127.0.0.1:2088: joined 127.0.0.1:2088: C: 000H CAPABILITY 127.0.0.1:2088: S: * CAPABILITY IMAP4rev1 127.0.0.1:2088: S: 000H OK CAPABILITY completed 127.0.0.1:2088: C: 000I LOGIN john john 127.0.0.1:2088: S: 000I OK LOGIN completed 127.0.0.1:2089: S: * OK HELLO 127.0.0.1:2089: joined 127.0.0.1:2089: C: 000J CAPABILITY 127.0.0.1:2089: S: * CAPABILITY IMAP4rev1 127.0.0.1:2089: S: 000J OK CAPABILITY completed 127.0.0.1:2089: C: 000K LOGIN john john 127.0.0.1:2089: S: 000K OK LOGIN completed 127.0.0.1:2088: C: 000L SELECT INBOX 127.0.0.1:2088: S: * 0 EXISTS 127.0.0.1:2088: S: * 0 RECENT 127.0.0.1:2088: S: * OK [UIDVALIDITY 512553089] UIDs valid 127.0.0.1:2088: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 127.0.0.1:2088: S: 000L OK [READ-WRITE] SELECT completed 127.0.0.1:2089: C: 000M LSUB * 127.0.0.1:2089: S: * LSUB () / INBOX 127.0.0.1:2089: S: * LSUB () / Sent Items 127.0.0.1:2089: S: * LSUB () / Drafts 127.0.0.1:2089: S: * LSUB () / INBOX/Baz 127.0.0.1:2089: S: * LSUB () / INBOX/Baz/Bar 127.0.0.1:2089: S: 000M OK LSUB completed 127.0.0.1:2089: C: 000N STATUS Drafts (UNSEEN) 127.0.0.1:2089: S: * STATUS Drafts (UNSEEN 0) 127.0.0.1:2089: S: 000N OK STATUS completed 127.0.0.1:2089: C: 000O STATUS INBOX/Baz (UNSEEN) 127.0.0.1:2089: S: * STATUS INBOX/Baz (UNSEEN 0) 127.0.0.1:2089: S: 000O OK STATUS completed 127.0.0.1:2089: C: 000P STATUS INBOX/Baz/Bar (UNSEEN) 127.0.0.1:2089: S: * STATUS INBOX/Baz/Bar (UNSEEN 0) 127.0.0.1:2089: S: 000P OK STATUS completed 127.0.0.1:2089: C: 000Q STATUS Sent Items (UNSEEN) 127.0.0.1:2089: S: * STATUS Sent Items (UNSEEN 0) 127.0.0.1:2089: S: 000Q OK STATUS completed 127.0.0.1:2088: C: 000R NOOP 127.0.0.1:2088: S: 000R OK NOOP completed It logs in, selects INBOX, then does a NOOP, and sits. (It makes another connection, checks out the subscriptions, and asks for the count of UNSEEN messages on all the other mailboxes.) I'm guessing that it wants me to send something with that NOOP, but I just can't figure out what. I've already told it I don't have any messages for it, and that hasn't changed... john -- - For information about this mailing list, and its archives, see: http://www.washington.edu/imap/imap-list.html -
RE: outlook express
Umm... I really did mean the protocol log - showing the creation of the mailbox if possible. You may have to get it from the server, I can't see where to turn it on in the current OE. I'm still not 100% convinced this isn't a user error/poor defaults on the part of OE. Just because Outlook works doesn't necessarily mean it's a bug in OE, since they are totally different paradigms. The error in your email indicates that the server felt that the folder called Mail/Admin wasn't selectable. That implies that the folder was created with a trailing / character, which means that it can't hold email (and thus isn't selectable). But without knowing the protocol messages that were sent when the folder was created, there's not much that can be done :( Larry Osterman -Original Message- From: Steve Dame [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 05, 2003 1:17 PM To: Larry Osterman; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: outlook express Larry, Related to this thread of discussion, do you have any information as to when M$ is going to fix the bug in OE6 related to clicking on subfolders in the explorer list contained within OE? Has it been confirmed as a bug and someone assigned to fix it??? It is the only thing lacking in an otherwise great client implementation when it comes to interfacing to the UW/IMAP system. In my example, I have a /Mail folder and then serveral folders under /Mail one of which is /Mail/Admin. If I try and select Admin, I get this error dialog in the attached file. It is a benign error, but just simply mars the otherwise good client implementation. -Steve - Original Message - From: Larry Osterman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, February 05, 2003 12:28 PM Subject: RE: outlook express Ok, then the protocol log will be required to diagnose this any further. Larry Osterman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 05, 2003 12:24 PM To: Larry Osterman Subject: RE: outlook express Quoting Larry Osterman [EMAIL PROTECTED]: If you're using U.W, then the chances are that it's a client bug, but first When you create the folders, do you create them with a trailing / character? U.W. (and technically the IMAP protocol) does not have the concept of folders, instead it has the concept of mailboxes. In the default U.W. message store, mailboxes cannot hold other mailboxes (in other words, they don't behave like directories in the filesystem). As a result, if you want to create something to hold mailboxes, you need to create the folder using a trailing / character - that's a hint to the U.W. message store that you want to create a container, not a mailbox. Is it possible that you're seeing something like this happen? I don't think so. Only Outlook Express is experiencing this, Outlook 2000 work fine. Larry Osterman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 05, 2003 9:38 AM To: Larry Osterman Subject: RE: outlook express Quoting Larry Osterman [EMAIL PROTECTED]: Thank you. I'm using UWIMAP for Sendmail 8.12.5 If you turn on outlook's protocol logging (there's an option on the server page), it might be helpful to send the relevant parts of the log to help diagnose the problem. I don't know what IMAP server you're using, or why the error is occurring, the protocol log would help figure that out Larry Osterman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 05, 2003 8:05 AM To: [EMAIL PROTECTED] Subject: outlook express This email is beyond the scope of this community but I'm going to ask this question because, us, IMAP administrators, maybe have seen this issue. First of all, IMAP is working superbly. My issue is that when I try to create email folders on Outlook Express, I get the following error: an unknown error has occurred or SUBSCRIBE COMPLETED. I do not see the folder on the client or server. When I use Horde's webmail client, it works. Obviously, its an M$ issue but Microsoft's KB has not been helpful. Any suggestions would be greatly appreciated and I promise I will not take advantage of this community for issues that are not related to IMAP. Rodney - Get a Room at http://www.lodging.com
RE: speaking of storing flags
Actually there IS a relatively (6ish years old) precedent. Trumpet Winsock (a free-ware Windows TCP implementation that was VERY popular in the pre-win95 days before a certain evil monopoly decided to destroy the 3rd party TCP/IP stack market by (gasp!) actually including an implementation of TCP/IP in their product) had a hard-coded 2 connection limit. A windows machine running trumpet could ONLY connect to two remote sockets simultaneously without changing magic ini file parameters. Once again, we got burned horribly by that when we were testing the windows version of the Exchange client over trumpet - the instant you tried to talk to a second public folder server, the client failed in mysterious ways and I was the poor sod who got stuck with figuring it out. So there ARE situations where connections are expensive. But not in a modern operating system. Larry Osterman -Original Message- From: Mark Crispin [mailto:[EMAIL PROTECTED]] Sent: Monday, January 27, 2003 11:22 PM To: Timo Sirainen Cc: [EMAIL PROTECTED] Subject: Re: speaking of storing flags On Mon, 28 Jan 2003, Timo Sirainen wrote: Multiple connections eat more memory and more network resources. How did you arrive at this conclusion? I suggest that you have fallen prey to an urban myth. Like most myths, there is a vestige of historical truth; in the NCP protocol used prior to 1983, network connections did consume costly resources. This was one of the things that TCP fixed. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate.
RE: speaking of storing flags
Oooh, that IS nasty then. It's almost as if the permanentflags on a folder can change dynamically. As I said in my first reply - the clients ARE unquestionably broken. As you said - if they do a store, and then someone else does a store, this is exactly the state that they'll see. So they are NOT respecting the store response. However to comply with 7.1, I think you still need to shadow the \Seen flag state, even though the \Seen flag's in the permanentflags. I know we did in Exchange (our case was more fundamental, in our case, \Seen could be set but not any of the other message flags because the Exchange store stores the read/unread state on a public folder as a per-user value). Have you tried doing: C: . STORE * FLAGS (\Seen) S: * 999 FETCH FLAGS () S: * 999 FETCH FLAGS (\Seen) S: . OK Fetch completed And see if that makes the clients happy? I don't know if it would but it might be worth a try. It's a total absolute hack but Larry Osterman -Original Message- From: Rick Block [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 28, 2003 10:31 AM To: Larry Osterman Cc: Mark Crispin; [EMAIL PROTECTED] Subject: Re: speaking of storing flags Larry, The server I'm working on does allow the \seen flag to be set, but unfortunately when it's set it is actually permanently set (facetious comment: isn't this exactly what the spec demands?). I realize from a user interface view this is not good, but I think the behavior I describe complies with the protocol (from the client's viewpoint, what might be happening is ***another client*** is setting the \seen flag shortly after it's been cleared). I haven't tried sending both an untagged fetch indicating the \seen flag has been cleared followed by an untagged fetch indicating it's been set again (I'll have to try this), maybe this might make the client happier. -Rick Block Larry Osterman wrote: Mark, I'm 99% sure that there's text in the spec that indicates that flag changes must take effect - they don't need to be permanent, but they do need to take effect (as I mentioned in my previous mail, we got burned by that on Exchange at one point). Obviously you wrote the text, so you should know but let me see if I can find the reference Time Passes Ah, here it is. Section 7.1: PERMANENTFLAGS Followed by a parenthesized list of flags, indicates which of the known flags that the client can change permanently. Any flags that are in the FLAGS untagged response, but not the PERMANENTFLAGS list, can not be set permanently. If the client attempts to STORE a flag that is not in the PERMANENTFLAGS list, the server will either reject it with a NO reply or store the state for the remainder of the current session only. The PERMANENTFLAGS list can also include the special flag \*, which indicates that it is possible to create new keywords by attempting to store those flags in the mailbox. Larry Osterman -Original Message- From: Mark Crispin [mailto:[EMAIL PROTECTED]] Sent: Monday, January 27, 2003 7:22 PM To: Rick Block Cc: [EMAIL PROTECTED] Subject: Re: speaking of storing flags On Mon, 27 Jan 2003, Rick Block wrote: I'm working on a server that cannot make a message unseen once it's been marked seen. I've tried returning untagged fetch responses to store attempts to clear the seen flag, like so (assuming message 1 is already seen): c: xyzzy store 1 -flags (\seen) s: * 1 fetch (flags (\seen)) s: xyzzy OK This is the correct thing for your server to do. If your server supports ACL (RFC 2086), it should not offer the s right. Now, I would prefer that your server allow alteration of the \Seen flag, but it *is* compliant. If your server didn't support the \Seen flag at all, a better behavior would be to omit \Seen in the PERMANENTFLAGS list and allow setting/clearing \Seen in the session. What you have is slightly different; you have a flag that can be set but not cleared. but the clients I've tried (Outlook Express 5 and a fairly old version of Netscape Communicator) seem to completely ignore the untagged response (the message starts out looking seen in the client, after marking the message unseen via their user interface even with the untagged fetch response the message is displayed as unseen). I consider both of these clients to be broken. Your situation is one of the reasons why the STORE command returns an untagged FETCH. I bet that if you try it with Pine, you'll get the behavior that you expect. I've tried a NO response; this is treated as a protocol error by these clients. I don't think that a NO response should ever be issued in response
RE: question about multipart/related and IMAP servers
Title: Message It takes place on the Exchange 5.5 server. I don't know why 5.5 wouldn't generate a full fidelity output stream on a m/r message, but that's undoubtedly where the failure is occurring. If you send me the original message as a .eml file, I can send it to the QFE guys to see what's going on Exchange 2000 maintains 100% full fidelity with the input MIME stream so you shouldn't see any problems with that. Larry Osterman -Original Message-From: Sang Park [mailto:[EMAIL PROTECTED]] Sent: Friday, December 20, 2002 11:46 AMTo: '[EMAIL PROTECTED]'Subject: question about multipart/related and IMAP servers I am sending out a message with multipart/related content-type (from outlook express). but when i forward this message to several different accounts (exchange 5.5, exchange 6.0, netscape 4.15, cyrus) i get two types of MIME messages. one where the original mime is left intact (exchange 6.0 and netscape 4.15) and another where the multipart/related has been changed to mutlipart/mixed. Does anyone know where this alteration takes place (the outlook client, the smtp server, the MTA or the IMAP server)? any help would be greatly appreciated. Thanks sang park
RE: Has IMAP been a slow starter?
IMHO, the biggest reason IMAP hasn't caught on more is simply that ISPs have no economic incentive to offer IMAP services. In the corporate space, there are many incentives to offer IMAP - server-centric email storage is a GOOD thing - you have centralized backup, the opportunity for centralized virus scanning, etc. But in the ISP space (which is 99% of all email users), server-centric email storage is a BAD thing. Email on the ISP's server==more hard disk space being used by the users==more costs for the ISP. The ISP could go to a IMAP costs more model but I don't think that they've got a good story to justify the extra costs for the customer. The only currently existing business model for server-hosted email is the hotmail model - the customers email is kept on the server, primarily to allow the server the opportunity to plaster ads in the customers face. So I suspect that IMAP will continue to grow in the corporate environment, but given the current technology, in the end-user space, it's probably a non-starter. On the other hand, I do agree with you w.r.t. mobility. If there's anything that's going to break IMAP loose in the ISP space, it's mobile devices - when you're dealing with small devices, then server-centric email storage is a requirement, and I suspect that small devices may be the thing that makes IMAP reach critical mass. Larry Osterman -Original Message- From: Pete Maclean [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 10, 2002 8:46 AM To: [EMAIL PROTECTED] Subject: Has IMAP been a slow starter? A customer recently posed the following question to me: I am curious about something based upon observation.Has IMAP been a slow starter because most people do not understand its capabilities intuitively?? From what I have seen, people understand at least some of the sharing and folder features of MS Exchange and most of the capabilities of POP. But these same people do not seem to understand that there is a protocol difference between the two and that sharing and folder access is enabled through this protocol. Has this been your experience as well?? Also, do you think that imap.org does a good job about getting the word out about IMAP?? I am unable to do a good job of answering this and wonder if anyone out there on the list would like to chime in with some helpful comments. I would like to create a good answer partly because the customer concerned has been extraordinarily helpful to me in marketing my IMAP products and partly because I would like to gain a better grasp of these matters myself. I consider my technical knowledge of IMAP to be excellent but my cultural knowledge of it is hazy. I will offer a few ideas that I would include in a response and I invite people to critique them. Has IMAP been a slow starter? I think it has although it is also true that it is well used in certain quarters. Is it hard to understand its capabilities intuitively? I think this is true. For example, there are excellent reasons why IMAP includes no facilities for sending messages but those reasons are rather technical and may seem strange to an average email user. I think it may also be difficult to get a grasp of what IMAP can do because of the way that clients implement it. Not that clients should expose IMAP capabilities as such but many clients make poor use of them. Why has IMAP not caught on more? Many email service providers have no incentive to provide IMAP support. Or is that the wrong way to look at it? Email providers could perhaps do better by offering IMAP as an extra, at a price. But maybe there would be too few takers? I feel strongly that another reason IMAP has not caught on is because of the sorry state of clients. While there are a couple of glowing exceptions, the state of IMAP support in general among popular clients is a disgrace. Should IMAP catch on more? I think it should and I think it will. The biggest reason that I see is mobility. (My view that this is the biggest reason may be created by the market that I operate in.) When you want to read your mail from a handheld device (be it a PDA, mobile phone, or something else), IMAP is ideal. You can arrange for your mail to be stored in one place and access any piece of it from your device. You can selectively access the various components of a message. You can search folders -- with awesome search power. The trouble is that there is no email client I know of for handheld devices that has anything like a complete implementation of IMAP, never mind one that works very well. (Although I have a wee notion that this situation could change for one particular PDA, the Sharp Zaurus.) Do I think that imap.org does a good job about getting the word out about IMAP? I have little idea. I am not even sure that that is a purpose imap.org is intended for. My thanks in advance for any comments, Pete Maclean
RE: Mailbox names containing hierarchy separator
Umm... Actually we ran into this about 5 years ago with the Exchange server. The simple answer is lump it. The Exchange server filters all folders with the hierarchy separator character in them. Our users were a bit surprised when they discovered this but they learned to cope. It's not pleasant for those stores that allow hierarchy characters in the mailbox, but this is fundimentally a limitation of the protocol. The U+2215 option IS viable, however you will run into other clients that cannot cope with receiving the unicode characters and choke on them (clients on non unicode-enabled Operating systems like Win9x come to mind immediately). That's why we decided not to go down that route for the Exchange server, ymmv Larry Osterman -Original Message- From: Grant Baillie [mailto:gbaillie;apple.com] Sent: Friday, November 15, 2002 11:20 AM To: [EMAIL PROTECTED] Subject: Mailbox names containing hierarchy separator Sometimes, users will want to create mailboxes whose names contain the hierarchy separator. A common case is to have dates in the name (say, Work - 11/02) when the server's separator is /. They are, not unnaturally, surprised at the results, since they expected to get a single mailbox, not two levels of hierarchy. (Presumably, this isn't so big deal for clients which present the output of LIST more or less directly, but most clients don't do that because it doesn't scale very well). A couple of ideas for dealing with that I can think of are: 1) For /, use a Unicode character like U+2215, which will display approximately the way the user expects. I think there's a similar unichar for . and maybe even \. 2) Modified UTF-7 encode the separator to get the mailbox name. I think this is illegal according to Section 5.1.3 (Mailbox International Naming Convention) of the spec, though. Any comments/suggestions would be welcome --Grant - Grant Baillie [EMAIL PROTECTED] Mac OS X Mail, Apple Computerm, Inc - -- - For information about this mailing list, and its archives, see: http://www.washington.edu/imap/imap-list.html - -- - For information about this mailing list, and its archives, see: http://www.washington.edu/imap/imap-list.html -
RE: Empty mailbox Fetch. Was: possible draft 19 changes for sequence
I'll just jump into a teeny tiny part of your objections: About BAD: There are three possible server completion responses: OK (indicating success), NO (indicating failure), or BAD (indicating protocol error such as unrecognized command or command syntax error). If FETCH 2:2 cannot be used right now, becase we have only one message in that mailbox, it is a failure, not an unrecognized command or command syntax error (even if we say in the syntax rules that seq_numbers used in the seq_subset should be not greater than the # of messages in the mailbox - it's not a syntax rule). The critical word here is such. The text doesn't indicate that BAD can ONLY be returned for unrecognized commands or syntax errors, the text indicates that AMONG the reasons for returning a BAD response is unrecognized commands or syntax errors. There is a critical difference between the two words (ONLY and AMONG). Since the following sequence is illegal by the protocol, it is appropriate that it be tagged with BAD - there only way that this sequence can be generated is if the client has an error that has caused it to misinterpret the protocol stream: S: * 1 EXISTS S: tag OK C: tag FETCH 2 S: tag BAD - Message 2 does not exist. Since message sequence number 2 does not exist, it is a protocol error to request it. The determination of whether or not it is a protocol error is based solely on the fact that the client HAS BEEN TOLD that message 2 doesn't exist (that happened when the client received the * 1 EXISTS untagged response). On the other hand, it is NOT a protocol error for the following to occur: S: * 2 EXISTS S: tag OK C: tag FETCH 2 S: * 2 EXPUNGE S: * FETCH 2 (NIL) S: tag OK Fetch completed but message deleted. In that case, the client has not yet been told that the message identified by sequence number 2 is gone, and the client DOES know that that the message exists, so it's legal for the client to request the data. Please note that one of the fundimental principals of IMAP (which is called out in the spec, but I'm not sure where) is that both the client AND the server know the state of their corresponding part. So the client needs to know the state of all the messages in the mailbox on the server, and the server needs to know what the client's state of the mailbox is. Fortunately for server implementations, the server can assume that the client has heard and understood everything that the server has sent to the client, and thus only has to keep track of what it sent to the client. Larry Osterman -Original Message- From: Vladimir A. Butenko [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 26, 2002 8:38 AM To: Mark Crispin Cc: [EMAIL PROTECTED] Subject: Re: Empty mailbox Fetch. Was: possible draft 19 changes for sequence On Wed, 25 Sep 2002 08:34:10 -0700 (PDT) Mark Crispin [EMAIL PROTECTED] wrote: On Wed, 25 Sep 2002 07:39:40 -0700, Vladimir A. Butenko wrote: If FETCH 2:2 is legal for a mailbox that contains one message, I do not understand why Fetch 1:1 is illegal in an empty mailbox, or why FETCH 1:* is illegal in an empty mailbox. FETCH 2:2 is *NOT* legal for a mailbox that contains one message. So your argument falls apart: x select foo * 1 EXISTS * 1 RECENT * OK [UIDVALIDITY 1032968134] UID validity status * OK [UIDNEXT 2] Predicted next UID * FLAGS (\Answered \Flagged \Deleted \Draft \Seen) * OK [PERMANENTFLAGS ()] Permanent flags * OK [UNSEEN 1] first unseen message in /u/mrc/foo x OK [READ-ONLY] SELECT completed y fetch 2:2 flags y BAD Bogus sequence in FETCH FETCH 2:2 is legal for a message that contains two messages. It is equivalent to FETCH 2. On the other hand... UID FETCH 2:2 is legal for all mailboxes. UID FETCH 1:1 is legal for all mailboxes. UID FETCH 1:* is legal for all mailboxes. Do you see the pattern? I see the pattern in your letter. I do not see anything resenbling this pattern in the RFC2060. Note: the phrase ; Identifies a set of messages. For message ; sequence numbers, these are consecutive ; numbers from 1 to the number of messages in ; the mailbox specifies what the sequence numbers are (hint: the word consecutive). It has NOTING to do with specification of: set = sequence-num / (sequence-num : sequence-num) / (set , set) and this: ; Comma delimits individual numbers, colon ; delimits between two numbers inclusive. Note ; that n:m and m:n are equivalent. ; Example: 2,4:7,9,12:* is 2,4,5,6,7,9,12,13, ; 14,15 for a mailbox with 15 messages. is not a proper declaration either
RE: Empty mailbox Fetch. Was: possible draft 19 changes for sequence
Crud, as always, you're right Shows I've been away from the protocol for too many years :( Larry Osterman -Original Message- From: Mark Crispin [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 26, 2002 9:17 AM To: Larry Osterman Cc: Vladimir A. Butenko; [EMAIL PROTECTED] Subject: RE: Empty mailbox Fetch. Was: possible draft 19 changes for sequence On Thu, 26 Sep 2002 09:15:34 -0700, Larry Osterman wrote: On the other hand, it is NOT a protocol error for the following to occur: S: * 2 EXISTS S: tag OK C: tag FETCH 2 S: * 2 EXPUNGE S: * FETCH 2 (NIL) S: tag OK Fetch completed but message deleted. Actually, that scenario is invalid. The server isn't allowed to send the untagged EXPUNGE in that situation. Valid scenarios which illustrate your point (albeit not as strongly): S: * 2 EXISTS S: tag OK C: tag FETCH 2 RFC822.HEADER S: * 2 FETCH (RFC822.HEADER NIL) S: tag OK Fetch completed but message deleted. C: tag NOOP S: * 2 EXPUNGE S: tag OK Here a dummy message was returned for message 2 cause the untagged EXPUNGE had to be deferred until the client did a command which permits the transmission of untagged EXPUNGE. Personally, I think that it is better, until the untagged EXPUNGE is sent, to retain a message ghosts that has all the message data. Here's another scenario that is closer to your point: S: * 2 EXISTS S: tag OK C: tag FETCH 2 UID S: * 2 FETCH (UID 23) S: tag OK C: tag UID FETCH 23 RFC822.HEADER S: * 2 FETCH (UID 23 RFC822.HEADER NIL) S: * 2 EXPUNGE S: tag OK Fetch completed but message deleted. Unlike FETCH, UID FETCH permits sending untagged EXPUNGE. However, the untagged EXPUNGE can not be sent until *AFTER* the untagged FETCH, since otherwise the 2 in the untagged FETCH would be invalid. Alternatively, the server could do the same scenario without sending any untagged FETCH: S: * 2 EXISTS S: tag OK C: tag FETCH 2 UID S: * 2 FETCH (UID 23) S: tag OK C: tag UID FETCH 23 RFC822.HEADER S: * 2 EXPUNGE S: tag OK Fetch completed but message deleted. Note that scenarios such as the latter two can never happen with message sequence numbers.
RE: possible draft 19 changes for sequence
I just checked the E2K server, and it does:
C: 1 UID FETCH * (RFC822.HEADER)
S: * 1 EXISTS
S: 1 OK done
C: 1 UID FETCH * (RFC822.HEADER)
S: * FETCH {}
S: 1 OK Done
In this scenario. And clearly the final case is incorrect.
Larry Osterman
-Original Message-
From: Mark Crispin [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 25, 2002 10:23 AM
To: Larry Osterman
Cc: Simon Josefsson; Pete Maclean; IMAP Interest List
Subject: RE: possible draft 19 changes for sequence
On Wed, 25 Sep 2002 10:20:56 -0700, Larry Osterman wrote:
Nit: Should it be should or SHOULD in The server should respond
with a tagged BAD below?
In general, I've avoided placing requirements on server handling of
errors. In my opinion, a compliant server could treat FETCH * of an
empty mailbox as the command to set the hard drive on fire, launch
nuclear missiles on Disneyland, and give the system manager a bad
haircut...
The philosophy here is GIGO (Garbage In, Garbage Out); you can't
predict subsequent behavior if you violate the standard, so don't
violate the standard.
Also, the UIDNEXT value? Is this right?
It was for lack of a better choice. The problem with saying last
assigned UID is that in a newly-created mailbox, there is no last
assigned UID and zero is not a possibility.
Mailbox is empty, client believes there are 0 messages in the inbox
Message arrives in mailbox
C: 1 UID FETCH * (RFC822.HEADER)
S: * 1 EXISTS
IMHO, this is a timing race. Either UID 1 doesn't exist at the time
that the command is executed, or it does exist. So, the scenario should
be one of:
C: 1 UID FETCH * (RFC822.HEADER)
S: * 1 EXISTS
S: 1 OK done
or
C: 1 UID FETCH * (RFC822.HEADER)
S: * 1 EXISTS
S: * 1 FETCH (UID 1 RFC822.BODY {xx}
Body of newly received message)
S: 1 OK done
I do not think that:
S: * 1 FETCH (UID 1 RFC822.BODY NIL)
should ever be returned. This is the worst of both possibilities.
Can you look into what Exchange does? Fortunately, I don't think that
it should be a major problem, since I doubt that clients will ever do
this.
Clients are much more likely to do UID FETCH 1:*. I assume that you'd
agree that
C: 1 UID FETCH 1:* (RFC822.HEADER)
S: * 1 EXISTS
S: * 1 FETCH (UID 1 RFC822.BODY NIL)
S: 1 OK done
is a definite bug!
RE: possible draft 19 changes for sequence
As Mark and I discussed earlier, the UIDNEXT item is irrelevant unless an item comes into the mailbox between the previous operation and the FETCH. And I agree with Mark that it's a race condition that can't be solved. The reality is that it's never going to happen (except for the case of a client that receives out-of-band notification of the presence of the message, which I claim is out of scope), a properly written client will never issue a FETCH for * when there are no messages in the mailbox. I understand Mark's problem here though - he has to have SOME text to describe what the UID * means in the empty mailbox case, since he's described what it means for the sequence number * in the empty mailbox. Larry Osterman -Original Message- From: Simon Josefsson [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 25, 2002 1:18 PM To: Mark Crispin; Pete Maclean; IMAP Interest List Subject: Re: possible draft 19 changes for sequence Mark Crispin [EMAIL PROTECTED] writes: On Wed, 25 Sep 2002 14:58:15 +0200, Simon Josefsson wrote: Would it improve the standard to make this more obvious? The text that the argument is based on is located inside parentheses in a comment inside the ABNF without saying how to handle the error or why it is an error. Well, sections 5.5 and 7.4.1 don't do that; they simply explain that it is alright for it to be an error. Here's my latest stab at the rule for seq-number. I hope this is clearer? It looks alright. seq-number = nz-number / * ; message sequence number (COPY, FETCH, STORE ; commands) or unique identifier (UID COPY, ; UID FETCH, UID STORE commands). ; * represents the largest number in use. In ; the case of message sequence numbers, it is ; the number of messages in a non-empty mailbox. ; In the case of unique identifiers, it is the ; unique identifier of the last message in the ; mailbox or, if the mailbox is empty, the ; UIDNEXT value. Except possibly this new UIDNEXT thing. Cyrus IMAP for one doesn't do this. In this case I think it is better to have * mean a non-existing article instead of UIDNEXT. . select INBOX.Drafts * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen \*)] * 0 EXISTS * 0 RECENT * OK [UIDVALIDITY 1025092571] * OK [UIDNEXT 1] . OK [READ-WRITE] Completed . FETCH * UID . NO No matching messages . UID FETCH * UID . OK Completed
RE: file not deleted on Win32
I'm sure that it'll be in XPSP1, which went gold on Friday (which means it should hit the web any day now). Larry Osterman -Original Message- From: Mark Crispin [mailto:[EMAIL PROTECTED]] Sent: Monday, September 02, 2002 11:18 PM To: Larry Osterman Cc: Wolfgang Spraul; [EMAIL PROTECTED] Subject: RE: file not deleted on Win32 On Mon, 2 Sep 2002 16:03:21 -0700, Larry Osterman wrote: The fix is in SP3 of W2K That's very nice. When will the fix appear in XP? I am current on all updates from Windows Update and I can assure you that the bug is still there. FWIW, it's also broken in 9x and Me.
RE: file not deleted on Win32
The KB article is:
http://support.microsoft.com/default.aspx?scid=kb;en-us;q300562
The fix is in SP3 of W2K, I don't know why they didn't back-prop it to NT4, but I
suspect that the reason is that either (a) there weren't enough customers still using
NT4 (which is 4 years old at this point) to justify the fix, or (b) they've stopped
qfe'ing NT4 (as far as I know, they're only supporting W2K and XP at this point for
QFE unless you're a premier customer).
Is there a reason you can't switch to W2K?
Larry Osterman
-Original Message-
From: Wolfgang Spraul [mailto:[EMAIL PROTECTED]]
Sent: Sunday, September 01, 2002 3:07 PM
To: Larry Osterman; [EMAIL PROTECTED]
Subject: Re: file not deleted on Win32
Larry -
my reason for switching was the well known Q300562 (couldn't
find it in the
web version of the MSDN).
That's an issue on NT4 where a buffer size is not correctly
calculated. A fix
exists but is only available through MS support. Since
getting the fix
through MS support would have cost me time and/or money, I opted for
switching to OpenSSL, which was remarkably easy.
Please consider making the fix publicly available (and
redistributable).
Regards,
Wolfgang Spraul
On Sunday 01 September 2002 11:23 pm, Larry Osterman wrote:
If you can explain the buggy schannel.dll problems, I can
forward them to
the schannel developers.
As long as you're not referring to the cert chain issue,
I'm sure they know
about that one :)
Larry Osterman
-Original Message-
From: Wolfgang Spraul [mailto:[EMAIL PROTECTED]]
Sent: Saturday, August 31, 2002 12:10 PM
To: [EMAIL PROTECTED]
Subject: file not deleted on Win32
Please consider the following patch for inclusion. On Win32,
you cannot delete
an open file (the delete will fail), so in this case we
should do the
close(fd) first, and then the unlink(tmp).
I understand that ssl_unix.c is not meant to be compiled on
Win32, but the
Microsoft SSL implementation schannel.dll is buggy, and
having the option to
choose OpenSSL on Win32 is nice. At least that's what we do.
This bug was found and fixed by Peter Boos.
Regards,
Wolfgang Spraul
Index: src/osdep/unix/ssl_unix.c
===
RCS file: /cvsroot/srclib/imports/imap/src/osdep/unix/ssl_unix.c,v
retrieving revision 1.1.1.1
diff -u -u -r1.1.1.1 ssl_unix.c
--- src/osdep/unix/ssl_unix.c 16 Jul 2002 20:48:40
- 1.1.1.1
+++ src/osdep/unix/ssl_unix.c 31 Aug 2002 18:59:05 -
@@ -92,10 +92,10 @@
if ((fd = open (tmpnam (tmp),O_WRONLY|O_CREAT,0600)) 0)
i = (unsigned long) tmp;
else {
- unlink (tmp); /* don't need the file */
fstat (fd,sbuf); /* get information about the file */
i = sbuf.st_ino;/* remember its inode */
- close (fd); /* or its descriptor */
+ close (fd); /* don't need the descriptor */
+ unlink (tmp); /* or the file */
}
/* not great but it'll have to do */
sprintf (tmp + strlen (tmp),%.80s%lx%lx%lx,
--
-
For information about this mailing list, and its archives, see:
http://www.washington.edu/imap/imap-list.html
-
RE: INBOX by any other name
INBOX may also be present under another name??? That's surprising to me. Since Exchange treats the user's primary delivery point as a localizable entity (Boite d'envoi), the Exchange IMAP server suppresses the name of the real primary delivery point and replaces it with INBOX because we figured that people would get confused if they saw them. Larry Osterman -Original Message- From: Arnt Gulbrandsen [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 09, 2002 8:45 AM To: [EMAIL PROTECTED] Subject: INBOX by any other name 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? --Arnt -- - For information about this mailing list, and its archives, see: http://www.washington.edu/imap/imap-list.html - -- - For information about this mailing list, and its archives, see: http://www.washington.edu/imap/imap-list.html -
RE: max+1:* fetches
There is no requirement in the protocol that max be higher than min in a message set. So 1601:1600 is the same as 1600:1601, and thus the second response is correct. Larry Osterman -Original Message- From: Gaël Roualland [mailto:[EMAIL PROTECTED]] Sent: Friday, May 31, 2002 5:36 AM To: Alexey Melnikov Cc: Paul Smith; [EMAIL PROTECTED] Subject: Re: max+1:* fetches Alexey Melnikov a écrit : Paul Smith wrote: 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 (\Seen)) 1 OK FETCH completed. The first one. No, the second one, because * is translated to 1600 for UIDs. Yes, * is translated for 1600, so that gives the range 1601:1600. But does that have sense ? (general understanding is probably that the second sequence number must be larger or equal to the first one, but I can't find it in the RFC). Gaël. -- Gaël Roualland -+- [EMAIL PROTECTED]
RE: Outlook express AUTH command
SPNEGO is RFC2831, if it helps :) Larry Osterman -Original Message- From: Marek Kowal [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 28, 2002 2:15 AM To: '[EMAIL PROTECTED]' Subject: RE: Outlook express AUTH command Whaw. I never expected to start such a discussion on this list. And almost completely OFF-topic, I must admit. Guys, I did not ask question: do you think that MS is right not to publish RFC for NTLM. In fact, I do not care. What I care, are customers of our POP3/WebMail service - and their exact number has SEVEN digits - who mostly use OutlookExpress or Outlook and who connect to our mailboxes. I hoped my question was clear, but I'll rewrite it a bit: What authorization method can I implement on my servers (installing Exchange or any Win2k service is out of question), which will allow us to securely authenticate our users and which will not use SSL? SSL is quite expensive, we would have to significantly increase our hardware base. And anyway, I am not interested in encrypting mail contents - I just want to keep passwords secure. Still, I've read all that discussions and attacks (mostly on Larry, as if his name was Larry Gates, not Larry Osterman) and managed to find two clues: one is SPNEGO and the other DIGEST. So I have four questions (and I mean to get answers on them, not the philosophical points of view, please): 1) which OE clients do support it? Does OE5.0 do? Or only OE6.0, which - at that point - is not really wide spread? 2) Can somebody point me to any resources on SPNEGO/DIGEST? I know, 45 secs. on MSDN would do, but I believe experts on this list will know much better what is really worth reading. 3) Is anybody implementing (has already implemented) any of those in Unix world. Can it be done outside Windows platform, or the RFC will not be published and this is again some proprietary thing? 4) What POP3 CAPA (or IMAP4 CAPABILITY) AUTH=XXX response should be presented to client, so that it starts negotiating DIGEST? AUTH=DIGEST? This would allow me quickly to check, which clients will try to negotiate it, event without actually implementing it. There is also another one, this might be more to your liking: is SPNEGO/DIGEST really good/secure? Why is it better/worse than CRAM-MD5? Frankly, I'd love to have first four questions answered before we start discussion on that one. Cheers, Marek. -Original Message- From: Marek Kowal [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 27, 2002 6:57 PM To: '[EMAIL PROTECTED]' Subject: Outlook express AUTH command Hi there, This is not really IMAP related question, but: Does anybody know, what AUTH modes are supported by Outlook Express? I've just heard that APOP or CRAM-MD5 is not supported. Only LOGIN is, and this is not real password protection, since this is just BASE64 login/password encryption and anyone can decrypt them. So how can I connect securely to server with OE, except for SSL? BTW, will UW-IMAP support NTLM authentication? Is there any Open Source server, that does? Cheers, Marek. -- - For information about this mailing list, and its archives, see: http://www.washington.edu/imap/imap-list.html -
RE: Outlook express AUTH command
Bob, Again, I am not a lawyer, but my brother IS a lawyer (he specializes in intellectual property law in fact), and he and I had a discussion about the viral nature of GPL and how deep its tenticles can extend a couple of weeks ago. It is his opinion that this is NOT clear, and that my concerns are NOT complete nonsense, due to the license covering algorithms and principals, there ARE scenarios where the GPL can unintentionally infect other non GPL code. They ARE obscure, but they ARE possible. This is a purely hypothetical scenario, but I don't believe it's beyond reason: A developer who works on SQL Server (call him Joe) also happens to play around with the Linux filesystem. At some point in the future, the powers that be in the SQL Server group at Microsoft decide to implement a feature that mirrors something in the Linux filesystem. If Joe works on this feature (or talks to someone who works on this feature),it is entirely possible that a non obvious algorithm (or non obvious implementation of that algorithm) that that person found in the source code would make its way into the Microsoft code, and we ship this in a future release. Now someone at Oracle notices this new feature in SQL server and realizes that Microsoft is copying some feature in the Linux filesystem. He asks around and discovers that Joe has been asking questions about the Linux filesystem on some of the public linux boards. And now the legal boys at Oracle sue Microsoft for violating the GPL, since it's possible that Joe has influenced the SQL server implementation. During discovery, the court suppoenas the source code for SQL server, hands it to a 3rd party expert, who discovers the algorithm from the linux filesystem in SQL server. And the court rules that due to the wording of the GPL, the entire source code of SQL server has to be released as open source. This is a REAL stretch, it relies on a lot of things happening that may never ever happen, but it IS possible. I personally have had something similar happen to me. When I realized what I had done, I immediately ripped out my implementation, and contacted LCA. The upshot is that I asked 3 other people on my team write a version of the algorithm. I then had my manager chose which of the 3 implementations we would use in the product, since I had to completely divorce myself from the implementation. Microsoft LCA is being as conservative as it is possible, even to the point of hysteria. This is a very good thing IMHO. That's why it takes a Senior VPs approval and LCA looking over your shoulder before you can even look at a piece of open source software at Microsoft. It CAN be done, but it's not easy. If you look at the IBM effort, as far as I know, the IBM employees that work on Linux don't also work on their proprietary closed source software (Barry, PLEASE correct me if I'm wrong), for the same reasons. All Microsoft employees work on proprietary closed source software, so they all need to be protected. And I DO apologize for the use of bigoted. It was unnecessarily inflamitory. Larry Osterman -Original Message- From: RL 'Bob' Morgan [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 28, 2002 1:02 AM To: Larry Osterman Cc: IMAP interest list Subject: RE: Outlook express AUTH command Larry: I really don't want to dive into this swamp, but I am concerned that no one be misled by your comments. I'm sure that you are accurately reporting the approach Microsoft takes to dealing with open-source code with its products and its programmers, and I suspect you are accurately describing the sad muddle of misunderstanding that this has likely, and unfortunately, created in its technical staff about these issues. But your comments on (1) re-release of code under GPL somehow affecting previous releases of that code under other licenses, and (2) copyright potentially covering concepts (algorithms) as well as expressions are simply complete nonsense. Copyrights cover expressions, concepts/mechanisms/algorithms are covered, if at all, by patents. (There is an increasing incidence of corporate-driven royalty-free patent licensing arrangements with constraints that look a lot like the GPL, but that's another story.) Code is often, these days, released under multiple licenses; it is up to users of code to choose the license that best fits their needs, and to abide by its terms. There are, as you note, a wide range of approaches to these issues among major software vendors. The fact that IBM, for one example, which sells a huge amount of proprietary, closed-source software, also employs people to work on Linux and other GPL codebases, might lead the rational observer to think that Microsoft's position is not conservative, but hysterical. Microsoft has every right to take that position, but others are well-advised not to be swayed by Microsoft's extremism on this issue. Most of my friends at Microsoft are honest enough to admit that the point
