I wrote:
> UIDVALIDITY typically does not change very often, although the
> server is allowed to change it at any time.
More precisely, it can't change during a session, but two different
sessions can get different UIDVALIDITY values, no matter how close
together they are.
paul
Michael Wener <[EMAIL PROTECTED]> wrote:
> Does the server keep a per-session mapping between messages and
> UIDs?
No, that mapping is per-UIDVALIDITY. UIDVALIDITY typically does not
change very often, although the server is allowed to change it at any
time.
paul
Michael Wener <[EMAIL PROTECTED]> wrote:
> Is it fair to say that once a UID is visible within a session it is
> shared state?
The UID has the same meaning for all sessions that have the same
UIDVALIDITY and that have been notified about the message. The same
is *not* true for message sequence nu
Michael Wener <[EMAIL PROTECTED]> wrote:
> My consideration at the moment is only coordinated sessions. Sessions
> that are aware of each others logic and are behaving in concert.
The server has no way of knowing whether two sessions are coordinated
on the client side. It has to treat each sessio
David Woodhouse <[EMAIL PROTECTED]> wrote:
> You can have multiple PTR records for the same IP address, pointing to
> each of those hostnames.
You can, but many programs won't know what to do with multiple PTRs.
They may use only the first record they see.
paul
"David Truckenmiller" <[EMAIL PROTECTED]> wrote:
> I ask, because if I save a mime message to the disk, then read it into
> the MimeMessage class, the size on the disk is different than the size
> reported by getSize(). I'm just wondering if this is expected.
The size assreported in RFC822.SIZE s
Andreas Aardal Hanssen <[EMAIL PROTECTED]> wrote:
> It looks like a good solution, but it has a flaw; mining for the existance
> of email addresses is done with a simple DNS lookup.
A wildcard record would take care of that. Or, to make it less
detectable, lots of individual records, aliasing dif
Mark Crispin <[EMAIL PROTECTED]> wrote:
> RFC 3501, section 6.4.5, page 54:
>Most data items, identified in the formal syntax under the
>msg-att-static rule, are static and MUST NOT change for any
>particular message. Other data items, identified in the formal
>synt
Philip Guenther <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Paul Jarc) writes:
>> I haven't been able to find any such promise in RFC3501.
>
> Message sequence numbers, as described in section 2.3.1.2, and the
> implied mapping between them and UIDs are clearly
Mark Crispin <[EMAIL PROTECTED]> wrote:
> On Wed, 24 Mar 2004, Paul Jarc wrote:
>> If the client deletes a message it wasn't able to download, then that
>> sounds like a buggy client.
>
> Why?
Um... lossage? If the client shows the user that "there is some
me
Mark Crispin <[EMAIL PROTECTED]> wrote:
> IMAP does not promise any sort of state in LIST. It does with
> SELECT.
I haven't been able to find any such promise in RFC3501. You could do
a lot to win me over by pointing me to it, or by saying something like
"This was an oversight; it is knowledge t
Philip Guenther <[EMAIL PROTECTED]> wrote:
> the experience of seeing this same argument about EXPUNGE and FETCH
> repeat over and over with no new points
I saw the thread last time around - I didn't respond then, because I
was reading it late. I think I have raised *some* new points; has the
pos
Timo Sirainen <[EMAIL PROTECTED]> wrote:
> Most IMAP clients will popup some error message
That makes sense. The user asked for something, but it couldn't be
done, so they get notified.
> and maybe fail even more badly
Clients must deal with their own bugs.
> With NILs user would temporarily s
Mark Crispin <[EMAIL PROTECTED]> wrote:
> The message shouldn't go away until that EXPUNGE [response] has
> happened.
So does this mean the EXPUNGE response should also be withheld from
the client that sent the EXPUNGE command, since the message has not
yet really been removed?
> If you read RFC
Mark Crispin <[EMAIL PROTECTED]> wrote:
> On Wed, 24 Mar 2004, Paul Jarc wrote:
>> Can you give a concrete example? I'm having a hard time imagining how
>> this could happen.
>
> Download-and-delete. A single message couldn't be accessed because of a
&
Pawel Salek <[EMAIL PROTECTED]> wrote:
> I have impression two distinct issues are mixed here:
Yes, good point.
> a. critical server errors (ENOMEM, etc)
...
> I would insist that the server should try _hard_ to avoid reporting NO
> on a-type condition. It is the server's task to handle these iss
Mark Crispin <[EMAIL PROTECTED]> wrote:
> If the message is "no longer available" the server should have sent an
> untagged expunge.
Of course - if it has had a chance. If it hasn't (i.e., when there
hasn't been any intermediate command that allows the EXPUNGE
response), then what? This is the s
Mark Crispin <[EMAIL PROTECTED]> wrote:
> IMAP is *read-write*. Writes based upon damaged reads are -- by
> definition -- creation of new damage.
Can you give a concrete example? I'm having a hard time imagining how
this could happen.
>> Further clobbering an already clobbered file would be bad
Pawel Salek <[EMAIL PROTECTED]> wrote:
> Server that answers NO follows the specification but is useless.
If the message is, in fact, no longer available by the time FETCH
arrives, then I would instead call it "honest".
> "Server says that message number xx exists but when I ask for it, it
> says
Mark Crispin <[EMAIL PROTECTED]> wrote:
> It is not necessary to cater to cretins.
>
> It is, however, necessary to avoid giving them wiggle room where they
> can point to the specification and claim that they are right and
> everybody else is wrong.
Ok. AFAICS, then, there is no wiggle room - NO
Mark Crispin <[EMAIL PROTECTED]> wrote:
> On Tue, 23 Mar 2004, Paul Jarc wrote:
>> Wouldn't it be reasonable to say "the server can give a NO response
>> in these conditions, but still must support these features"?
>
> Decades of unfortunate exper
Timo Sirainen <[EMAIL PROTECTED]> wrote:
> "Message being deleted" case was just discussed in January (Subject:
> Multiple command clarification). Issuing NO isn't a very good idea,
> rather use NIL if you don't know the data.
Why should deletion be handled differently from any other error, like
E
Mark Crispin <[EMAIL PROTECTED]> wrote:
> If a server could send an tagged NO to a FETCH, then there would be
> no need for a serverto implement ENVELOPE, BODYSTRUCTURE, etc. --
> just send a tagged NO and force the client to FETCH RFC822 and parse
> the message itself.
I don't see why you would t
Arnt Gulbrandsen <[EMAIL PROTECTED]> wrote:
> A tagged NO means something went wrong with the execution of that
> command.
Ok, that's what I thought.
> a) tagged NO relates to the command; untagged BYE ALERT relates only
> to general server state
> b) NO means the server can go on; BYE ALERT mean
Mark Crispin <[EMAIL PROTECTED]> wrote:
> On Tue, 23 Mar 2004, Paul Jarc wrote:
>> Note that "can't access mailbox" is mentioned distinctly from "no such
>> mailbox".
>
> You're reading too much into that. "Can't access mailbox
Arnt Gulbrandsen <[EMAIL PROTECTED]> wrote:
> A tagged NO means something is wrong with that command.
What you're describing sounds more like BAD. RFC3501, 2.2.2:
# There are three possible server completion responses: OK (indicating
# success), NO (indicating failure), or BAD (indicating a proto
Arnt Gulbrandsen <[EMAIL PROTECTED]> wrote:
> Paul Jarc writes:
>> Even for errors that won't go away on their own? ISTM reporting the
>> error will make it more likely to get fixed.
>
> Report it to the sysadmin? If so, use something like syslog() with as
> much
Mark Crispin <[EMAIL PROTECTED]> wrote:
> On Tue, 23 Mar 2004, Paul Jarc wrote:
>> Mark Crispin <[EMAIL PROTECTED]> wrote:
>>> Untagged "* BYE Horrible Error #69, contact your sysadmin"
>> How does this improve upon tagged NO? Will clients report th
Mark Crispin <[EMAIL PROTECTED]> wrote:
> On Tue, 23 Mar 2004, Paul Jarc wrote:
>> But then what should the server do in the case of an error like
>> EACCES, ENOMEM, ENFILE, EMFILE?
>
> Untagged "* BYE Horrible Error #69, contact your sysadmin"
How does this
Arnt Gulbrandsen <[EMAIL PROTECTED]> wrote:
> Paul Jarc writes:
>> But then what should the server do in the case of an error like
>> EACCES, ENOMEM, ENFILE, EMFILE?
>
> untagged BYE followed by a connection close?
Even for errors that won't go away on their own
Mark Crispin <[EMAIL PROTECTED]> wrote:
> I don't think that you should ever issue a tagged NO in response to a
> FETCH.
But then what should the server do in the case of an error like
EACCES, ENOMEM, ENFILE, EMFILE?
paul
[Old thread.]
"David Harris" <[EMAIL PROTECTED]> wrote:
> In fact, if I use '%' wildcards to retrieve folder lists, I can't
> see any way at all of ever getting to the "Public folders/" tree -
> I've tried passing "Public folders" and "Public folders/" as a
> reference, but Exchange simply returns
Is there any IMAP extension which would let the client ask the server
for an email address corresponding to a particular mailbox?
One case where this would be useful: a mailbox holds the messages of a
mailing list, but of course APPENDing to the mailbox will not
distribute the message to all subsc
Lastly (I hope), exactly which content-types must a server delve into?
multipart/mixed, multipart/alternative, message/rfc822, ...
message/delivery-status? multipart/digest? Others?
paul
Mark Crispin <[EMAIL PROTECTED]> wrote:
> x.MIME is only meaningful for parts of a multipart message and never
> refers to HEADER part.
Ok. Cyrus seems to allow it, but I guess that won't hurt any correct
clients.
paul
Mark Crispin <[EMAIL PROTECTED]> wrote:
> That is, there is a multipart message, encapsulated within a single part
> message, encapsulated within a single part message.
Right. I thought that's what I was saying.
> [] entire [EMAIL PROTECTED]
> [HEADER] header of [EMAIL PROTECTED]
> [TEXT] tex
Mark Crispin <[EMAIL PROTECTED]> wrote:
> On Tue, 27 Jan 2004, Paul Jarc wrote:
>> That server agrees with what Mark says ([1.1.HEADER] is the header of
>> the multipart/mixed message), but it seems to disagree with the
>> example in RFC3501. In my test message:
>&
I wrote:
> Consider a top-level message/rfc822, which contains a message/rfc822
> part, which contains a multipart/mixed part, which contains a
> text/plain part.
I just checked the public Cyrus test server at cyrus.andrew.cmu.edu
with such a message. (Well, the multipart part contained two
text/
Mark Crispin <[EMAIL PROTECTED]> wrote:
> On Thu, 15 Jan 2004, Paul Jarc wrote:
>> If the encapsulated message itself is also message/rfc822, then
>> [1.TEXT] is the header and body of the doubly-encapsulated message,
>> and there is no way to refer to the header and b
Mark Crispin <[EMAIL PROTECTED]> wrote:
> On Thu, 15 Jan 2004, Paul Jarc wrote:
>> Please confirm my understanding here. In a text/plain message,
>> BODY[TEXT] and BODY[1.TEXT] refer to the same data (the message body),
>> and BODY[] and BODY[1] refer to the same data (
Please confirm my understanding here. In a text/plain message,
BODY[TEXT] and BODY[1.TEXT] refer to the same data (the message body),
and BODY[] and BODY[1] refer to the same data (the full message,
header and body). But in a multipart/* message which contains a
message/rfc822 part as its only pa
"Christof Drescher" <[EMAIL PROTECTED]> wrote:
> 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?
Right.
> Since no client can tell the server that it DOES a recv()
> by any means, it must assume that the
Mark Crispin <[EMAIL PROTECTED]> wrote:
> On Tue, 30 Dec 2003, Paul Jarc wrote:
>> How about this: CAPABILITY IMAP4rev1 AUTH=ANONYMOUS LOGINDISABLED
>> Would clients be prepared for that?
>
> That capability string is fine for an anonymous-only server. My client
>
Mark Crispin <[EMAIL PROTECTED]> wrote:
> On Tue, 30 Dec 2003, Paul Jarc wrote:
>> I thought I had also read somewhere explicitly that [READ-ONLY] was
>> specifically useful in greetings, but I can't find that text now.
>
> I don't recall ever writing such text
Mark Crispin <[EMAIL PROTECTED]> wrote:
> READ-ONLY appears in a tagged OK response to a SELECT or EXAMINE command.
I had thought I saw somewhere that it could also occur in a greeting.
If that's not the case, I'll send CAPABILITY data instead.
>> Do you think it would be more useful to have \See
Arnt Gulbrandsen <[EMAIL PROTECTED]> wrote:
> Paul Jarc writes:
>> For the SELECT command, what should a server do for OK [UNSEEN n]
>> when there are no unseen messages? Omit that part of the response?
>
> Yes. If you look at the RFC 3501 formal grammar, you will see t
Mark Crispin <[EMAIL PROTECTED]> wrote:
> If there are no unseen messages, then the [UNSEEN ] response would be
> omitted.
Ok.
> Generally, you would only include capability information at a greeting
> response (initial untagged OK response) or in the tagged OK response for a
> LOGIN or AUTHENTIC
[Old thread. I'm writing a read-only, anonymous-only server for
publishing list archives, etc.]
For the SELECT command, what should a server do for OK [UNSEEN n] when
there are no unseen messages? Omit that part of the response?
Right now, my greeting looks like "* OK [READ-ONLY] ...". How sho
I'm writing an entirely read-only IMAP server; it's mainly intended
for serving mailing list archives. Just like a web archive, it lets
anyone in (PREAUTH greeting), but maintains no per-user persistent
state. So - how should I handle flags? My PERMANENTFLAGS set will be
empty. \Answered, \Dele
49 matches
Mail list logo
