Is there any simple way to know how many emails are in thread in GMail mailbox? I fetched information about a message (message_id, X-GM-THRID, references, in_reply_to etc) and I want to know how many other messages with same X-GM-THRID are in the mailbox. Is it possible without fetching information about those other messages?
According to this page about GMail IMAP extensions, X-GM-THRID is supported as a search key. This is the example from that page:
a009 UID SEARCH X-GM-THRID 1266894439832287888
* SEARCH 2 3 4
a009 OK Search (Success)
That gives you the UIDs of the messages in that thread, and you can just count the number of results.
If you really just want the count, and don't need the message ids, you can make use of the fact that GMail supports the ESEARCH capability (described in RFC 4731), which lets you ask for the count and nothing else:
C: 202 SEARCH RETURN (COUNT) X-GM-THRID 1261978514042297166
S: * ESEARCH (TAG "202") COUNT 2
S: 202 OK SEARCH completed (Success)
Related
EWS Managed API have two properties:ConversaionId and ConversationIndex
What is the difference between them? I guess ConversationId is the the ConversationIndex of the first mail in the conversation which is essentially of 22 bytes, while ConversationIndex is the index of that particular reply in the conversation thread, essentially of 22 bytes + multiples of 5 bytes for each reply in the conversation. Is it like that?
Also ConversationId is accessible only with Exchange Server 2010 onwards. So cant we access ConversationId in the Exchange Server 2007?
Correct, you can't access ConversationId in Exchange 2007.
The ConversationId identifies the conversation. The ConversationIndex represents the message’s position relative to the original message. ConversationId is not the ConversationIndex of the first mail. Here are some sample values I just grabbed off a new message.
<t:ConversationId Id="AAQkADIwM2ZlM2ZlLWMwYjctNDg2Ny04MDU0LTVkMTFmM2IxY2ZjZQAQACkRMjewk3RHldv8l7aTV2s=/>
<t:ConversationIndex>AQHPkWCfKREyN7CTdEeV2/yXtpNXaw==</t:ConversationIndex>
<t:ConversationTopic>test message</t:ConversationTopic>
It should be noted that ConversationId does not appear to be unique per entirely different conversation threads.
Meaning, while you can be assured that two conversations that don't share the same ConversationId are definitely not related, the converse -- that the same ConversationId guarantees the same "email thread" -- as popularly understood (people answering each other in a chain) -- does not appear to be the case.
I have discovered multiple instances of the same ConversationId on the same email Subject (every now and then) even though the cascade is not off the original.
So for example if HR sends out a "Thought of the Day" email freshly each day to a given group X, this may have the same ConversationId even if they are new chains.
This is problematic if one is sorting emails on a website from payroll by, say, "RE: your 401k" and two distinct conversations are conflated.
I am using Elasticsearch to search an email inbox. I want to be able to search subject lines as well as message bodies. Simple enough. But if I just do a simple search that ends up matching a subject line, all the email messages in that thread will be returned (because they all have the same subject line). How can I use Elasticsearch to collapse all those messages into one response, while still having it return individual messages that have matches in the message bodies? I want results that behave similar to gmail search results, in other words. Is this possible without having to do two individual searches (one over subjects, one over message bodies), and then combining the results? I'd like to avoid that if possible.
Each message includes a thread identifier, which is unique per message thread.
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
Does anybody know if is possible to access facebook messages via imap or pop to manage facebook messages within an email client?
No, this is not possible. Only the publicly documented APIs are available.
See especially the inbox connection of the User object
This Article propose a way to read and store facebook message:
The process is done through the following steps:
Logging in : Logging in might be one of the trickier parts. The way you login to an IMAP server is to use the following command:
LOGIN username password
Listing folders : The command you’d issue to the IMAP server is:
LIST "" *
Since we know from the Mailbox folder API description, there are only
three folders. These folders are:
Inbox (folder_id 0)
Outbox (folder_id 1)
Updates (folder_id 4)
With this in mind, we can hard code the following response to the list
command:
LIST (\HasChildren) "/" Inbox
LIST (\HasChildren) "/" Outbox
LIST (\HasChildren) "/" Updates
Selecting a folder : In IMAP, you use the following command to select a folder:
SELECT folder-name
Getting message content: The key in getting messages trough IMAP is a command named FETCH. The FETCH command comes with a lot of
different modes, but we’ll focus on the most fundamental ones. These
are (AFAIK) FLAGS, RFC822, RFC822.HEADER, RFC822.TEXT, RFC822.SIZE and
UID. Since RFC822 is just RFC822.HEADER and RFC822.TEXT combined, we
have one less variable to worry about.
FETCH UID Let’s start with UID, as this is the easiest one. You’d issue this command as follows:
FETCH 1:6 (UID)
The expected result would look something like this:
1 FETCH (UID 1029955483)
2 FETCH (UID 1029955484)
3 FETCH (UID 1029955485)
4 FETCH (UID 1029955486)
5 FETCH (UID 1029955487)
6 FETCH (UID 1029955488)
The equivalent command in Facebook’s API would be something like this
(I’m not sure if it’s possible to combine queries like this, but you
get the idea):
SELECT message_id FROM message WHERE thread_id IN (SELECT thread_id FROM thread WHERE folder_id = 0)
You would then use that output as the UID.
More operations are available in http://www.emailserviceguide.com/2010/01/making-facebooks-messaging-system-imap-compatible/
I understood that UID changes but the Message-Id will not be changed during any operation on a particular mail. However, after some operations I came up with this case:
Lets assume I have a total of 2000 emails in my INBOX. If I copy the 1000th email with UID 1000 and Message-Id 1000 to my Trash mailbox and then I copy that back to the INBOX, the UID will change to 2000 and Message-Id to 2000; the current for that folder. Then, regardless of the date that email will be at the top.
Now the question is, if I . fetch 1990:2000 fast (the last 10 emails), I'll get the that particular email among the 10 fetched. How would you fetch the last 10 based on the date without having to fetch 2000 emails and then sort them out by date?
If the IMAP server supports it, you can use the SORT command for this, as descibed in RFC 5256. The specific command you're looking for is probably:
C: A11 SORT (REVERSE DATE) UTF-8 ALL
S: * SORT 5 3 4 1 2
S: A11 OK SORT completed
The server response is a list of message sequence numbers that you can use for a subsequent fetch.
If your server supports the SORT extension (modern IMAP servers do), it will be announced in response to the CAPABILITY command. Here's a response from the ancient version of Courier-IMAP I'm running:
CAPABILITY
* CAPABILITY IMAP4rev1 CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES
SORT QUOTA LOGIN IDLE ACL ACL2=UNION STARTTLS