Re: problems using mailutil to move messages from Groupwise to Cyrus
Mark Crispin wrote:
On Fri, 13 Jun 2003, Steve Hanson wrote:
+ go ahead
IMAP protocol error: STORE 1 Command, State, or Parameter
STORE 1 Command, State, or Parameter
() "13-Jun-2003 08:48:41 -0500" {1851}
The first and last line are OK. The numbers in the curly braces are
simply the size of the message being transferred (refer to RFC 3501 on the
topic of "literals").
The middle two lines are the problem. It looks like one of the two IMAP
servers sent:
* BAD STORE 1 Command, State, or Parameter
but it isn't clear which one did it. My guess is that it's the
adngate.adn.uwrf.edu server, since the biff.servers.uwrf.edu looks to be
happily in the middle of a multi-APPEND.
This is also suspicious because the "transfer" command in mailutil never
does any IMAP STORE commands. I agree with you that this looks to be a
GroupWise IMAP server issue, but I'd like to hear from the Cyrus folks and
have them verify that this isn't one of their messages.
It doesn't look like anything that I've seen in Cyrus, and a quick grep
of the source seems to confirm this.
--
Kenneth Murchison Oceana Matrix Ltd.
Software Engineer 21 Princeton Place
716-662-8973 x26 Orchard Park, NY 14127
--PGP Public Key--http://www.oceana.com/~ken/ksm.pgp
Re: problems using mailutil to move messages from Groupwise to Cyrus
On Fri, 13 Jun 2003, Steve Hanson wrote:
> + go ahead
> IMAP protocol error: STORE 1 Command, State, or Parameter
> STORE 1 Command, State, or Parameter
> () "13-Jun-2003 08:48:41 -0500" {1851}
The first and last line are OK. The numbers in the curly braces are
simply the size of the message being transferred (refer to RFC 3501 on the
topic of "literals").
The middle two lines are the problem. It looks like one of the two IMAP
servers sent:
* BAD STORE 1 Command, State, or Parameter
but it isn't clear which one did it. My guess is that it's the
adngate.adn.uwrf.edu server, since the biff.servers.uwrf.edu looks to be
happily in the middle of a multi-APPEND.
This is also suspicious because the "transfer" command in mailutil never
does any IMAP STORE commands. I agree with you that this looks to be a
GroupWise IMAP server issue, but I'd like to hear from the Cyrus folks and
have them verify that this isn't one of their messages.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
problems using mailutil to move messages from Groupwise to Cyrus
We've been happily running a cyrus mail server for several
years. Lately we've been attempting to migrate our Groupwise
users from the dark side over to our IMAP server. This seemed
straightforward enough. We're using imaputil to move the
Groupwise mailboxes over, but have run into some issues
(probably caused by the Groupwise IMAP server).
Cyrus 2.1.10 IMAP server
When we move the mailboxes with
mailutil transfer -debug {adngate.adn.uwrf.edu}
{biff.servers.uwrf.edu}INBOX.GW.
most of the mail messages move over fine, but some generate a
whole slug of errrors, and are not moved. As an example:
+ go ahead
IMAP protocol error: STORE 1 Command, State, or Parameter
STORE 1 Command, State, or Parameter
() "13-Jun-2003 08:48:41 -0500" {1851}
+ go ahead
IMAP protocol error: STORE 1 Command, State, or Parameter
STORE 1 Command, State, or Parameter
(\Seen) "13-Jun-2003 08:54:18 -0500" {2521}
+ go ahead
(\Seen) "13-Jun-2003 08:54:19 -0500" {2555}
+ go ahead
(\Seen) "13-Jun-2003 09:14:42 -0500" {2852}
+ go ahead
(\Seen) "13-Jun-2003 09:14:45 -0500" {2886}
+ go ahead
IMAP protocol error: STORE 1 Command, State, or Parameter
STORE 1 Command, State, or Parameter
() "13-Jun-2003 09:21:25 -0500" {5489}
+ go ahead
I'm not quite sure what I'm suppsed to divine from this - I
don't see anyting that jumps out at me here. What are the
numbers in the curly braces???
--
Steve Hanson
UW River Falls ITS
715-425-4357
--
-
For information about this mailing list, and its archives, see:
http://www.washington.edu/imap/imap-list.html
-
Re: Arbitrary BODYSTRUCTURE complexity?
On Fri, 13 Jun 2003, Edward Hibbert wrote: > Suppose you have a message with 10,000 attachments. How much effort do the > server writers amongst you take to produce an accurate BODYSTRUCTURE for > this, and allow FETCH to work on all of them? Or 100,000... I don't think that there is a particular "effort" in doing this, although one can envision a server running out of memory. > I couldn't see anything in RFC2060 about limits (which suggests I should > handle it), but it is a Friday so I may have missed it. I'm looking for > some guidance along the lines of "tough, you must support it" or "you should > NDR it if you're not going to" or "you can fudge it like this". I would go with the "tough, you must support it". If your server can't handle a particular message, it should fail in some horrible way indicating clearly that it's a bug in the server (e.g. crash+core dump) rather than fudge and pretend that nothing is wrong. It can then be discussed whether or not it is reasonable to expect your server (or any server) to handle the particular message. But, note that the bar of what is "reasonable" tends to move with time; and what is unreasonable in 2003 may be commonplace in 2013. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
unsubscribe me
PLEASE! -- - For information about this mailing list, and its archives, see: http://www.washington.edu/imap/imap-list.html -
Arbitrary BODYSTRUCTURE complexity?
Suppose you have a message with 10,000 attachments. How much effort do the server writers amongst you take to produce an accurate BODYSTRUCTURE for this, and allow FETCH to work on all of them? Or 100,000... I couldn't see anything in RFC2060 about limits (which suggests I should handle it), but it is a Friday so I may have missed it. I'm looking for some guidance along the lines of "tough, you must support it" or "you should NDR it if you're not going to" or "you can fudge it like this". Edward Hibbert Internet Applications Group Data Connection Ltd Tel:+44 131 662 1212Fax:+44 131 662 1345 Email: [EMAIL PROTECTED] Web:http://www.dataconnection.com -- - For information about this mailing list, and its archives, see: http://www.washington.edu/imap/imap-list.html -
