Having a multiple email messages with one or more attachments in each message, how can I forward all such attachments only (not the messages, just attachments)? I am looking for a simple solution that does not take too much time.
Doing this in VBA is fairly straightforward. Use the Explorer.Selection object collection to iterate through the MailItem objects within, and iterate through each MailItem's Attachments collection, using Attachment.SaveAsFile to save each file to disk temporarily. You can then create a new MailItem object and use MailItem.Attachments.Add to add each of the saved files, then call MailItem.Display to show the email.
Related
In my OLK 2016 addin i have defined
private void ThisAddIn_Startup(object sender, System.EventArgs e)
{
this.Application.NewMail += new Microsoft.Office.Interop.Outlook.ApplicationEvents_11_NewMailEventHandler(ThisApplication_NewMail);
}
In ThisApplication_NewMail, i have some code that does some categorization with that mail when it arrives, depending on sender, and such things. This works just fine.
However, I also have defined in OLK some "move email" type rules (the mail is moved in folder nested in the Inbox, not outside the mailbox), which, on occasion, do apply to the mails that should be categorized by my addin.
Breakpointing on the method's entry does not happen, which indicates the manually defined rules process the mail before my code (for lack of a better informed technical explanation).
So I am looking for a way in which I can either write the code differently in order to process with my code before the manual defined rules, or define a priority between the two, or something in those lines.
One way i could think on working around it is to simply enumerate all the folders in the inbox and run my IFs there, however, this might end up with a performance penalty since there are a lot of unread mails to be processed.
Anyone has a better idea on how to achieve my scenario? Pointers are sufficient, not asking for the code necessarily.
All events are asynchronous, plus server side rules are almost guaranteed to run before your code does.
Try to set up Items.ItemAdd event handlers on the Inbox folder, Junk Email, and all folders that the rules point to.
First of all, the NewMail event doesn't give you a context which email is received. It is fired when one or more new email messages are received in the Inbox. If you want to process items that arrive in the Inbox, consider using the ItemAdd event on the collection of items in the Inbox. The ItemAdd event passes a reference to each item that is added to a folder.
Also, I'd suggest trying the NewMailEx event which is fired for once for every received item that is processed by Microsoft Outlook. The NewMailEx event fires when a new message arrives in the Inbox and before client rule processing occurs. You can use the Entry ID returned in the EntryIDCollection array to call the NameSpace.GetItemFromID method and process the item. Use this method with caution to minimize the impact on Outlook performance. However, depending on the setup on the client computer, after a new message arrives in the Inbox, processes like spam filtering and client rules that move the new message from the Inbox to another folder can occur asynchronously. You should not assume that after these events fire, you will always get a one-item increase in the number of items in the Inbox.
I would like to use the Outlook REST API to display the messages in a mail folder and group messages by conversations, like you have in any modern webmail.
For example with inbox, I would request using a first query such as <mailuri>/inbox/messages?$select=ConversationId (by default it is reverse chronological order)
It is not sufficient to group this request results by ConversationId because some emails may not be in inbox (think of sentmails) or they may be paginated and not returned in the first page.
Consequently, for each distinct ConversationId I need to perform another REST request, for retrieving participants or simply counting the emails in the conversation. I may use the new batch request to do this.
There are a lot of requests involved. Is there a better solution ?
As you've probably realized the REST API doesn't directly provide a way to work with conversations as an entity. This is something that we have on our roadmap to improve.
With the current state of the API what you're describing is basically the right approach. You could possibly defer the second request to "fill in" a conversation until the user selects it.
You can actually use this endpoint to cover both inbox and sentitems
https://outlook.office.com/api/v2.0/me/messages/?$select=ConversationId & $filter=ConversationId eq '${params.conversationId}'
It is my understanding that an Outlook contact's "avatar" image is stored as an Attachment object in the Attachments collection (ref).
Now suppose, as an example, that I want to keep my own (separate) contact database updated whenever the user's Outlook contacts change, so I'm registered for a PropertyChange event on the ContactItem. Is there any way to determine whether or not the picture attached to a ContactItem has changed, or do I need to call SaveAsFile() on the ContactPicture.jpg Attachment every time that I get a change notification, just on the off chance that it may have been updated?
There is no any kind of CRC of the attachment data, so you won't know if the actual binary data has changed. You can read the Attachment.Size property, and if it is different from what you had before, the data has changed for sure.
You can also read the PR_CREATION_TIME and PR_LAST_MODIFICATION_TIME properties using Attachment.PropertyAccessor.GetProperty, but these properties are not requires and can stay the same even if the data has changed.
A web application sends an email on behalf of a UserA to UserB, using the new Gmail API (Users.messages: send).
The synchronous response contains threadId, messageId which are stored in the database.
We then query the history API for any changes in user's inbox (Users.history: list).
Is there an efficient way to get all the updates since last sync (new replies, read/unread changes)?
One implementation that we tried was to filter the history API results through a custom label. Unfortunately, we noticed that once a thread/message is tagged with a specific label any subsequent responses are not labeled automatically and new replies are not included in the history API response.
A second approach was to query threads using gmail advanced search for a particular label and date (e.g. after:2014/08/29 label:MY_LABEL). The problem was that gmail does not return threads that were created before 2014/08/29 but had a reply on that date.
Any scalable suggestions would be greatly appreciated.
Not sure I understand here, users.history.list was made exactly for this. Given a previous historyId, you can then call history.list(previousHistoryid), iterate through the results to find all the message Ids that have been updated since the previous historyId. Then call messages.get() on all of those--for any messages you already knew about you can just call format=MINIMAL (to see label updates), and for new messages you can use a different format to get the message content if you need it.
I want to download mails that matches the in-place eDiscovery. I do a GetDiscoverySearchConfiguration(), then I execute SearchMailboxes() for each mailbox that GetDiscoverySearchConfiguration() returns. SearchMailboxes() returns SearchPreviewItems() where I can get the real EmailMessage Id but this does not have the email body, so I have to do another retrieve using FindItems() to get the EmailMessage object.
This is a very slow process, are there any other way to do this?
I would like to get all the mails that I can see in the
preview
Instead of FindItems(), use the ExchangeService.BindToItems() method and provide a collection of the message ids you want in batches. Restrict the property set to only the properties you need. A couple of other thoughts:
- Limit the preview response shape to just the item identifiers since you'll call BindToItems for the properties you need.
- FindItems will only return the first 512 characters of the body.
- Use paging with SearchMailboxes(). Optimal page size will depend on the property set. You'd have to test different page sizes to optimize.