What you are doing with RFC 2047 encoding looks correct for the most part.
I think that your problem with Mulberry is that (the last I heard) it does
not support East Asian characters at all.
I said for the most part because you can't use RFC 2047 for the NAME=
parameter. You must use RFC
On Thu, 19 Aug 2004, petite_abeille wrote:
(1) Envelope and bodystructure responses are always US-ASCII. Correct?
IMAP responses are always ASCII, unless charset tagged in some way.
(2) Envelope's env-subject is RFC 2047 encoded if necessary. Correct?
(3) Envelope's addr-name is RFC 2047 encoded
On Thu, 19 Aug 2004, petite_abeille wrote:
IMAP responses are always ASCII, unless charset tagged in some way.
Ok. Is it possible to tag a charset for envelope and bodystructure
responses?
That's what RFC 2047, etc. do.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from
On Wed, 18 Aug 2004, petite_abeille wrote:
Oh, well... I guess I will stick to my current methodology then:
... dont read specs until someone yells...
Not a good idea. The IMAP protocol is very rigid, and does not permit
deviation. Failure to read the IMAP specification closely prior to
On Wed, 18 Aug 2004, petite_abeille wrote:
Ok. So FLAGS should always returns \Answered \Deleted \Draft \Flagged \Recent
and \Seen? Even if they are not applicable for such mailbox?
Yes, and those flags are *always* applicable (even if they are
session-only) by definition.
Consider the effect
On Thu, 5 Aug 2004, petite_abeille wrote:
I'm in the process of testing a little embedded IMAP server which is part of
a P2P messaging system and... I was wandering if there is an official
conformance test suite anywhere which could assist me with uncovering any
protocol related glitches in a
On Mon, 12 Jul 2004, Pete Maclean wrote:
That, in my view, is not the real problem though. As a server developer
myself, I am inclined to be extremely forgiving of server bugs.
You shouldn't be. Server bugs are unforgivable. Any forgiveness should
be granted to clients.
Now, this is not
On Mon, 12 Jul 2004, Sebastian Hagedorn wrote:
Maybe they meant RFC 1730?
RFC 1730 didn't have partial syntax; it had a poorly-considered definition
of partial fetching which was revoked and replaced in RFC 2060.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting,
On Fri, 9 Jul 2004, Lyndon Nerenberg wrote:
This seems wrong to me. IMAP servers are tied to people, not hosts. If I
visit your site, I want don't want my IMAP client to suddenly try to connect
to your site's IMAP servers.
I agree, and given unfortunate history it's pretty clear that some
Every IMAP list message contains the proper unsubscribe instructions in
the message header: the List-Help, List-Subscribe, List-Unsubscribe,
List-Owner, and List-Post header lines. Please use these instructions.
Please do not send unsubscribe messages to the mailing list, nor to me
On Thu, 8 Jul 2004 [EMAIL PROTECTED] wrote:
That would then make me assume that though our IMAP server appears to be
working it must be silently working incorrectly, because we are accessing
IMAP's data store from NFS. What symptoms would I experience when a flock()
lock erroneously succeeds?
If
On Thu, 8 Jul 2004 [EMAIL PROTECTED] wrote:
I may be revealing my ignorance again, but I think we were using
qpopper before we even decided to use IMAP at all, that had problems over
NFS because it locks, makes a copy and if you are saving messages on the
server copies it back. All that happening
On Thu, 8 Jul 2004 [EMAIL PROTECTED] wrote:
So if we were to insist on remote storage we would have to modify IMAP
server source to do fcntrl instead of flocks where necessary and it still
wouldn't work because lock files can't be counted on.
More importantly, you MUST use .lock files with NFS in
On Thu, 8 Jul 2004, Timo Sirainen wrote:
Doesn't that mean that a user is located only in a single server, so in
case it breaks, the user can't read mail until admin has fixed the
problem by restoring mails from backups and moved the accounts to new
server?
As opposed to having all users located
On Fri, 9 Jul 2004, Timo Sirainen wrote:
I didn't say anything about NFS. Filesystems clustered over multiple
separate computers providing automatic failover if a few of the
computers die are more interesting. Of course that assumes that they
work correctly - I don't have personal experience with
On Wed, 7 Jul 2004 [EMAIL PROTECTED] wrote:
I've been doing some research on file locking for mail systems and have
noticed in several places mention made to IMAP [Not needing file
locking].
Any place that says such a thing is uninformed (at best).
Although the IMAP protocol itself has no
On Fri, 2 Jul 2004, Ole wrote:
Using debian with sendmail+squrrilmail+(imap)
I have installed imap-2004 with the command make slx, because i want
to user the passwords in /ets/shadow so i guess this is the right make
option.
make ldb is more likely to be correct, since Debian has different
What you're proposing is a concept called notifications. This has
proven to be something in which people spend a lot talking about and very
little time actually doing. Currently, there's some talk about
notifications in the Lemonade working group.
I wrote a prototype implementation of a
On Sun, 13 Jun 2004, Imap List wrote:
Is there a generally accepted technique to advise (or force) a client to
requery the folder list? We currently send an [ALERT], but that's less
than optimal.
Unfortunately, no.
Would it make sense to send a bunch of unilateral, untagged LIST
responses [ *
A reference name of is not the same as a reference name of . Also,
to avoid possible ambiguity, it is better that non-empty reference names
terminate with the hierarchy delimiter, e.g.
tag LIST Specials\\ Read
rather than
tag LIST Specials Read
Consider the following command:
tag LIST
On Thu, 27 May 2004, Pete Maclean wrote:
One element seems wrong but I am not 100%
certain. This server (which I cannot identify since it has not been
identified to me) claims IMAP4Rev1 compliance by virtue of its initial
response (* OK IMAP4rev1 Service Ready).
IMAP4rev1 compliance is
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
On Mon, 10 May 2004, Ashish Srivastava wrote:
// -- myHomeDir = cpystr (home);
sprintf (tmp, %s/mail, home);
myHomeDir = cpystr (tmp);
and in sysInbox :
// -- sprintf(tmp, %s/%s, MAILSPOOL, myusername());
sprintf (tmp, %s/mail/incoming, myhomedir());
sysInbox = cpystr (tmp);
These patches tell
This message is to announce the University of Washington IMAP toolkit,
version 2004.
imap-2004 is a major release. Programs written for the previous release
(imap-2002e) should build with this version with minor modification.
imap-2004 is available at:
On Thu, 6 May 2004, Tim Showalter wrote:
They're asking for a way for the server to kick the client into the
unselected state.
(Personally, given clients won't easily be able to test that, and it will be
hard to motivate client authors to enable such a thing, I suggest that such
functionality
On Tue, 4 May 2004, Mike Wener wrote:
What exactly is the definition of unsolicited?
There are two definitions.
One is any untagged response (that is, only tagged responses are
solicited).
The other is an untagged response which does not have any obvious
relationship to the command.
I prefer
On Tue, 4 May 2004, Arnt Gulbrandsen wrote:
With the exception of EXPUNGE, *ALL* untagged responses may be sent
unilaterally.
At risk of sounding like a broken record... I wish that weren't the case for
SEARCH.
Why? We may want to do that someday.
-- Mark --
http://staff.washington.edu/mrc
UW imapd can send an unsolicited UIDVALIDITY and UIDNEXT, but only if a
mailbox goes from empty (meaning ambiguous mailbox format) to non-empty
(meaning determinate format).
UW imapd does not have any path in which a non-empty selected mailbox can
change its UIDVALIDITY. It prohibits RENAME
On Tue, 4 May 2004, Mike Wener wrote:
How would this become clearly defined? Is it a matter of convention or
specification?
I think that it would have to be specified somewhere, either in a future
revision to the IMAP base specification (or more likely in an extension).
For example, I could
On Thu, 29 Apr 2004, Andreas Aardal Hanssen wrote:
A mailbox can be
subscribed to twice, which does not make any sense, whatsoever.
If an interpretation does not make sense, that should be a clue that there
is something wrong with the interpretation, and that an alternative
interpretation should
In the UW IMAP server, email access are the same as UNIX accounts.
On Solaris, you may have to update services in NIS as well as
/etc/services. You also may have to restart inetd and/or restart the
system before telnet localhost 143 works.
For more information about using and installing this
On Tue, 30 Mar 2004, Rick Block wrote:
Guessing that you're talking about a client development SDK of some
kind
He's using the c-client API in the UW IMAP toolkit. c-client has the
capability of converting arbitrary charset text to UTF-8, and of
converting UTF-8 into most charsets.
If
C and
On Fri, 26 Mar 2004, Arnt Gulbrandsen wrote:
I've been told that when Japanese newspapers print a Chinese person's name,
they use their regular Japanese font. Is that true?
Yes, it is true.
Why don't these newspapers have the same acceptance issue?
Because it isn't really an issue.
-- Mark --
On Fri, 26 Mar 2004, Mark Keasling wrote:
The basic problem is that Japanese, Chinese,
and Korean all use a large number of the same characters and when
Not same but similar. The unification effort took characters with both a
similar appearance and a similar meaning and lumped them together.
Ah,
On Thu, 25 Mar 2004, Pete Maclean wrote:
- what charsets are commonly used for email?
The ones that I see most commonly are: US-ASCII, UTF-8, ISO-8859-1,
ISO-8859-2, ISO-8859-15, KOI8-R, ISO-2022-JP, GB2312, BIG5, EUC-KR,
WINDOWS-1251. However, others do appear.
- can most clients handle
On Wed, 24 Mar 2004, Arnt Gulbrandsen wrote:
Some errors are caused by lack of global resources, and sometimes that lack
goes away. For example, if some big batch job is currently eating most of the
RAM, that batch job will finish and the RAM will become available for the IMAP
server. (The
On Wed, 24 Mar 2004, Pawel Salek wrote:
Ok. AFAICS, then, there is no wiggle room - NO is listed as a valid
response to FETCH, and any client that can't handle it is in
violation. Servers are entirely within their rights if they send NO,
though of course it's preferable to prevent the problem if
On Wed, 24 Mar 2004, Arnt Gulbrandsen wrote:
Until such time as that happens, I think authors of clients, servers and
peer are well advised to assume that their servers, clients and peers
may be buggy. To some degree.
Which is why, when a horrible error #69 happens, you stop everything
instead
On Wed, 24 Mar 2004, Paul Jarc wrote:
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.
No, the server is broken.
If the message is
On Wed, 24 Mar 2004, Paul Jarc 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.
Download-and-delete. A single message couldn't be accessed because
On Wed, 24 Mar 2004, Paul Jarc wrote:
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?
The situation should never come up.
The message shouldn't go away until that EXPUNGE has happened. There
On Wed, 24 Mar 2004, Paul Jarc 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?
Not at all. It took
On Wed, 24 Mar 2004, Paul Jarc wrote:
It appears your real disagreement is with the IMAP mailbox abstraction
with its guarantee that messages won't randomly disappear beneath a
client.
If there is indeed such a guarantee, then I have two problems with it:
it's too cumbersome, and it isn't clearly
On Tue, 23 Mar 2004, Paul Jarc wrote:
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?
Untagged * BYE Horrible Error #69, contact your
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 covers such
normal cases as protection failures.
It is not a mandate that all instances of horrible error #69 must be
On Tue, 23 Mar 2004, Perry Ruiter wrote:
Frankly, I was surprised when Mark said that FETCH should never
return a tagged NO and that the preferred approach was to dummy
up a note's structure when running into difficulty. I sure didn't
get that from reading the RFC.
The whole point of IMAP is
On Tue, 23 Mar 2004, Paul Jarc wrote:
Is it necessary to cater to the cretins? Can't we let them deal with
their own problems? It seems those who violated the standard are
being rewarded by requiring the rest of the world to accommodate them.
It is not necessary to cater to cretins.
It is,
On Tue, 23 Mar 2004, Perry Ruiter wrote:
* BYE on an error is the server saying I can't work with one of your
messages so I'm not going to let you work with any of them. I don't
find that a helpful approach to the end user. The client will probably
just reconnect and attempt to FETCH the
On Fri, 19 Mar 2004, Arnt Gulbrandsen wrote:
Perry Ruiter writes:
So the FETCH was unable to return anything. In this case do clients
typically revert to POP mode and just fetch the entire note and try and
deal with it themselves? Thanks ... Perry
I'd be utterly surprised if many IMAP clients
If you want the Content-Type information, you need to fetch the
BODYSTRUCTURE and not the .MIME parts. The .MIME parts only apply to
subparts of a multipart. There is no reason to expect that 1.MIME will
necessarily return anything interesting.
-- Mark --
http://staff.washington.edu/mrc
On Fri, 13 Feb 2004, Vlada Macek wrote:
I tried to prevent using of all other drivers by erasing envvars EXTRADRIVERS
and DEFAULTDRIVERS in the Makefile, this way also dummy was removed from the
linkage.c list. Also, I forced my new driver in the mail_valid() routine in the
mail.c.
Disabling
This is almost certainly a client-side issue. The fact that it happens
with qpopper as well as ipop3d indicates that the problem is independent
of the server implementation.
If you are running an anti-virus program with email scanning, it could be
interfering with the POP3 traffic.
Another
On Mon, 2 Feb 2004, Mark Harris wrote:
They are not having problems getting the messages or sending but when a
message is deleted it stays deleted but is never removed unless I goto the
server and remove it.
In IMAP, deleting a message simply marks that message for removal by a
subsequent
I agree with you that it's a bug in your C library's implementation of
getpwnam(), specifically in its NIS (a.k.a. Yellow Pages) routines (note
the yp_??? function calls).
The idea of those calls is to enable the #public and #shared namespaces if
the users imappublic and imapshared respectively
If imapd did not respond to a normal kill (SIGTERM) interrupt it is likely
that it was in so-called critical code, meaning that it was in the
middle of updating the mailbox. That isn't supposed to block.
It would therefore be very interesting to know what it was that that
process was doing, such
On Thu, 29 Jan 2004, Paul Jarc wrote:
Lastly (I hope), exactly which content-types must a server delve into?
multipart/mixed, multipart/alternative, message/rfc822, ...
message/delivery-status? multipart/digest? Others?
Did you read RFC 3501? The answer is to be found on page 55.
-- Mark
On Tue, 27 Jan 2004, Paul Jarc 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
You misrepresented the structure of the message; there is a layer of
encapsulation that you didn't mention. That's the cause of your
confusion.
The structure of that message is:
MESSAGE/RFC822 (message id [EMAIL PROTECTED])
1 MESSAGE/RFC822 (message id [EMAIL PROTECTED])
1.1 MESSAGE/RFC822
On Tue, 27 Jan 2004, Paul Jarc wrote:
Now if there is a text/plain message encapsulated in a message/rfc822
(single part) message, so that [1] is the same as [TEXT], then is
[1.MIME] the same as [HEADER]? Or is [x.MIME] only meaningful for
parts of a multipart message?
x.MIME is only
Everything is working correctly.
If you want a trusted certificate, you have to buy one. Self-signed
certificates are not trusted because anyone can create one.
On Mon, 26 Jan 2004, Terry Poperszky wrote:
I just upgrade a server to SuSE 9.0, which switched me to 2002d, which
requires SSL. In
On Fri, 16 Jan 2004, Andreas Aardal Hanssen wrote:
It's compliant with IMAP.
Indeed it is compliant, and it's necessary for the reasons that Andreas
and Timo gave. But there's another point.
Even if there was no reason for the server to have sent extra data, it is
*always* compliant for the
It looks like the PAM includes are not installed on your system. Look for
a Suse package that would install a PAM development environment.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
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 (the full message,
header and body).
No. In a text/plain message,
On Thu, 15 Jan 2004, Paul Jarc wrote:
Now, IIUC, if the top-level message is message/rfc822, then [TEXT] is
(the header and body of) the encapsulated message, [1] is the same,
and [1.HEADER] and [1.TEXT] are the encapsulated header and body
individually.
Yes.
If the encapsulated message
On Tue, 13 Jan 2004, David Woodhouse wrote:
H.. Can we then have a \Subscribed flag too?
That would require that all subscribed mailboxes exist.
Or is there another way of finding out which folders are subscribed
other than separately issuing LIST and LSUB commands?
No.
-- Mark --
On Sun, 11 Jan 2004, Michael Wener wrote:
I noticed that BODYSTRUCTURE on the uw imapd returns the actual
multipart boundary value. For exchange 2000 the value differs from what
is actually returned in BODY[].
If current versions of Exchange still do that behavior, it is broken.
IMAP was
On Fri, 9 Jan 2004, Tim Showalter wrote:
I tried to spend a few minutes thinking about this over the past couple days.
Mark's implementation is certainly more powerful, although I still find it
really odd. I can't get a good counter argument going.
Yes, it is odd, but it seems to be more
On Wed, 7 Jan 2004, Tim Showalter wrote:
I never thought about a.b c.d, but if I had, I would have made it do a.b.c.d,
not a.c.d. It might be worth fixing. I don't understand why a.c.d would be
desirable (doesn't a/b c/d = a/b/c/d on UW?).
a/b c/d = a/c/d in UW imapd.
This is based upon the
On Wed, 7 Jan 2004, Timo Sirainen wrote:
What about UW-IMAP's #news namespace? Does it have breakout characters?
No, it doesn't.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
On Wed, 7 Jan 2004, Ken Murchison wrote:
I'm willing to fix this, if we can decide which output is correct. Do we
insert a separator as Tim suggests, or backtrack to the first separator in the
reference as Mark suggests? I think I prefer Tim's idea.
Although Tim's idea seems more obvious,
On Wed, 7 Jan 2004, bj rui wrote:
how does mailutil generate its list of mailboxes? can it use
~user/.mailboxlist?
The .mailboxlist file is the list of subscribed mailboxes (sort of like a
bookmark file). It is not used by mailutil.
Most people put their mailboxes in a subdirectory of their
For what it's worth, UW imapd only lists the trailing hierarchy delimiter
form in two cases:
. the zero-character match case. In other words, if you list junk/* or
junk/% then junk/ will be included in the results
. hierarchy delimiter after the wildcard. In other words, if you
list
On Tue, 6 Jan 2004, Arnt Gulbrandsen wrote:
Alt.Fan doesn't exist, but Alt.Fan.Mark.Crispin might.
In IMAP terms, alt.fan is \noselect \haschildren.
Yes, but such a name shows up with a % wildcard. It does not necessarily
show up with a * wildcard.
Doesn't that make a mockery of \noselect?
On Tue, 6 Jan 2004, Richard Bang wrote:
At the
moment, the only clients that seems to do a good job of shared folders
are the dreaded Outlook duo from MS. I cant find any others that use
IDLE or NOOP at a reasonable rate. Any suggestions would be appreciated.
Pine does periodic NOOP.
-- Mark
On Tue, 6 Jan 2004, bj rui wrote:
mailutil check {remote.host.name:993 /user=username}
Two problems:
1) There should be no space in the string.
2) Using :993 without /ssl says to make a non-SSL connection to the
SSL port. I don't think that you want to do that.
The correct command is:
On Tue, 6 Jan 2004, Eric A. Hall wrote:
There are no mechanisms for manipulating hierarchies via the protocol. If
I want to create or rename a folder hierarchy (eg, create a #public
hierarchy), then I have to do it off-line since there is no support in the
protocol directly.
Well, supposedly
On Wed, 7 Jan 2004, David Harris wrote:
1: I don't consider myself enough of an IMAP expert to be qualfied for
the task.
You'll learn on the job. Trust me.
2: Since in 14 years of developing e-mail packages I've never once
been invited to participate in any IETF discussions of any kind, I
On Tue, 6 Jan 2004, Eric A. Hall wrote:
Right, they are partitions of the underlying mailstore. The partitions may
be tied to one or more filesystems, or they may be logical representations
of a filesystem (eg, netnews) or some representation of a database
subsystem, or whatever.
Or, instead
On Wed, 7 Jan 2004, David Harris wrote:
I guess that means I've just broken rule #1 - I volunteered. :-)
No good deed goes unpunished. :-)
Generally, there is no such thing as an invitation to a discussion.
?? Way back in 1992 or 1993 I asked John Klensin if I could take part
in the SMTP
On Tue, 6 Jan 2004, Eric A. Hall wrote:
Okay, semantics first. Servers have one (logical) mailstore. The mailstore
may contain one or more subordinate stores, which are essentially
partitions. Whereas you are saying that a server may have multiple stores,
I'm saying that those are partitions
On Wed, 7 Jan 2004, Timo Sirainen wrote:
I think that in Cyrus:
LIST foo.bar zap.zowie = foo.zap.zowie
LIST foo.bar. zap.zowie = foo.bar.zap.zowie
LIST foo.bar .zap.zowie = foo.bar.zap.zowie
but I'm not really sure; in practice only the second form is used.
Well, this
On Mon, 5 Jan 2004, Timo Sirainen wrote:
At least the task is a little bit easier if you store UIDs with the
message, rather than having to infer same message from message contents.
Several POP3 servers get UID by getting MD5 sum of some part of message, so I
think that's also quite safe to
On Mon, 5 Jan 2004, Timo Sirainen wrote:
the problem with traditional UNIX mailbox format is that
shared access itself is a problem
I don't think it's that much of a problem. It may be slow when other
applications modify it though. My plan is:
- whenever mtime or size changes unexpectedly,
On Mon, 5 Jan 2004, David Harris wrote:
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
On Sat, 3 Jan 2004, Timo Sirainen wrote:
Wasn't IMAP supposed to work with existing mail stores? How exactly do you do
this with maildir or mbox? Or anything else than mbx and other formats
explicitly designed for IMAP?
When IMAP was designed, neither maildir nor mbx existed. It was designed
On Sun, 4 Jan 2004, David Harris wrote:
What I want to know now is why is the Exchange server using this
extension?.
It is not incorrect for Exchange to send it without client permission.
flag-extension is part of the rule of mbx-list-flags (via mbx-list-oflag)
in RFC 3501, thus a server *may*
On Sun, 4 Jan 2004, David Harris wrote:
There is nothing about RFC3348 that makes it either a standard or a
standards-track revision of RFC3501 - or even of RFC2060. Its status is
nothing more than informational.
I forget now why RFC 3348 was informational. Perhaps it was because
CHILDREN was
PS: I think that the requirement for standards-track for list-extension is
new in 3501, so it can be argued that 3348 is grandfathered.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
On Fri, 2 Jan 2004, Christian Kratzer wrote:
can you perhaps further elaborate on your thoughts on why exactly you
feel that an untagged NO FETCH response is evil.
Clients don't handle it the way that you think they do. They expect that
if they issue a proper FETCH, that it will work work; and
On Fri, 2 Jan 2004, Christof Drescher wrote:
This is definitely arguable, and I personally think you are wrong. So
is RFC2180, which allows it for purpose.
RFC 2180 is informational. It is not standards-track. In part, RFC 2180
has been overtaken by events.
If it had been stated in the IMAP
On Fri, 2 Jan 2004, Tim Showalter wrote:
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
On Fri, 2 Jan 2004, Christof Drescher wrote:
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.
Whether or not that strategy will get you into trouble is
On Thu, 1 Jan 2004, Christof Drescher wrote:
..or you fail the fetch command for C1, forcing C1 to catch up!
In my opinion, it is acceptable client behavior to react to a NO response
from a valid FETCH command with Server bug detected. Please report this
bug to your server administrator. Your
On Wed, 31 Dec 2003, Christian Kratzer wrote:
A frequently used solution will be to use an index file or a header in
the message store to mark messages as expunged and only rewrite the
mailbox when an exclusive lock on it has been obtained.
Correct.
With a maildirs like message store you
On Wed, 31 Dec 2003, Arnt Gulbrandsen wrote:
a) make a simple ghost message (e.g. one with no body and a simple default set
of headers).
This is the least bad of the choices that you made, but there is another
choice, which is to keep the message around until it is expunged.
Think of what
On Tue, 30 Dec 2003, Christof Drescher wrote:
That's the problem of the ding-dong, not the problem of the server
developer.
It's a bad argument to say don't do it, because someone could misuse it.
Painful lessons of the past 30 years indicate that when harm is made
possible, harm will happen;
On Tue, 30 Dec 2003, Christof Drescher wrote:
It is neither unilateral nor unexpected, if this information is given
by the admins. If they do, everything is ok, if they don't, it is their
fault, not the programmer's.
When a user's client does not work the way the user expects, the user will
On Tue, 30 Dec 2003, Christof Drescher wrote:
When a user's client does not work the way the user expects, the user will
blame the client, not their system administrator. And the client authors
are going to lash out at any server which turns out to be the cause of the
problems.
..
On Tue, 30 Dec 2003, Paul Jarc wrote:
I'd like to skip TLS support - at least for now - and I'd like to make
it as clear as possible to clients that the server is anonymous-only.
How about this: CAPABILITY IMAP4rev1 AUTH=ANONYMOUS LOGINDISABLED
Would clients be prepared for that?
That
On Mon, 29 Dec 2003, Richard Bang wrote:
I'm getting flack from my mail server clients because IMAP marked as
deleted and then expunges. Basically they don't want to have to manually
copy all the messages to a trash can folder. They like the way their POP
clients work, moving everything they
601 - 700 of 1002 matches
Mail list logo
