I want to deploy an addin to outlook 2013.
The basic principle is that if an employee send an email to a certain adress, then the addin will auto fill his body with some info he must provide.
i tried this but it won't work.
if (mailItem.To == "some#example.com")
{
mailItem.Subject = "support ticket";
mailItem.Body = "IP :[ ]";
}
When exactly does the code run? in the Application.ItemSend event? What exactly does not work? You need to be a lot more specific than that.
If it is (as I suspect) the test for the email address that is failing, you need to avoid using the To property and instead loop through the Recipients collection comparing each Recipient.Address property. If it is an Exchange mailbox, the address will be an EX type address (as opposed to SMTP) and you will need to use
`Recipient.AddressEntry.GetExchangeUser().PrimarySmtpAddress`
(be prepared to handle nulls and exceptions).
Related
I've been trying to find an answer to this within MSDN documentation and various other resources, but am unable to find something that works.
Here is some C# code I am using:
private ExtendedPropertyDefinition SurpressAutoResponse = new ExtendedPropertyDefinition(
DefaultExtendedPropertySet.InternetHeaders,
"X-Auto-Response-Suppress",
MapiPropertyType.String); // Also tried with StringArray and Integer
private ExtendedPropertyDefinition OtherID = new ExtendedPropertyDefinition(
DefaultExtendedPropertySet.InternetHeaders,
"X-Custom-ID-Property-Example",
MapiPropertyType.String);
{ some other code that's unimportant in between }
var mm = new EmailMessage(Global.Exchange);
mm.ToRecipients.Add("me#me.com"); // example address, of course
mm.Subject = Subject.Replace('\r', ' ').Replace('\n', ' ');
mm.SetExtendedProperty(SurpressAutoResponse, "OOF, NDR"); // Also tried {"OOF", "NDR"} and -1
mm.SetExtendedProperty(OtherId, "12345-1");
mm.Body = "Hello World";
mm.Send();
When I inspect the headers for the incoming email, I see that my "OtherId" is correctly set, but the X-Auto-Response-Suppress is not set. Any ideas how I should be getting exchange to suppress these out of office and delivery failure reports?
Notes:
I am targeting an Exchange 2010_SP2 server, which should support this
References:
https://learn.microsoft.com/en-us/openspecs/exchange_server_protocols/ms-oxcmail/ced68690-498a-4567-9d14-5c01f974d8b1
https://learn.microsoft.com/en-us/previous-versions/office/developer/exchange-server-2010/dd633654(v=exchg.80)
UPDATE
I decided to try testing the behavior of the email and set an auto-reply/OOF on my email account. Even though the properties of the email do not include the X-Auto-Response-Suppress header, I noticed that it indeed prevented a reply. My presumption is that the header is read on the Exchange server, which also probably processes the auto-responses instead of the client. Since the client doesn't act upon the header itself, Exchange saves some data by removing it from the original email before it's transferred. Can anyone who knows please confirm this is correct?
I have had issues using that header before as the MSDN is very vague on what all it actually does. And it is mostly only utilized by exchange servers and OOF purposes. Instead there are other headers that work better. Here is an article explaining why I think it would serve you well to use other headers. https://www.jitbit.com/maxblog/18-detecting-outlook-autoreplyout-of-office-emails-and-x-auto-response-suppress-header/
If you are only wanting to catch OOF then you can change the header to:
X-Auto-Response-Suppress:OOF
But I don't see that as a good example. Here is another thread on why this isn't always the best header to use: Detecting Outlook autoreply/out-of-office emails
I have been getting the sender's email address in Outlook using the RDOMail.SenderEmailAddress property, but I have recently realised that under some cases for SMTP or IMAP email accounts, that this property is null occasionally, right after the email arrives the inbox.
There's a rather convoluted way to get the sender's email address using the Outlook Interop Library: https://msdn.microsoft.com/library/office/ff184624.aspx
However, this does not work with the Redemption RDOMail object because the RDOAddressEntry interface lacks the AddressEntryUserType and the GetExchangeUser method.
The documentation of the RDOAddressEntry object says the following about the SMTPAddress property:
String, read-only. Returns the SMTP address of the given user. If the
address type is "SMTP", the returned value is the same as that
returned by the Address property. If the address type is "EX",
Redemption tries to retrieve the PR_SMTP_ADDRESS property, if
unsuccessful, it retrieves the default SMTP address from the
PR_EMS_AB_PROXY_ADDRESSES Extended MAPI property.
Looks like it might be a more reliable way to get the sender's address if I do this in my method:
if (rdoMail.SenderEmailAddress != null) return rdoMail.SenderEmailAddress;
if (rdoMail.Sender != null) return rdoMail.Sender.SMTPAddress;
return null;
Since I don't have a reliable way to test my theory, I'm seeking help here to see if anyone has more experience in dealing with this problem.
Thanks in advance.
I cannot image why SenderEmailAddress would be null, unless you have a partially downloaded item (IMAP4 specific). There is no reason to have AddressEntryUserType or GetExchangeUser method - all you need is the address type - if it is "EX", you have a GAL user, otherwise an SMTP address.
To get the sender SMTP address, check the SenderEmailType property. If it is anything but "EX", just use the SenderEmailAddress property. If it is "EX", read the PidTagSenderSmtpAddress property using RDOMail.Fields["http://schemas.microsoft.com/mapi/proptag/0x5D01001F"]. If you get back null, check if RDOMail.Sender is not null and read the RDOMail.Sender.SMTPAddress property.
I am currently evaluating the redemption library for converting MSG files to EML files.
RDOSession session = new RDOSession();
RDOMail msg = session.GetMessageFromMsgFile(msgFile);
msg.SaveAs(emlFile, rdoSaveAsType.olRFC822);
So far Redemption is doing a really good job here in contrast to everything else I've tested against our "wild MSG-files corpus".
Nevertheless there is an issue with internal e-mail addresses. For internal e-mail addresses the resulting EML-file does contain the personal part of the addresses only but not the real e-mail address with the # sign.
I can see that RDOMail's recipient objects contains the real e-mail address in the SMTPAddress property in any case.
But there is a difference for the Address property which contains the "real e-mail address" for external addresses but something like /O=EXAMPLE ORGANIZAION/OU=SOME GROUP/cn=Recipients/cn=FBarney for internal addresses.
The latter ones are exactly the addresses that are missing the real e-mail address in the resulting EML-file.
So I tried to override the Address property like that:
recipient.Address = recipient.SMTPAddress;
But this does not have any effect on the resulting EML-file at the end.
How to convert MSG to EML with redemption without losing the real e-mail addresses for internal addresses?
This is an indication that EX type addresses cannot be converted to SMTP. This usually happens if the current MAPI session does not have access to the Exchange server that hosts these GAL objects. In your particular case, there is no MAPI session at all. You can either set the RDOSession.MAPIOBJECT property to Namespace.MAPIOBJECT from the Outlook Object Model to share the session with Outlook or you can call RDOSession.Logon/LogonExchangeMailbox/etc.
You can also try to specify the olRfc822_Redemption format to force Redemption to use its internal MIME convertor (it jumps through quite a few hoops to get the SMTP addresses from the message itself rather than GAL). By default olRfc822 uses the built-in Outlook convertor (IConvertorSession) if Outlook is installed.
I want to retrieve all mails in a conversation when a user selects an email.
I know that I can use this - https://msdn.microsoft.com/en-us/library/office/ff869870(v=office.15).aspx, but for some microsoft exchange accounts, getrootitems returning zero.
So, is there any other way that works for microsoft exchange ?
More details:
My outlook showing "Online with microsoft exchange" at bottom right.
Below process is slow as I have 1000's of mails in inbox, so this wont help me.
IEnumerable mail =
folder.Items.OfType().Where(m => m.Subject == "Test").Select(m => m);
The GetRootItems method of the Conversation class has the following description in MSDN:
If all items are deleted from the conversation after the Conversation object has been obtained, GetRootItems returns a SimpleItems collection with zero objects. In this case, the Count property of the SimpleItems collection returns 0.
Try to use the cached exchange mode instead.
I am developing an OUTLOOK 2010 addin in C#. This addin will create activities based on conversation.
For example, one user create new email, others reply,forward or CC, treat this email chain as one converstaion thread. Thoes emails have the same mailItem.ConversationID.
Based on this conversationID, my program generated an activty, and link conversationid to the activity which can be seen in each email in this email chain.
It all works fine on my machine (I reply,forward,cc in the same email chain, it get the same conversationID). However when other user reply email trigger my program generate activities, it generated different ConverstationID (the same email chain).
My question is:
1.ConversationID works only in local? Like for the same email Chain in different user's machine, the conversationID is different?
2.Is there universal mailitem conversationID for one email chain as long as user is using the same version of OUTLOOK?
var mailItem = this.OutlookItem as OutlookNS.MailItem;
if (mailItem.ConversationID != null )
{
OutlookHelper.Conversation_Index = mailItem.ConversationIndex;
OutlookHelper.Conversation_Topic = mailItem.ConversationTopic;
OutlookHelper.Current_ConversationID = mailItem.ConversationID;
CreateActivity(mailItem.ConversationTopic,mailItem.ConversationID);
}
I already tried EntryID, this attribute is keep changing.
I figured it out myself.
All the email in the same email chain has the same first 44 character of ConversationIndex. Everytime when a new replyer reply this email, the ConversationIndex will append a new ramdon generated 44 characters string. It is a universal identity applied for user using differet machine. But when the subject of this email is changed, a brand new 44 charaters ConversationIndex will be generated. ConversationID only works in local to track emails in the same email chain