Anyone knows what are these 2 here:
https://learn.microsoft.com/nl-nl/office/vba/outlook/concepts/forms/item-types-and-message-classes
IPM.Note.Secure :: Encrypted notes to other people
IPM.Note.Secure.Sign :: Digitally signed notes to other people
I mean secure email messages have these 2 IPMs:
IPM.Note.SMIME, IPM.Note.SMIME.MultipartSigned
I don't think that sticky notes can be signed or encrypted? (or I'm wrong?) So what are Note.Secure and Note.Secure.Sign?
Thanks
These are standard message classes in Outlook that belong to mail items, not sticky notes as you could think.
IPM.Note - Normal e-mail message.
IPM.Note.SMIME - The message is encrypted and can also be signed.
IPM.Note.SMIME.MultipartSigned - The message is clear signed.
IPM.Note.Receipt.SMIME - The message is a secure read receipt.
But the following message classes belongs to notes:
IPM.Note.Secure - Encrypted notes to other people
IPM.Note.Secure.Sign - Digitally signed notes to other people.
From the MAPI point of view every items is considered to be sent. Outlook applies its own business rules the low-level code. See Item Types and Message Classes for more information.
Also you may find the 2.2.2.49 MessageClass section for more information about possible variations and their meanings.
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.
My company has a policy of only sending passwords via encrypted email. However, that takes a little more effort then just asking and sending a quick message during a thread. Is there a way for Teams to reject a message containing a word, in this case password, and give a rejection message?
Thanks
This isn't a programming related question, so this isn't the place to ask it. I'll answer it anyway though.
We call this "Data Loss Prevention" (DLP) and it's available in some versions of Office 365. We have not yet added it for Teams but it's definitely on the roadmap. Please use "share an idea" via the Feedback (lightbulb) icon at the lower left of Teams and add your vote.
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?
My Question:
How does Outlook 2007 decide if it
should redirect an e-mail to the Junk
E-mail folder?
Background Story:
When I send a simple HTML e-mail from my domain mailbox, it's being redirected to the Junk E-mail folder.
Here are two sub questions:
Does Outlook 2007 care if the sender's outbound mailbox's reverse PTR is incorrectly configured? [If so, how can it check?]
Does Outlook 2007 care if the sender doesn't provide a plain text version of the HTML content?
EDIT: It turns out, I'm not the only one wondering about Outlook's junk algorithm. See the comments attached to this answer.
Here's a helpful answer.
"...The technology used for message
content analysis is also far from
being perfect. Microsoft has created a
dictionary of several tens thousand
words, and assigned different weights
to the words in the dictionary. The
message content analysis is nothing
more than mere summation of weights of
words contained in the message."
And here's another one.
But bear in mind:
Microsoft intentionally keeps
Outlook's spam filtering rules
secret.
Because if they didn't, spammers would have a playbook for
which they could circumvent the
rules.