How about:
resp-text-code /= PROGRESS SP tag SP progress SP time-to-go
progress = number ; 0 = progress = 100: estimated progress as a percentage
/ nil; no reliable estimate available
time-to-go = number ; 0 = time-to-go: estimated time remaining in seconds
/ nil
I've pushed version 02 of the Channel draft to the ID editor. Early
access can be had at:
http://atg.aciworldwide.com/draft-nerenberg-imap-channel-02.txt
Diffs from version 01:
Changed channel-set to use section-spec instead of section-text.
This allows retrieval of headers and
I see no reason not to do this in UW imapd (and make a user very happy), but
before I do it I'd like to get a sanity check from the community -- is there
any reason why this might be a bad idea?
As long as you define localhost as any interface that has the IFF_LOOPBACK
bit set this should be
I believe the only safe implementation of RENAME is one that creates a new
mailbox, copies all messages to that new mailbox, and then deletes the
source mailbox. The client can do that just as easily as the server.
I agree. RENAME appears simple at first glance; in practice it has
turned out to
I do not believe that people should architect protocols or software
implementations to compensate for the limitations of firewalls and NATs.
Rather, it is up to the vendors of firewalls and NATs to build products that
can accomodate the protocols and software that the firewall/NAT will carry.
3) Why not imagine a new protocol? Because, truly, the world does not need
yet another protocol that overlaps with 98% of one or more existing
protocols.
In this case, it does need a new protocol. IMAP was never intended to do
what you're asking of it. Twisting the semantics of an existing
We need to be able to be able to
scale to 10K users. Can someone give me some feedback
or perhaps point me to a resource in order to
accomplish authenticating users to Mysql or Oracle.
Why don't you run some tests and see for yourself how well it scales?
First hand knowledge is a good thing.
What are you're thoughts on AUTHENTICATE in this regard? Should a
server not advertise the AUTH= capability after authentication has
been performed (and succeeded)?
I don't think it really matters (since clients cannot make use of the
capability after authentication). In my servers I remove
On Thursday, July 3, 2003, at 11:42 AM, Alexey Melnikov wrote:
I believe Junk and NoJunk are in use (no leading $).
Does anybody have any information on how there are used?
Apple Mail's junk filter uses the Junk, JunkRecorded, and NotJunk flags.
--lyndon
I don't think there is anything broken other than the original issue
of the client using an invalid sequence number in SEARCH which
should/must return BAD.
Good. You had me scared there for a minute ;-)
Barry, are you planning to issue a revision to RFC 2683? If so, this
whole issue of command
On Friday, July 11, 2003, at 08:49 AM, Cyrus Daboo wrote:
I would like to see Alexey's document recommend a best practice for
naming of keywords in the 'private' area to avoid namespace problems:
specifically a 'vendor.productid.xxx' convention. I'm already using
that format for the keywords
Do servers generally do that?
Servers are *required* to do that.
--lyndon
$Work, $Personal:
Is there a need to standardize these? It seems to me that the
reason for $* flags is to ensure functional compatibility
between clients. I cannot think of any functionality that would
be triggered by these flags. All they're really useful for is
On Monday, July 14, 2003, at 10:28 AM, Mark Crispin wrote:
On Mon, 14 Jul 2003, Chris Newman wrote:
RFC 1734 (POP3 AUTH) has a normative reference to RFC 1731. Until it
is
revised, we can not move RFC 1731 to historic.
And it looks like RFC 1939 has a normative reference to RFC 1731.
As do
--On Monday, August 11, 2003 1:33 PM -0400 Pete Maclean
[EMAIL PROTECTED] wrote:
FETCH 1:* BINARY[1]
I expect it would be rare for a client to issue a FETCH for a specified
body part for multiple messages but it is certainly possible and I can
imagine odd situations where it would be quite
[This thread is getting far afield from imapext's charter. Let's move it
to the IMAP protocol list. PLEASE remove [EMAIL PROTECTED] from any
replies.]
[[Cyrus: why won't Mulberry let me set a Reply-To header?!?]]
On Monday, August 25, 2003 12:14 AM +0100 Paul Smith [EMAIL PROTECTED]
wrote:
Does
I disallow BINARY[] in my server, but I can be convinced that that was a
mistake given that RFC 3516 says that it is OK.
Didn't Ned catch this and ask the RFC editor to make the change before
publication? I have to dig through my email archives and verify what
happened. Meanwhile, I'm dealing
--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. I
--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
As Lyndon said, the proof that it works well is in the existence of
multiple implementations in which it works well.
And for the record, I have participated in interoperability tests with
a number of servers. Those that have proven themselves include: UW,
Cyrus, and MessagingDirect. Others have
--On 2004-1-6 7:32 PM -0500 Pete Maclean [EMAIL PROTECTED] wrote:
While we are on the subject of clarification, I am moved to suggest
one other related area where I think some clarification would be
beneficial. That is to specify the minimum requirements for a
mailstore to be suitable for use
--On 2004-3-23 3:09 PM -0500 Paul Jarc [EMAIL PROTECTED] wrote:
The user would also be notified for NO [ALERT], right? So the only
difference is closing the connection? How might that help?
If the server *knows* that the error is such that it simply cannot
continue to perform any useful
--On 2004-4-8 2:04 AM +1200 David Harris [EMAIL PROTECTED]
wrote:
I've
never been concerned about this in the past because the RFC states
clearly that the client MUST wait for the continuation response
before proceeding, so no issue has ever previously arisen as a
result.
The reason we have
Have any of you looked at the draft-cadar-dhc-opt-imap-00 draft? From
the abstract:
This document describes a new option for Email related configuration
information in Dynamic Host Configuration Protocol (DHCP), the option
for Internet Message Access Protocol (IMAP) Server addresses for
--On 2004-7-20 8:09 AM +0530 Arnt Gulbrandsen
[EMAIL PROTECTED] wrote:
3. It does seem rather wrong for you to be inserting mail into SMTP
and directing the error messages at someone else. If there is a
problem between your fetchmail and the next delivery of the message,
where should the error
--On 2004-8-6 2:04 PM -0700 Stuart Nicholson
[EMAIL PROTECTED] wrote:
I do still feel the server in question is in violation of the RFC
however the above point makes this unimportant. Violating both word
and spirit of the RFC seems to be the norm rather than the exception
with the IMAP servers
--On 2004-8-19 12:37 AM +0300 Timo Sirainen [EMAIL PROTECTED] wrote:
Having clients store flag changes permanently in client side would be
useful for publically accessible IMAP mailboxes. I think clients
should do that for flags not included in PERMANENTFLAGS list, but
they don't.
I'm not
On Wednesday, August 13, 2003, at 09:20 AM, Pete Maclean wrote:
What I was actually trying to get at is this: should the server set
the \Seen flags for messages for which it has returned data or not?
Yes, it should.
Given my understanding that you have implemented this, I am wondering
28 matches
Mail list logo
