This is quite frequently asked and with surprise & worries mixed together… Why WebDAV is able to see my Private meetings/appointments? Isn’t this a security breach? How can I get it fixed?
The answer is very simple, not this is not a bug. This is how it should work and then comes a even bigger surprise “FTW” from the receiver of this message.
Let’s understand why this is so and what you should do and what you should not do to prevent such scenarios.
There is no such thing as Private appointments/meetings in real sense and it’s a feature of the email client like Outlook/OWA. Exchange Server treat all items as same. Every calendar item has a field name “Sensitivity” which can store a value of “Normal”, “Personal”, “Private” & “Confidential”.
In case of Private appointments this is marked as “Private” which allow the email client (Outlook/OWA) to decide if this should be displayed to the user or not. With that said, this is decided at the business logic layer in the email client.
Now coming to the WebDAV, it has no business logic of itself and gives the requestor a raw output of the items/properties and leave it up to the client how they want to process those items. If you are writing a email client and want to have the same behavior as Outlook does then you should honor the value of Sensitivity before displaying the Item to the user.
Exchange Server does not support Item level permissions and this is just a way to give users some sort of liberty to share restricted items when all the users are using Outlook or OWA. If you have users in your organization which may use other email clients then you should not give them Read access to your calendar/Tasks folder. This will prevent them from reading your private (or not so private?) items.
This has been documented here as well:
Outlook 2007: http://office.microsoft.com/en-us/outlook/HA100750811033.aspx?pid=CH100788801033
Outlook 2003: http://office.microsoft.com/en-us/outlook/HP030741291033.aspx
This is probably the first bug reported by customer so far for System.Net.Mail Class in .NET 4.0 Framework, or at least the first one I worked on. This was pretty straight forward repro and I did not had to do much to reproduce the issue locally.
static void Main(string args)
SmtpClient client = new SmtpClient("contoso_smtp_server");
client.Credentials = new System.Net.NetworkCredential("User1", "Password", "contoso");
MailMessage msg = new MailMessage("email@example.com", "firstname.lastname@example.org", "Large Attachment Mail", "Large Attachment - Test Body");
Attachment attachment = new Attachment(@"d:\3mb.dat");
That saved me more troubleshooting and I changed the way the attachments were being encoded from Base64 to 7Bit and it worked like charm.
So all you need to do is add any of the following line to your code to make it work.
// Any "one" of those two code section will work
attachment.TransferEncoding = System.Net.Mime.TransferEncoding.QuotedPrintable;
attachment.TransferEncoding = System.Net.Mime.TransferEncoding.SevenBit;
Since .Net 4.0 is still in beta there will not be any hotfix for this until we hit the RTM and there is no official word on when this bug will be fixed.
UPDATE – 7/20/2010
We have an official fix and here is more information about it.
UPDATE - 7/21/2010
If you prefer not to contact PSS, you can download the hotfix by yourself from the following link.