On calling /me/messages Outlook API, it returns details of every message including Internet Message Headers, but can we select specific named headers from that. Because while dealing with large amount of data this may reduce some memory... And on performance wise too, it reduces the iterations to search for specific message...
Depending on the Internet header property you want to look at it most get promoted as Extended properties onto the Message so if you use singlevalueextendedproperties definition https://learn.microsoft.com/en-us/graph/api/singlevaluelegacyextendedproperty-post-singlevalueextendedproperties?view=graph-rest-1.0 of that particular property you can get and filter on particular internet headers. You can use a MAPI editor like MFCMapi or OutlookSpy to see what particular extended properties are available on Message.
Related
A quick note in case you come upon this question hoping for a solution.... there isn't one. Sadly sometimes one has to accept that the right answer to one's question is "You can't do that".
I am hoping there is something I can do here to ensure that attaching a large file to an Outlook.MailItem works exactly the same as doing so manually.
To be precise... when a user composes an email in Outlook and they attach a file that is too large to the email, Outlook will happily attach the file to the email. Instead of simply refusing to do so, it will attach the file and a message will appear in the Inspector:
However....
When coding a similar action you would get access to an Outlook.MailItem and you would invoke the .Add method on its .Attachments object
oMailObject.Attachments.Add("<path to a file that is way too big here>")
The problem is that that action fails. An error is thrown
"The file you're attaching is bigger than the server allows. Try putting the file in a shared location and sending a link instead."
Yes, we can obviously catch the error and then show a message to the user. That's what we're currently doing. It would, however, be nicer if there were a way I can prevent it from raising the error so it would still attach the file to the MailItem, and then when I show the inspector to the user they would see the same thing they would see if they had attached the attachment manually.
Is there an option on the MailItem to prevent it raising an error? Something in the Attachments.Add method? Any suggestions?
The Attachments.Add method doesn't provide anything for that.
You may consider adjusting the maximum size of the attachments in Outlook. Regular mail profiles can be configured using the windows registry keys.
HKEY_CURRENT_USER\Software\Microsoft\Office\<x.0>\Outlook\Preferences
HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\ x.0 \Outlook\Preferences
There you can add a value type: DWORD
Value name: MaximumAttachmentSize
Value data: An integer that specifies the total maximum allowable attachment size. For example, specify 30720 (Decimal) to configure a 30-MB limit. Specify a value of zero (0) if you want to configure no limit for attachments.
Exchange accounts require configuration on the Exchange side, read more about that in the Microsoft Exchange Server email account configuration section.
You can read PR_MAX_SUBMIT_MESSAGE_SIZE MAPI property (DASL name is "http://schemas.microsoft.com/mapi/proptag/0x666D0003") from the store (use Store.PropertyAccessor.GetProperty) - it returns the size in kB - prior to sending the message. This property is Exchange-specific.
I am trying build an api which conforms to the json:api spec.
My api has three resources /task, /item and /result. A task has the fields name, description and state. A item has the fields itemName. A count is kept server-site for the item and the count is returned when a user retrieves the item with a GET request. The count is incremented server-side when the item is updated. There is a one-to-many relationship between task and item. In a sense an item is appended to a task. When the tasks state changes a script runs server-side to do some processing on the associated items. Once the script finishes the output is available in the result resource.
Per the spec, I am using the POST verb to create a task and the PATCH to update a task. I just want one endpoint which handles both the create /update (appending) of an item. But, I'm not sure which verb to use? Can I use PATCH to update the item but also create an item if it doesn't exist?
I also thought that perhaps I should be using the PUT verb. But, my understanding here is that this verb is used to simply replace a resource rather than update it. I don't think this is right for my user-case as an items count is incremented when updated, so replacing it is not what I want todo. But, the count is handled server-side so a user doesn't have the option of "replacing" the count anyway.
my understanding here is that this verb is used to simply replace a resource rather than update it.
This is a common understanding - wrong, but common.
The IANA registry documents the authoritative reference for the semantics of http methods. Most of the common ones are defined by RFC 7231; PATCH is defined by RFC 5789.
PUT is an appropriate choice when the message body is a complete representation of what you want the resource to be. It may be easier to think about "saving a file"; PUT describes what the client expects the document to look like when it has been saved.
It's appropriate to use PUT for either updating a document or creating one, provided that the client knows the identifier for the document (just in the same way that we can use save to create a file, or replace a file, but we need to know the file name).
If you read the text of the specification, you'll see that - while the semantics of the request are to save the new representation "as-is", the server isn't required to do that -- the server, after all, is in control of its own documents -- so there is room to cover read only fields, or fields that should be updated by the server only. You need to have a little bit of care with the response headers to avoid implying that you saved the representation as is, but other than that you should be fine.
I'm using MS Office 2016 Desktop App on Windows 10.
I didn't find any success searching online and also contacting MS Outlook Support to find that there is no easy way to achieve it except VBA script.
We send individual mail having an attachment, to a huge bulk of people. (I'm fine with this.)
I want when an email is not sent successfully (because of incorrect email address or other reason), to perform some action on the original email (not the undeliverable mail notice).
Possible action could be printing the mail and its attachments to some other email.
I want this as it is burdensome to print individual emails from around 1000s of emails daily.
MS Outlook rules don't provide the condition for 'when email undelivered' or similar. Can this be achieved with VBA script?
In theory - yes. Firstly, you need to make sure you get the actual NDR and the object type is ReportItem. That shouldn't be a problem if you are sending through Exchange, but if you are sending through POP3/SMTP account or if the NDR is delivered as a regular plain text message from the target server rather than your own Exchange Server, all bets are off.
The various report properties are stored in the recipient table of the NDR items. Unfortunately, ReportItem in OOM does not expose the Recipients collection like it does for MailItem. You can get NDR information from the Body property, but unfortunately OOM has a bug (left unfixed for a few years now) that causes ReportItem,Body to return meaningless garbled text. See Extract text string from undeliverable email body to Excel.
In most cases, you would be able to extract the message id of the original message (that caused in the NDR) from the PR_TRANSPORT_MESSAGE_HEADERS property (take a look at an NDR with OutlookSpy - I am its author - click IMessage button). You can access that property using ReportItem.PropertyAccessor.GetProperty("http://schemas.microsoft.com/mapi/proptag/0x007D001F"). You can then try to extract the In-Reply-To MIME header and use it to search for the original message in the Sent Items folder using Items.Find on the PR_INTERNET_MESSAGE_ID property (DASL name http://schemas.microsoft.com/mapi/proptag/0x1035001F). And here lies another problem - it is possible that the item in the Sent Items folder will not have that property: it is set automatically by Exchange, but the item in teh Sent Items folder in the cached store might not have it because most likely the item in never synchronized (this is due to bandwidth optimization trick by Outlook), so you might have to open the folder in the online mode using the MAPI_NO_CACHE flag, which OOM won't let you use - it is either Extended MAPI (C++ or Delphi) or Redemption (I am also its author - any language). See https://stackoverflow.com/questions/45952523/what-is-the-vba-property-for-server-folder-contains-x-itmes for an example.
I have already checked the following links but they weren't much helpful (in parenthesis I've explained why it didn't work in my case as suggested in their answers)
Streams - hasOutOfBandMetadata and getStreamingMetadata (our content is already HLS)
Sonos player not calling GetStreamingMetadata (getMetdata is not called, only getMediaMetada is called since radio stream has unique id and is not a collection)
In Sonos API documentation it is mentioned that "hasOutOfBandMetadata" is deprecated and it is recommended that metadata be embedded inline with the content. However due to some limitations it can't be achieved in our service thus I have to go with the old way itself (whatsoever it is).
I suppose, ideally "getStreamingMetadata" should be called after setting "hasOutOfBandMetadata" to true but it's not happening.
Secondly, for testing purposes I set "secondsRemaining" and "secondsToNextShow" for different values to find out that "description" is also being displayed for those different time intervals (if I set secondsRemaining/secondsToNextShow to 20 then description is displayed for 20 seconds, if set to 200 then for 200 seconds and likewise). After the time lapses, information inside "description" disappears. So I guess there must be some call going to refresh metadata after the time lapses but couldn't figure out which call.
Kindly explain what is the proper way to get metadata for a continuous radio stream. On TuneIn radio you can find Radio Paradise for which metadata is getting updated as track changes. Even if they use metadata inline with their content there must be some way to achieve this.
Can you please post the calls and the the response that you are sending? This would help with troubleshooting this issue. Also what mimeType are you trying to use?
At this time the only full supported method for getting metadata for a continuous radio stream on Sonos that will be guaranteed to work in future releases is to embed metadata in line.
I have been trying to figure this out as I am working on a deliverable for which I need to provide metadata for emails. As the title suggests when I am recording this metadata often the MailItem.Senton property will be greater than the MailItem.ReceivedTime property. How is this possible?
This is due to the fact that these values come from different places - the Date MIME header is created by the sender, while the received time is based on the receiving machine time.