I have recently been working with javamail. Right now, I am trying to store all mails in a file. For such a thing, one would need a unique ID, so I assumend UID would fit best here. However, I noticed something odd: A mail in the "Inbox" Folder with the subject "Hello" has the UID 10. If I fetched the same message from the "All Messages" folder, I'd get the same Message(because I am in "All Messages") with the same content, but with a different UID.
This isn't actually that much of a problem, however, is it possible that two completely different mails from different folders might have the same UID? In this case, I would have to overthink the way i store mails.
Thanks in advance.
The UIDs are not JavaMail UIDs, they're IMAP UIDs, defined by the IMAP RFC.
The UIDs are unique per-folder, based on the UIDVALIDITY value for the folder. There is no unique ID for the folder itself.
Depending on your needs, you might consider using the Message-ID for the message, although note that while it's very, very likely to be unique, there's no guarantee that it is unique, and there's no guarantee that it exists for every message.
Related
From what I've read, every Message-ID must be unique, however it is possible to create repeated Message-IDs if we force the header with a fixed value. So I don't understand what the point of them saying that the Message-ID should be unique, but they are very easy to create duplicates. If they can easily be generated by anyone with a little reading and basic programmatic knowledge, why do Message-IDs exist and what are they used for, which I can easily duplicate?
Short answer: For threading in email clients.
The message-id header is defined in RFC 2822:
The "Message-ID:" field contains a single unique message identifier.
The "References:" and "In-Reply-To:" field each contain one or more
unique message identifiers
The message ID is used to show which message is a reply to which other message, for example. That way mail clients can show a tree of emails with their replies even if other things like the Subject don't change. (Counting leading Re:s of the subject line would be a bad way to determine ancestors and children: not every mail client adds them, and some use language specific ones.)
https://datatracker.ietf.org/doc/html/rfc5322#section-3.6.4
in conjunction with the References and In-Reply-To fields, mail clients use Message-ID to organize multiple messages into threads.
https://en.wikipedia.org/wiki/Message-ID
and at least some clients will consider two messages with the same ID to be the same thing and discard one of them.
Mail user agents usually display threads of Emails by chaining messages together according to the In-Reply-To and References header fields that contain the Message-IDs of other messages. Although a mail usually only replies to one other message, it may be the case that one message answers multiple others. The standard allows multiple entries in both fields. What can I expect when I send an email that References or is In-Reply-To multiple IDs this way?
Is it good practice to do so?
Does it confuse widespread MUAs?
Is there any common ground on how to display such a message in a
threaded view?
The "In-Reply-To:" field will contain the contents of the
"Message-ID:" field of the message to which this one is a reply (the
"parent message"). If there is more than one parent message, then
the "In-Reply-To:" field will contain the contents of all of the
parents' "Message-ID:" fields. If there is no "Message-ID:" field in
any of the parent messages, then the new message will have no "In-
Reply-To:" field.
Technically there COULD be a reason where you would reply to multiple emails and it would be valid to place multiple message ids in the In-Reply-To header. I can’t think of any program that actually supports this. As to MUAs they won’t care the delivery that the MUA cares about is the To, Cc, Bcc headers.
The In-Reply-To header and References header would control how threads are displayed. Not sure if any mail clients would have an issue handling the multiple In-Reply-To headers. 99% of the time there would only be a single message ID in the In-Reply-To header. So it’s feasible mail applications won’t support it. However they would support the additional reference entries. And this shouldn’t pose an issue.
We're considering using an external application to send e-mails where the attachments have huge filesizes.
One of our users states the requirement: it must be possible to ORDER attachments, so that I can refer to them as "the first attachment", "the second attachment" and the receiver will see the attachments in the same order I sent them.
She claims any normal email clients support this: the sender chooses the order, the recipients client always shows the attachments in this order.
I can't verify that claim. Is this true? Is it stated anywhere? How (technically) are attachments ordered?
Well... Inside the message there is order. Attachments are sent sequentially one-after-the-other inside MIME text. But RFC makes no statement on how these should be displayed in email client. And it even might depend on your email generating software to keep the order you added the attachments in (JavaMail does so)
Things you could consider:
Prefix your attachment filenames with a number 1_first_attachment.txt 2_contract.pdf and so on.
Use HTML for your emails and create a section "attachments: a, b, c" with linkd to the attachments using Content-ID (href="cid:xxx")
Actual, when u load the document to the email, and load next, they gonna be in order anyway. They not gonna be mixed.
if u afraid that particular ur email gonna mix attachments, just add numerical order)
This is example where i just adding files. I just by holding shift click on the files in that order that i wanted and that is all.
And i receive this message with attachments in the same order as it was sent.
I will use java mail api to handle mails like thunderbird etc. I have to fetch mails having 1000 messages. My design will be: When user performs a synch on a folder, i will get all uids of the messages in the folder:
Message[] msgs = ufolder.getMessagesByUID(1, UIDFolder.LASTUID);
// Use a suitable FetchProfile
FetchProfile fp = new FetchProfile();
fp.add(FetchProfile.Item.ENVELOPE);
fp.add(FetchProfile.Item.FLAGS);
I wil then compare the list of uids with the list stored in my db.
For the deleted ones, for example a message is not in the folder but in the db, i will mark it as deleted.
For the new ones, for example a message is in the folder but not in the db, i will mark as possible new. But, because messageuids are not safe (can be changed by the mail server on some cases), for the new mails, i will use additioanlly a custom hash value build from message id in the header + subject + receivedate and build a md5 hash. Only for the possible new mails i will use this hash and catch new mails.
For the moved messages, because their uids will be changed in the new folder, it will be flagged as deleted in the first and will be a new message in new folder, but the message will have same custom hash value becaue message id in the header and other properties will remain same duing the movement.
Question about performance issue: On each click on folder (folder synch) i will do the compare operation of all uids in the folder with the local uid list stored in the db to learn the deleted ones. I could not find another better way to accomplish this. As you know, thunderbird catches immediately a deleted message without relogin, even if the folder is large and the deleted message is very old (5 years). I think thunderbird also compares all message uids in that folder with a list stored locally.
How can i implement a better mechanism for the synch for a better performance? Does thunderbird apply a different approach? How can thunderbird
accomplish it so quickly?
If we were interested only for the new messages, i could have kept last stored uid and only compare the new messages later than that, but for the deleted ones, i already have to compare full folder. Additionally, UIDNEXT value is always -1 in my mail server, if it were set correctly, it will not help to get deleted ones again, a full compare is a must i think, am I wrong?
Note: I canot not use or add message listeners because the appliaction is server-client based and the mail handling task is on the server side and we do not support threads listeners etc. The events should be triggered from the client and the request is being processed on ther server and a response is returned and client handles the response on the gui.
What you want is called condstore or quick resync, RFC7162 in both cases. That's what Thunderbird uses.
That's a pair of extensions support commands like "give me all the UIDs that have changed since last time I connected", "tell me what's been deleted" and so on.
If you can't use threads to listen for these events from the mail server, your options are very limited. Probably the best thing you can do is limit the resynchronization to the messages that are visible to the client.
I'm writing a script to analyze my mailbox and want to periodically check for new messages. The search criteria would be: give me the UIDs for all emails with UID greater than X, where X is the UID of the last email I processed.
Or, more generally, I'm looking for a way to only see messages since my last search.
Note that I'm not looking for seen/unseen messages; the script opens the mailbox as read-only, and I'd like it to not interfere with my flags, etc.
I know I can specify a date in the IMAP search, but the granularity of that seems to be by day, so not exactly what I need.
I'm starting with Gmail as the IMAP server, but would like to support generic IMAP servers in the future.
Is there way to search for emails with UID greater than X? Or another means of specify all messages since message X?
You can use IMAP SEARCH for UIDs. Assuming your most recently fetched UID is 1999, I think you would do:
SEARCH UID 2000:*
Why not use IMAP IDLE for this?
with IMAP IDLE, the server warns you every time a new message arrives