How is it possible to get the diagnostic information from an email received in Outlook. We're using some ole thing in gupta/teamdeveloper. I want to find out if the email was returned by the system if the sender was not found because we're using the sent/received date and when that is empty (which apparently happens when the mail is returned by the system) our software crashes because the ole thing can't read the empty date...
Use the Outlook_ReportItem object which is similar to a MailItem object, and it contains a report (usually the non-delivery report) or error message from the mail transport system.
If you don't have it in your automation apl already, then you'll need to re-generate the apl.
All the functions you need will be in the Functional Class once the interface has been (re) generated properly.
Related
Found a very similar question here: Email aliases not returned as "To" address in logic app
TLDR: From within a logic app "When a new email arrives" trigger, How do I get the original alias that the email was sent to?
I have a logic app that creates a ticket based off an email sent to an outlook box. Now I want to be able to choose aspects of the ticket based off of whether or not the email was sent to the mailbox itself or an alias of the mailbox. The problem I'm having is that by the time logic apps gets a hold of the email, the alias address has already been replaced with the actual box's address ("alias1#place.com" -> "actualbox#place.com").
The actual mail in the inbox has the original email's alias information in the headers, but I can only get them by looking at the properties in outlook. I've tried to get the original "To" internetheader information both within logic apps (by exporting the email to blob storage and looking at headers there) and with the Microsoft Graph API. Sadly, the email exported by logic apps doesn't have the alias information and Graph API has pretty much every header but "To". At least one other person has lamented the lack of To
That said, the actual email still has the original alias information. Can someone help me get that information in logic apps without jumping through too many hoops? A many hoop solution is welcome if none other can be found though.
Use the Export email (V2) action from the Office 365 Outlook connector. This will give you the full message with original headers (including the actual To address)!
The flow here is, trigger on the incoming email, as you already are, then add the export email action providing the message id from that trigger to pull this specific email.
From there, you you'll have one big "body" property which you'll need to interrogate to find the To address.
Caveat on this though, it doesn't work when emails are sent between mailboxes in the same Office 365 tenant. Exchange Online will "helpfully" go, "I know that address... this is the address you wanted!"
What API are you using? In Outlook Object Model / MAPI / EWS, you need to retrieve the PR_TRANSPORT_MESSAGE_HEADERS MAPI property (DASL name http://schemas.microsoft.com/mapi/proptag/0x007D001F)
We arrived at a many hoop solution.
The "Primary" email box now has some rules that look at the internet headers mentioned above (Message -> Properties -> look for 'To:').
If it finds an alias there, it will put the email in a corresponding folder for each alias.
Then we have logic apps listening to each of the alias folders which will then send the email's information to the _Core logic app that does the actual processing.
We are trying to save attachments selected by the user using Redemption but stumbled on filename escaping inconsistency between VSTO and Redemption. What we do:
By attachment context menu save attachmentSelection[1] index and filename to the db and also message entryId and storeId.
After a while (maybe even after Outlook restart) we need to save this attachment to file. To do this, we get that e-mail with Redemption by id, get attachment by index (rdoMail.Attachments[index]) and also ensure that filename match, since according to this:
https://learn.microsoft.com/en-us/dotnet/api/microsoft.office.interop.outlook.attachment.index?view=outlook-pia#Microsoft_Office_Interop_Outlook_Attachment_Index
index property is valid only during the current session. Although it is not clear what they mean. Can it change if the e-mail is saved and sent already? Or received?
For reply e-mail VSTO Attachment.Filename is "RE Test.msg" and RDOAttachment.Filename is "RE_ Test.msg" (this is msg attachment of another e-mail).
So, the questions are:
why it is different and is it documented somewhere? Can we, for example, replace _ with string.Empty for Redemption filenames or there can be other cases?
Or maybe there is a way to get RDOAttachment from Outlook Attachment object somehow?
Can we rely on that Redemption attachment index is the same as Outlook one?
Sounds like you are dealing with an embedded message attachment - unlike regular by-value attachments that expose the PR_ATTACH_LONG_FILENAME MAPI property, there is no intrinsic file name property for the embedded attachments. Both OOM and Redemption generate that property from the the embedded message subject, whcih you cam access through RDOAttachment.EmbeddedMsg.Subject. OOM does not expose embedded message attachments at all.
Yes, use RDOSession.GetRDOObjectFromOUtlookObject method
The index usually does not change, but it might. MAPI itself uses PR_ATTACH_NUM to open the attachment using IMessage::OpenAttach, but it can be different based on how the message was opened - a fake IMessage returned from MailItem.MAPIOBJECT can have a different value of PR_ATTACH_NUM from the native message returned by the store provider.
We have written an Outlook Add-in and it appears that when you add user properties to a MailObject while the user is composing it, and you then encrypt and sign it and the message is Sent, the message will end up getting sent as TNEF, despite imploring outlook to do otherwise through various settings and so on as described here: http://www.slipstick.com/problems/outlook-is-sending-winmail-dat-attachments/
So one of our clients has a contact who insists on encrypted communication and therefore our client now has an issue with this contact. Either they cannot use our Add-in to its full potential (having to avoid the functionality that adds those User Properties), or their contact complains about receiving mail with "winmail.dat" attachments.
I have since established a communication with our client's contact, and I am trying to establish what e-mail client they are using, and one thing I'm going to try is see whether they would be open to the idea of moving to another e-mail client that is TNEF capable, even if it's not Outlook. But my Google-Fu is failing me. I've googled "TNEF capable email clients" and many variations thereof "that can use" "able to" ... etc etc etc. Nothing gives me the result I am looking for, a simple list of non-outlook email clients that have native capability for handling TNEF e-mails they receive. Plenty of articles of tools to allow users to decode the winmail.dat attachments manually, sure, but no simple list of natively capable e-mail clients.
If anybody can help me with this one, it would be greatly appreciated.
Eudora used to support TNEF. Otherwise Outlook is the only one to the best of my knowledge.
I'm searching for a possibility to generate a predefined mail when the user clicks on a button in a tcl/Tk program. Up to now I'm using the mailto-protocol, but as the predefined message may have a long body, the message may be cut at some point. Thus, this is no real solution.
All alternatives I found up to now have some drawbacks. So, is there a possibility which meets following requests?
Open default mail program, which may be a proprietary one (not only the standard ones like Outlook or Thunderbird...)
Create (and open) predefined message with either much text or alternatively an attachment
Should work on at least Windows XP until current versions (Windows 10) and also with very limited user rights
Must be possible to implement with tcl or C
It would be no solution to just send a Mail in the background, as it should be really transparent what happens and which information is send...
(I know there are already many questions about similar topics, but I haven't found a solution which worked for me.)
It should be possible to automate sending mails on Windows via tcom by using the CDO.Message COM object.
That's a Windows-only solution.
A cross-platform solution which should work everywhere is using the package mime to construct the message and smtp to send it. Both are part of "the standard Tcl library", tcllib, available on any sensible system which has Tcl packaged.
As to
It would be no solution to just send a Mail in the background, as it should be really transparent what happens and which information is send...
I failed to parse it. Could you may be try to reformulate?
Update:
Well, OK, after re-reading the title I think I completely fail to understand the essense of the question.
If everything what's needed is opening a e-mail message — as in "a file with MIME-formatted text representing an e-mail message", — I think that's hardly possible because a "default program to handle e-mails" is specified for URIs having the mailto scheme.
If what's needed is to spawn a default mail client on Windows asking it to open a window to let the use compose an e-mail message destined to the predefined address, the you can use
exec [list rundll32.exe uri.dll,FileProtocolHandler "malto:$addr"]
where the addr variable contains the recipient's e-mail address.
The mailto: URIs allow specifying the message body (and may be that's what you're currently using) but they (rightfully) do not allow specifying a file name to interpret as a message, so there appears to be no way to open a mail client with a pre-made message.
Update #2:
OK, so may be I finally got what did you mean by saying "should be really transparent...". You mean the user has to see with their own eyes what will be sent, right? But what's wrong with just emulating an e-mail client by presenting the user with a dialog window showing which will be sent? This is used by every software product I have seen which had a similar feature. Various Microsoft and Mozilla products come to mind as the most visible examples. They just offer you a dialog box to browse what will be sent.
Note that even if the user saw "what will be sent" in a true mail client and hit "Send" with their own hand, nothing prevents any host among those which will be handling this message (usually two at least) from modifying it unless it was a cryptographically signed message (in S/MIME format).
Are you sure you want to go that far?
I am trying to send a report from Exchange Management Shell Exchange 2007. When I send this report to Outlook the email is formatting as expected, but when I send the email to Lotus it's losing the HTML formatting such as CSS, headings, tables and borders. The data is preserved but the formatting is incorrect.
On the other hand, when I send the message using Send-MailMessage in Exchange 2010 everything is fine even when I send it to a Lotus Notes user.
Why does this difference occur?
You're going to have to go to the Notes client, and view the MIME source of both messages and compare them using a good diff program. If one is displaying correctly, and the other is not, there will be differences, and finding out why and those differences occur should give you some clue about what is happening to break the message.
(The above is assuming that the recipient is set up to receive the message in his mailbox in MIME format. If, in fact, the user has been set up to receive messages converted to Notes rich text format, then you would have to go to the Domino server instead of the Notes client, and use the SMTPSaveImportErors setting to capture the MIME source for the two messages.)