t.
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).
L
DITY 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
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
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, Augu
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 PROT
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
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
18, 2004 2:18 PM
To: [EMAIL PROTECTED]
Subject: Re: shared mailbox permanent flags?
Hi Larry,
On Aug 18, 2004, at 23:08, Larry Osterman wrote:
> 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 i
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, 20
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 di
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
ags means. The
server's telling you that you can change the flags but they won't have
changed the next time you connect. You don't have control over this
behavior.
Larry Osterman
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Stuart Nic
ags 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:[E
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]
Subjec
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.
Larry Osterman
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PRO
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] [mai
vers greater than NT 3.51 support NTLMV2).
Larry Osterman
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Andreas Aardal Hanssen
Sent: Monday, April 05, 2004 4:46 AM
To: IMAP protocol mailing list
Subject: Re: IMAP & SPA
On Mon, 5 Apr 2004, Alexey
ed 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
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 PROTE
I'm speaking for Barry, but as I remember, the logic behind allowing
IDLE in the authenticated state is that in the future a server might
have legitimate information to send to the client when in the
authenticated state.
Currently there's no such info that can happen but...
> -Original Messag
Title: Re: Assumption of hierarchy?
I'll be honest and say that I
haven't checked. And since I'm working from home today (it's a snow day) I
can't check right now.
From: Arnt Gulbrandsen
[mailto:[EMAIL PROTECTED]Sent: Tue 1/6/2004 9:23
AMTo: Mark CrispinCc
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 PRO
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]
> Subj
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 o
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
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 abilit
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:
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
ystem.
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
---
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-o
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: [
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
(\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
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 PROT
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] [m
\" ""
S: OK LIST completed
Then mozilla is doing the right thing, and your other responses are
incorrect.
Larry Osterman
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Slavo Uhrin
Sent: Wednesday, November 19, 2003 2:00 PM
To: [EMAIL
tuff 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 b
I just received the attached bounce message from the mail I
sent.
I don’t know who generated it, but it may possibly be
the WORST bounce message I’ve ever seen.
Here’s the headers as received by our email system:
Microsoft Mail Internet Headers Version 2.0
Received: from df-s
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
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 \N
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
xpunge
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
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
My take is that this is a bug of Mozilla - \NoSelect means exactly what
it says - the mailbox has no inferiors.
Larry Osterman
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Andreas Aardal Hanssen
Sent: Wednesday, September 10, 2003 2:05 PM
To: IMAP
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
Eric A. Hall [mailto:[EMAIL PROTECTED]
> Sent: Friday, August 15, 2003 9:45 AM
> To: Larry Osterman
> Cc: Arnt Gulbrandsen; Pete Maclean; IMAP protocol mailing list
> Subject: Re: IMAP not good enough?
>
>
>
> on 8/15/2003 11:12 AM Larry Osterman wrote:
>
&g
ndard". 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
n [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
> > propr
> 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 to
x27;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 PR
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 [
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
7;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 z
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.
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,
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
>
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 rel
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
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 s
#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
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 Exchang
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
&g
s 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
Grr.. Wrote this and then realized you said \Unseen, not \Recent. Blah.
My point is still valid and relevant, just different.
Larry Osterman
>
> -Original Message-
> From: Larry Osterman
> Sent: Wednesday, March 19, 2003 11:41 AM
> To: 'John Milan
rating 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 "* EXPUNGE/* 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
et been sent), when the client saves
their changes on the message, the server assigns a new UID to the
message and sends an expunge for the old message.
Larry Osterman
Please
see RFC2821 and RFC2822 for more information on how to send email using the
internet infrastructure.
Larry
Osterman
From: rajib basue
[mailto:[EMAIL PROTECTED] Sent: Friday, March 07, 2003 5:41
AMTo: [EMAIL PROTECTED]
Sir,
I would like to know is it
;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:
&
hments or not - the server
will almost always get it wrong.
Consider the above as empirical evidence that the user experience
associated with a server's automatically "has attachment" algorithm is
almost always poor.
Larry Osterman
And obviously I'm speaking for myself.
&g
>
> Outlook and OE for example don't want BODY, BODYSTRUCTURE or ENVELOPE.
> Caching any of them for these clients is just waste of disk
> space and disk I/O.
Don't use Outlook/OE as examples. They're really POP3 clients on
steroids as opposed to being "real" IMAP clients.
Larry Osterman
Out of curiosity, what are those issues? Is yEnc already encumbered
with the same legacy interoperability issues that prevented uuencode
from being standardized?
Larry Osterman
>
> -Original Message-
> From: Eric A. Hall [mailto:[EMAIL PROTECTED]
> Sent: Saturday,
ey 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
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
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
> -Origin
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-
>
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
>
ter - 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?
Larry Osterman
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Wednesd
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 fi
Is there a practical difference between the two statements? If
"subscribed" is an aspect of the folder and the folder gets
deleted....
Larry Osterman
-Original Message-
From: Timo Sirainen [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 28, 2003 1:04 PM
To: Larry O
thing we got burned on in Exchange :)
Funny how that is.
Larry Osterman
-Original Message-
From: Barry Leiba [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 28, 2003 12:39 PM
To: IMAP Mailing List
Subject: Re: RENAME, once more
> Another problem came to my mind though:
Ok, when I wrote that I hadn't realized the NAT limitations. Ignore my
comment :)
Larry Osterman
-Original Message-
From: Larry Osterman [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 28, 2003 9:45 AM
To: Mark Crispin; Timo Sirainen
Cc: [EMAIL PROTECTED]
Subject: RE: speaki
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
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
y 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 2
for), but
the server is REQUIRED to respect flag changes by the client (I don't
have the reference, but it's there (it bit us in the Exchange server
when we used clients against read-only mailboxes)).
Larry Osterman
-Original Message-
From: Rick Block [mailto:[EMAIL PROTE
documents,
specifically the MIME documents [RFC2045, RFC2046, RFC2048, RFC2049]
that extend this standard to allow for different sorts of message
bodies. Again, these mechanisms are beyond the scope of this
document.
Larry Osterman
-Original Message-
From: Mark Crispin [mai
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, 20
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 [mail
ivial to get the users password.
In the localhost case, while there might well be local exploits, you
still need to get the users password to be able to connect to their mail
store so local access per-se isn't the security hole.
Larry Osterman
-Original Message-
From: Matti Aarn
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
Arnt, I'm not trying to be confrontative (really, I'm not), but I'm
wondering if this is starting to devolve into a djb-style "should your
SMTP client send quit before closing the connection" argument?
I'm starting to have a serious case of deja-vu
Larry Oste
cally fail.
Larry Osterman
-Original Message-
From: Arnt Gulbrandsen [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 09, 2002 8:53 AM
To: [EMAIL PROTECTED]
Subject: Re: to logout or not...
DINH Viet Hoa <[EMAIL PROTECTED]>
> > I find this a tough question to answer.
ces of opinion occur.
Larry Osterman
-Original Message-
From: Vladimir A. Butenko [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 26, 2002 11:55 AM
To: Larry Osterman; Larry Osterman; Mark Crispin
Cc: [EMAIL PROTECTED]
Subject: Re: Empty mailbox & Fetch. Was: possible draft
ossible protocol violations in the section that defines
"BAD", instead it is more appropriate to call out specific violations
throughout the specification (which is exactly what the IMAP spec does).
Larry Osterman
-Original Message-
From: Vladimir A. Butenko [mailto:[
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
ow 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 t
escribe 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 Cr
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
returned:
S: 1 OK RFC822.BODY {xx}
Please note that I have NOT tested this on an Exchange server, I don't
know exactly what it would do, but it may be an issue.
Larry Osterman
-Original Message-
From: Mark Crispin [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 25, 20
Absolutely not. Messages in IMAP are immutable.
Larry Osterman
-Original Message-
From: Arnt Gulbrandsen [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 25, 2002 1:44 AM
To: IMAP Interest List
Subject: Re: possible draft 19 changes for sequence
Mark Crispin <[EM
1 - 100 of 129 matches
Mail list logo
