LO47623: BAD FETCH COMMAND SENT BY NOTES CLIENT WHEN USING IMAP ONLINE AC COUNT

APAR status

• Closed as fixed if next.

Error description

• Customer uses Notes client as IMAP client and receives
  messages from 3-party
  IMAP server. When user connects to IMAP server, it needs very
  long time to get mail box open or Notes hangs at last.
  
  With debug parameter Debug_IMAP4Client=1, we can see that if I
  use IMAP online
  account, notes client will send following fetch command to
  server:
  A005 FETCH 8 (UID)
  A006 FETCH 9 (UID)
  A007 UID FETCH 8:9 (UID FLAGS BODY.PEEK[HEADER.FIELDS (From Date
  Subject
  Message-ID)])
  
  The above log is for connecting Domino IMAP. On Domino IMAP,
  the message UID are contiguous, so there is no problem we use
  IMAP online account. However, on 3-party IMAP system, they use
  timestamp to
  create UID, so the UID are not contiguous and the command will
  be like:
  A005 FETCH 1 (UID)
  [0] ReceiveResponse: * 1 FETCH (UID 1262579226)
  A006 FETCH 31 (UID)
  [0] ReceiveResponse: * 31 FETCH (UID 1262596721)
  
  A007 UID FETCH 1262596672:1262596721 (UID FLAGS
  BODY.PEEK[HEADER.FIELDS (From
  Date Subject Message-ID)])
  A008 UID FETCH 1262596622:1262596671 (UID FLAGS
  BODY.PEEK[HEADER.FIELDS (From
  Date Subject Message-ID)])
  A009 UID FETCH 1262596572:1262596621 (UID FLAGS
  BODY.PEEK[HEADER.FIELDS (From
  Date Subject Message-ID)])
  ...
  A356 UID FETCH 1262579226:1262579271 (UID FLAGS
  BODY.PEEK[HEADER.FIELDS (From
  Date Subject Message-ID)])
  
  You can see it creates great unnecessary load to server and
  leads performance
  issue.
  
  From RFC3501, there are following statement regarding the UID:
  2.3.1.1.        Unique Identifier (UID) Message Attribute
  
     A 32-bit value assigned to each message, which when used with
  the
     unique identifier validity value (see below) forms a 64-bit
  value
     that MUST NOT refer to any other message in the mailbox or
  any
     subsequent mailbox with the same name forever.  Unique
  identifiers
     are assigned in a strictly ascending fashion in the mailbox;
  as each
     message is added to the mailbox it is assigned a higher UID
  than the
     message(s) which were added previously.  Unlike message
  sequence
     numbers, unique identifiers are not necessarily contiguous.
  
  3-party IMAP server vendor think they do not break the RFC. They
  challenge that
  notes should not  send such FETCH command to server.
  
  I also test the IMAP offline account and find the command is
  like:
  A005 FETCH 8 (UID)
  A006 FETCH 9 (UID)
  A007 UID FETCH 8:* (UID FLAGS)
  A008 UID FETCH 8:8 (UID FLAGS BODY.PEEK[HEADER.FIELDS (From Date
  Subject
  Message-ID)])
  A009 UID FETCH 8 (RFC822)
  A010 STORE
  A011 UID FETCH 9:9 (UID FLAGS BODY.PEEK[HEADER.FIELDS (From Date
  Subject
  Message-ID)])
  A012 UID FETCH 9 (RFC822)
  
  So the offline account will not have the problem.
  

Local fix

• use IMAP offline account
  

Problem summary

• The problem will be fixed in the next release of the product.
  

Problem conclusion

Temporary fix

Comments

• This APAR is associated with SPR# YPHG7ZDK2C.
  The problem will be fixed in the next release of the product.
  

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Modules/Macros

• NA
  

Fix information

Applicable component levels

• R850 PSN

     UP