On Dec 17, 2003, at 10:48 PM, Mark Crispin wrote:
STATUS is not necessary, and can involve excessive costs. These costs
have nothing to do with new mail. The costs are in STATUS data which,
for
the limited purpose of new mail notification, are frills!
Well, many clients don't really want to kno
On Wed, 17 Dec 2003, Christof Drescher wrote:
> I'd be interested to see your argument for MESSAGES, because I assumed
> some coherence between MESSAGES and EXISTS, which is used to announce
> new mail in selected mailboxes. Or am I off the track again?
The problem is that prior state is implied.
Now we get to a point I fully comply with you :-)
> > Needed: Notification of new mail arrival in unselected mailboxes
>
> Good definition.
>
> Since you only need notification of new mail arrival in unselected
> mailboxes, then the solution should be tightly focused on accomplishing
> that goal.
--On 2003-12-17 12:57 PM -0800 Larry Osterman
<[EMAIL PROTECTED]> wrote:
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.
Not a chance. It means one (or a very few) threaded processes are
giving select
On Wed, 17 Dec 2003, Christof Drescher wrote:
> Just to make it totally clear to me: A message can be removed from the
> session-state list of \Recent messages ONLY by expunge?
Correct.
> Or the other way round: A server MUST NOT change the \Recent flag for a
> single message at any time until a
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 Gulbrandse
On Wed, 17 Dec 2003, Christof Drescher wrote:
> So what? A server for which it is "expensive" to do this status update -
> don't advertise it in your CAPABILITY and you need not bother coding it.
> Right? Even if you advertise it and for a certain folder it is to expensive,
> give a NO response. Yo
Hi,
thank you Mark for your answers.
I think I see now your points and I think I have what I need to code a
"compliant" server which matches the intended behavior.
Please allow my last comment before I shut up. :)
> > c)
> > Is it correct that a server can at any time issue a * 0 RECENT untagged
Hi,
in the best tradion of what is to be in the core specs and what should be an
extention, please consider this:
> > One addition would then be the part of an "extension": A command to
supply a
> > list of folders which it wants to receive untagged STATUS updates about.
> >
> > Wouldn't that be a
On Wed, 17 Dec 2003, Christof Drescher wrote:
> Is a server broken in any way if it sends untagged STATUS updates at its
> desire?
No.
> b)
> Which of these cases can happen if a Recent message arrives, if more than
> one session has a mailbox selected:
> - none gets a RECENT update
> - only one
On Wed, 17 Dec 2003, Christof Drescher wrote:
> One addition would then be the part of an "extension": A command to supply a
> list of folders which it wants to receive untagged STATUS updates about.
>
> Wouldn't that be a really simple solution? Conforming? Rather easy to
> implement on both clien
On Wed, 17 Dec 2003, Christof Drescher wrote:
> I think I don't confuse anything about this issue. We were talking about the
> pro and cons of Mark's idea of RECENT update, and came about his example,
> which I questioned. I did not question IMAP specs or anything, and I did not
> bring up the issu
Answering my own posting may make me look strange, but anyway...
One addition would then be the part of an "extension": A command to supply a
list of folders which it wants to receive untagged STATUS updates about.
Wouldn't that be a really simple solution? Conforming? Rather easy to
implement on
Hi,
now to make something out of the discussion, I'd like to drop a few
questions. Maybe you can shed some light on it and make me happy. :)
a)
Is a server broken in any way if it sends untagged STATUS updates at its
desire?
b)
Which of these cases can happen if a Recent message arrives, if more
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
Wow wow wow...now hold a second...
> > a) What "professional" mail server system today relies on any CLIENT
> > checking for spam/viruses?
>
> An IMAP server could not care less what a client does, as long as the
> client doesn't violate the IMAP protocol specification. I think you are
> confusing
--On 2003-12-17 9:09 PM +0200 Timo Sirainen <[EMAIL PROTECTED]> wrote:
Then again, if any of the clients crash or their connection hangs for
some reason, no-one handles those \recent messages.
One process is designated to perform periodic cleanup, part of which is
looking for messages that didn't
On Dec 17, 2003, at 8:05 PM, Lyndon Nerenberg wrote:
Consider a trouble ticketing system that uses an IMAP mailbox as an
input queue for requests. Requests are delivered into the mailbox. On
the other side, n (n > 1) processes retrieve requests from the mailbox
for processing. These processes u
--On 2003-12-17 10:30 AM +0100 Christof Drescher
<[EMAIL PROTECTED]> wrote:
a) What "professional" mail server system today relies on any CLIENT
checking for spam/viruses?
An IMAP server could not care less what a client does, as long as the
client doesn't violate the IMAP protocol specification
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
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.
M
On Wed, 17 Dec 2003, Arnt Gulbrandsen wrote:
> Christof Drescher writes:
> > Anyway: Do you argue such an extension would not be wise to have?
> There have been a great many attempts at this, all failed. I do not feel
> competent to judge why they failed, and how it can successfully be done.
I can
Hi,
adding to Richard's mail...
>There must be a way to notify which messages are recent in a logical
>manner that can be applied to all clients.
>
>This leads me to another question: If the behaviour for multiple
>connections is undefined, why cannot they all see the recent flag being
>set?
This
Timo Sirainen wrote:
>I'm not sure if this really needs to be an extension. Rather server
>could just send untagged STATUS updates to client whenever it feels
>like it. Only problem is that most clients seem to ignore it if they
>didn't request it themselves.
You are so right! Thank you!
I really
> Any server which does not implement \Recent flags is broken. The only
> acceptable excuse for not implementing \Recent is a legacy mail store
> which makes doing so impossible. Even then, it is clear that
> such servers
> are dysfunctional.
If the server implements it but you never see it beca
On Wed, 17 Dec 2003, Christof Drescher wrote:
> a) What "professional" mail server system today relies on any CLIENT
> checking for spam/viruses? Even if so, how on earth can one assume that ALL
> clients connecting do the proper virus checking.
There are multiple levels of spam and virus checking
On Dec 17, 2003, at 1:38 PM, Christof Drescher wrote:
Anyway: Do you argue such an extension would not be wise to have?
20 TCP connections might be cheap for CPU and memory, but it also means
more network traffic which might not be nice if your bandwidth costs
per kilobyte (mobile phones).
I'm
On Wed, 17 Dec 2003, Philip Guenther wrote:
> Wow. An internal session---perhaps real, perhaps nominal---open to each
> mailbox, *just* to avoid having to implement part of the protocol that
> you don't like. There are other bits in the RFC that I found tough to
> get right; you're telling me now
Christof Drescher writes:
Anyway: Do you argue such an extension would not be wise to have?
I'm not sure. It would be a good feature, but is appropriate as an IMAP
extension, or should it be a separate protocol, perhaps using UDP?
There have been a great many attempts at this, all failed. I do no
Hi,
it's not really the point to argue about it, but I code for quite some time
now and - forgive me - sometimes think with the eyes of a "small system"
where RAM is valuable and unnecessary demands at least SHOULD be avoided.
And I like to enhance the software solution rather than putting more
ha
"Richard Bang" <[EMAIL PROTECTED]> writes:
...
>According to the RFC this is compliant and all clients must be able to
>work correctly in this scenario as they can never quarantine that they
>will EVER see the flags.
Wow. An internal session---perhaps real, perhaps nominal---open to each
mailbox,
Christof Drescher writes:
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. B
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 muc
--On Mittwoch, 17. Dezember 2003 11:01 Uhr +0100 Simon Josefsson
<[EMAIL PROTECTED]> wrote:
"Christof Drescher" <[EMAIL PROTECTED]> writes:
Maybe Mark can explain what PINE does about it, and other client
implementors about their programs respectively?
Gnus visually mark \Recent articles with "N
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
Hi,
>> Is there any "simple" way for a client to get notified if a non-selected
>> mailbox has newly arrived mail?
>It seems that you want to poll this mailbox.
Not "poll" in the closer sense, I want an information pushed at new arrival.
>> Possibly best would be an update sent
>> without request
Christof Drescher wrote :
> Is there any "simple" way for a client to get notified if a non-selected
> mailbox has newly arrived mail?
It seems that you want to poll this mailbox.
> Possibly best would be an update sent
> without request, a real notification then (e.g. as a response to a NOOP
>
No doubt Mark will give me some flack for this but I decided never to
send the recent flag to any connected client.
And this is why.
I created a daemon client that is connected to all mailboxes on a
permanent basis, as it was always first in the connection queue, it
always saw the recent flag fir
"Christof Drescher" <[EMAIL PROTECTED]> writes:
> Maybe Mark can explain what PINE does about it, and other client
> implementors about their programs respectively?
Gnus visually mark \Recent articles with "N". However, since for many
typical environments \Recent is, according to the specificati
Hi,
thinking about the /Recent problems and reviewing Timo Sirainens mail as of
03 Aug, I came about the following question:
Is there any "simple" way for a client to get notified if a non-selected
mailbox has newly arrived mail? Possibly best would be an update sent
without request, a real notifi
Hi Timo,
>\Recent flags are useful to quickly notice what messages are really
>new, ie. user has never seen them (I often leave some messages unread).
>For example client could show recent messages with bold font. Of
>course, with RFC-specified \Recent behaviour this breaks badly with
>multiple se
Hi Mark,
now this sounds odd. There are (at least) two points against it:
a) What "professional" mail server system today relies on any CLIENT
checking for spam/viruses? Even if so, how on earth can one assume that ALL
clients connecting do the proper virus checking. And even so, would it not
be
42 matches
Mail list logo
