When I'm getting IMAPMessage from the IMAP server and calling getMessageID() I got next id (for the privacy reasons it not real, but reproduce the differences) :
Then, when I saved this message to the disk and read it as MimeMessage and calling getMessageID() I got this :
As you can see the difference is in  for the string after @.
What could cause to such behavior ?
I'm saving to disk using Message.writeTo() method.
Found some more cases not only with , for example :
<122D4DEFEA5F484DACD7AAE386CDB1F40B4BAA@exchange.someserver land.com> from IMAP server
and after reading from the file :
<122D4DEFEA5F484DACD7AAE386CDB1F40B4BAA@exchange.someserver\r\n\tland.com> - (with \r \n\t)
And one more :
<email@example.com> from IMAP server
and after reading from file
firstname.lastname@example.org - no <>
I'm using Gmail IMAP server.
In the case of "xxx.yy.www.q" are server IP (numbers).
The first case it clearly split the line into a continuation line.
In the second case I can't imagine why it would remove the angle brackets in some cases but not others.
You didn't say what it looks like in the file.
Also, what version of JavaMail are you using?
What does the protocol trace show when you fetch the message from Gmail and write it to the file?
When you call the getMessageID method, JavaMail gets the Message-ID value from the IMAP
BODYSTRUCTURE response, which the IMAP server creates by parsing the message.
When you call the writeTo method, JavaMail asks for the entire message as a MIME stream.
It's possible that Gmail is parsing the message and "canonicalizing" the data before returning it in
the BODYSTRUCTURE, but returning you the raw message when it returns the MIME stream.
The protocol trace will show us if that's what's happening.
First of all I'm using Java 1.4.5.
In the protocol trace I see that message-id header is contains  but envelope that is used in the case of IMAPMessage to get the message id doesn't contains .
In the file message-id header also has .
i have some problem to find message without <> but it seems to be the same problem.
The question now is to understand why envelop's message id is different (not consistent) than message-id header.
With the brackets I can understand the logic - when there is IP address, correct ?
But, could be another cases that will make same inconsistency ?
Or, may be more robust solution to work directly with "Message-id" header directly ?
BTW, I can't reproduce your problem using my Gmail account.
All messages show a Message-Id in the FETCH ENVELOPE
response with angle brackets (as expected).
Do you have a protocol trace showing the inconsistency,
where angle brackets are missing from the FETCH ENVELOPE
response but are included when fetching the entire message contents?