I need to avoid forwarding in the emails that I'm sending using .NET. I'm using Outlook and Exchange server and I read tha IRM can help me. Does anyone have any code example or know if it's possible?
It looks like you might be able to use the Microsoft Outlook 2010 Primary Interop assembly and set the PermissionTemplateGuid property of the MailItem you're sending.
Note that you'll have to know the Guid of an IRM policy that prevents forwarding of the email.
You cannot send IRM mail programmatically in Outlook 2010. IRM mail is actually a regular mail message with an encrypted attachment, and Outlook does not expose the right API to craft the encrypted attachment and change the mail type.
The only way to do it from C# code is to use ActiveSync and send the mail in Exchange directly. Unfortunately, as of Exchange 2010, only licensed vendors can use ActiveSync.
See http://www.microsoft.com/about/legal/en/us/intellectualproperty/iplicensing/programs/exchangeactivesyncprotocol.aspx for more information.
Also, if you go down the path of setting the template guid, know that the DoNotForward template guid is hard-coded -- if it actually works (this is untested and unsupported, so you're mileage will vary) then you don't need to bother looking up the RMS template.
Related
I am currently working on a program to export/import data from other mail clients to outlook.
So far it seems I have two options available.
I learn how to write to a pst file so I can easily import the necessary data.
I create a different, self-made connection.
I am not asking which one I should use but rather on some advice because so far while planning I ran across a few things with each method that might turn out to be too much of problem.
So far I couldn't find an existing library that allows writing to a .pst file. I am lucky to finally have found a library that allows reading the pst file that is open source.
I haven't found a way yet to programmatically create a new mail item in the inbox. I have been able to create a new email that can be sent but no email yet that is "incoming".
have you looked into outlook interop?
depending on how your application will function it is a great way to interact with outlook at a high level, you can easily create mailItems, calendar, memos etc.
My recommendation would be to create a temporary IMAP account on whatever IMAP server you like best (whether that be GMail, Yahoo!Mail, some other free IMAP account, or a local Exchange/Dovecot/etc server).
Then, once you've got that setup, export mail from Mail Client X to the IMAP server and then add the temporary IMAP account to Outlook and copy them all into your Outlook folders.
I need some advice on how to solve a problem. I have an application that sends out emails to users. Note, I am using Microsoft Exchange as email server. I would like to have a feature where the user can reply to the email sent by the application and the application be able to read the reply and perform certain actions.
For example, the application will send out an email requesting approval for an item. I would like the user to reply the email and say whether or not the item has been approved or rejected. It's a very simple scenario but it captures what I want to do. How can I read emails sent to a particular address in c#?
Reading, parsing and answering emails in code is often very hard piece of machinery. If you are open to suggestions though one of the possible solutions could be a couple of Approve/Reject links in the body of the email which are linking back to your web site and triggering corresponding actions in your approval workflow. Hope it helps!
You can use EWS, see EWS Managed API, EWS, and web services in Exchange. If you are dealing with Office 365 you may also consider using Outlook REST API.
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution. Read more about that in the Considerations for server-side Automation of Office article.
If you use Outlook for sending emails consider using the VotingOptions property of the MailItem class which allows to set a string specifying a delimited string containing the voting options for the mail message. This property uses the character specified in the value name, sList, under HKEY_CURRENT_USER\Control Panel\International in the Windows registry, as the delimiter for multiple voting options. So, in a response you can use the VotingResponse property which returns a string specifying the voting response for the mail message. This property is usually set to one of the delimited values returned by the VotingOptions property on a reply to the original message.
I want to write C# application which will remotely connect to exchange server and read my inbox! I want to use MAPI for that.
So I got two questions:
Can it be done remotely, and is there any requirements(e.g. install outlook client,etc? )
I was not able to find any code example in C# which uses MAPI to connect to inbox?
1) If I remember correctly Outlook must be installed and a profile must be set up. (In short; you are reading Outlooks data, not Exchange).
2) There are samples for this:
http://bytes.com/topic/net/insights/795371-accessing-inbox-through-mapi-using-c-net
http://g8.cx/mapi/ (See 4.7)
Note that MAPI/CDO is not supported in .Net.
Other options is to communicate directly using WebDAV, IMAP, POP3 or WebServices. All will work to retrieve emails. I recommend you try the webservice.
You can access the mailbox of a user from a remote machine.The email account should be configured on that machine and then you can read the mailbox using Microsoft.Office.Interop.Outlook and this link will provide you more info.
http://msdn.microsoft.com/en-us/library/ff870566.aspx
Why do you want to use MAPI so badly ?
Just use EWS:
http://www.codeproject.com/Articles/399015/Exchange-Web-Services
I open outlook from my Winfoms application. I want to open outlook in reply mode. How can I do this.
Thanks.
so you want to open outlook and have it ready to send an email to a prefered receiver.
the quick and dirty fix i think is to have a hidden webbrower in your program and let the browser navigate to mailto:mail#mail.com?subject=somekindsubject
which will open the default email client on the machine.
System.Diagnostics.Process.Start("mailto:youremailaddress#whatever.com");
The mailto can be used with a lot of parameters
Check out the parameters here
http://msdn.microsoft.com/en-us/library/aa767737(VS.85).aspx
http://www.ietf.org/rfc/rfc2368.txt
Eg (Taken from MSDN)
mailto:user#example.com?subject=MessageTitle&body=MessageContent
UPDATE:
Attachments i think are not supported due to security reasons and I strongly agree with it as well.
However Outlook 2003 seems to be accepting the parameter "attachments" according to someone who has posted in MSDN.
string email = "mailto:name#domain.com?attachments=\"\"C:\\file.txt\"\"";
System.Diagnostics.Process.Start(email);
This is the best i could do and i cannot test it as I do not have Outlook 2003. But even if it works in Outlook 2003, i strongly urge you not to use the attachment parameter as it may not be supported by different programs.
You can use something like:
System.Diagnostics.Process.Start("mailto:mail#address.com?subject=Sample subject");
Which will open the default email application filling in the to and subject fields. You can find more options here.
Edit: this takes a bit of time on my system, so make sure that if your user has a slower computer they'll know what's going on. Also, you should handle the case when they don't have Outlook or another mail program installed if it's a possibility.
I’m using .NET 3.5, and I want to automatically send a mail. I’m currently using the following:
Microsoft.Office.Interop.Outlook.MailItem mailMsg =
(Microsoft.Office.Interop.Outlook.MailItem)outlookApplication.CreateItem(
Microsoft.Office.Interop.Outlook.OlItemType.olMailItem);
mailMsg.To = recipient;
mailMsg.Subject = subject;
mailMsg.Body = body;
mailMsg.Send();
However, I’ve found several articles that seem to imply I should be using the following method:
System.Net.Mail.MailMessage mailMsg = new System.Net.Mail.MailMessage();
mailmsg.To = recipient;
mailmsg.Subject = subject;
mailmsg.Body = body;
Can anyone tell me what the difference between the two namespaces if, and why you might want to use one over the other?
The first one, I assume, required Outlook to be installed in the machine so that the Office Interop assemblies are installed. The second one is pure .Net framework.
The second example needs a SMTP server, to make a direct connection, and uses this SMTP server to send the email. It has low overhead, will normally work.
If you need to compose & send an email on behalve of the current user, you could use outlook.
So far I have only seen answers with disadvantages for outlook. But it has a few advantages:
You do not have to ask the user for any configuration.
Outlook already knows the Exchange / SMTP server,
and the email address of the user
Email you send will be stored in the sent-items list of the user. So the user can see wat is sent in his name.
Add-ons that sign / encrypt outgoing email, or add a standard company disclaimer will be used, so you will follow company policies
Can prompt the user if it is allowed to send email (yes, this can be an advantage to)
You can choose to only compose the mail, present it to the user. The user can edit and choose to send it or not.
Edit:
I use the SMTP method for sending technical emails (like log files & error messages) to our support unit, these mails go out fast and unnoticed.
The Outlook method I use for sending mails on behalve of my user to other humans. These mails are slow, but are trackable, etc.
The first method is using interop by creating an instance of Outlook (outlookApplication) and having that instance of Outlook send the e-mail.
The second is used for sending e-mail over regular old SMTP and doesn't require outlook at all.
Unless you have specific needs for interop there's no need to send an e-mail using outlook (and your code won't work on any machine that doesn't have outlook installed).
First one uses COM interop, which is unneeded overhead. Second is pure .net with all it's features. Plus it is more flexible.
As other have mentioned, the first one uses outlook to send email. The disadvantage is that the user has to have outlook installed; the advantage is that it will look like outlook is sending it.
The second method will try to send mail directly. The advantage is that it doesn't require outlook to be installed, and is a lot less overhead. The disadvantage with this option is that most enterprises these days block port 25, so when you try to send the message, it will fail.
They are different.
MailItem represents message item in Outlook.
MailMessage represents an e-mail message that can be sent using the SmtpClient class.
Check MailItem and MailMessage.
First one is using COM Interop and uses Outlook as its base. It needs outlook configured. The second is using SMTP Client. The interop could run you into issues related to outlook, but will allow for some cool features like Opening a Mail Window (but its generally not worth it). The second one will send silent mail, though you can show some window of your own, but still it wont allow flexibility of Outlook Automation. My choice is System.Net.Mail.*.
The first one is using MS Office which you don't want to publish while System.Net.Mail is available when .Net framework is installed.
The first example uses libraries installed by the Office Interop Assemblies download.
The second example uses libraries installed by default with the .NET framework, System.Net.
The first example uses Microsoft Interop Libraries. I would go with your second example, since it's part of the default .NET install. The Interop libraries will have more overhead that isn't required as well.
The Microsoft.Office uses Microsoft Outlook to send the email. It requires Outlook to be installed, and is (at least the last time I tried sending mail this way) more prone to difficulties. (For example, it prompts the user to let them know that a program is attempting to send mail on their behalf, etc.)
The System.Net.Mail just uses pure .NET, and the specified SMTP server to send mail.
Trust me.. Avoid using the Office unless there's a need.
You need to use the second option any day. It's pure .NET.
If you use first option, i guess Outlook should have been installed in that machine. When you deploy, you will have problems if you don't have MS Office installed in the server.