System.Net.Mail.SmtpPermission not granted for smtp client from within a webrole.

Question

Hello, In attempting to use System.Net.Mail.MailMessage smtp client, I get:  Request for the permission of type 'System.Net.Mail.SmtpPermission failed. exception while setting the port #. I assumed we can send mail from Azure, i.e. trust level is sufficient.

Note, this is on my local system, haven't deployed to the could yet. (don't got no invitation yet :( )

Any ideas? Attempts to set trust level in web config faild due to override setting.

Answer 1

Can you cut and paste more of the call stack. I know others have been able to send mail using Azure, but it requires some careful configuration, the error will help us point you in the right direction.

Answer 2

Hello, it is thrown on the line setting the port:

client = new SmtpClient();
client.Host = "smtp.gmail.com";
client.Port = 587;

System.Security.SecurityException

{"Request for the permission of type 'System.Net.Mail.SmtpPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed."}

"   at System.Security.CodeAccessSecurityEngine.Check(Object demand, StackCrawlMark& stackMark, Boolean isPermSet)\r\n   at System.Security.CodeAccessPermission.Demand()\r\n   at System.Net.Mail.SmtpClient.set_Port(Int32 value)\r\n   at BlackRoosterCloudTest_WebRole.Book_Default.SendRoosterMail(String receptient, String senderEmail, String senderName, String subject, String body, Boolean isHtml) in C:\\Users\\Marek\\Documents\\Visual Studio 2008\\Projects\\BlackRoosterCloudTest\\BlackRoosterCloudTest\\BlackRoosterCloudTest_WebRole\\Book\\Default.aspx.cs:line 85"

I'm not sure what the problem could be as this is just a connection to an external server. Do you think its specific to offline mode? Thanks for any help.

Answer 3

You can only send smtp email out on the standard port (25).  The default security policy of Azure (and medium trust) will not allow you to send outbound email on another port.  See this page for more information: http://www.west-wind.com/WebLog/posts/232833.aspx

Shan McArthur
www.shanmcarthur.net

Answer 4

Of course I cannot change the server port number to 25, so I can't send email? Seems strange since as far as I understand it all this is, is a connection to a remote port of 587 on any local port. No different than any other tcp connection, which is just as much a security hole.

Answer 5

This might be an oversight in the Windows Azure policy. Given that we give you unrestricted socket permissions. It makes sense to give you unrestricted SMTP permission. We have to add the following change to our policy

http://msdn.microsoft.com/en-us/library/system.net.mail.smtpaccess.aspx

The Windows Azure trust policy should probably include ConnectToUnrestrictedPort. We'll have to discuss this change with the appropriate internal security folk. However, I think this is likely just a bug on our end.

Answer 6

This sounds reasonable.

Answer 7

Windows Azure still cannot send email on any port other than SMTP, and with public services such as gmail and pretty much evey ISP, this is a big problem.  The fix is a single line change to a config file, yet this issue has been outstanding for a couple of months now.  Can we have an ETA on when this bug is going to be resolved?  Sending email from a website is a critical requirement.

Thanks,
Shan McArthur
www.shanmcarthur.net

Answer 8

Hi Shan,

I believe this is now addressed via the full trust support we launched at MIX.  More detail here:
http://blogs.msdn.com/windowsazure/archive/2009/03/18/hosting-roles-under-net-full-trust.aspx

Hope this helps.

Thanks,
Mohit

Answer 9

I am really happy to chime in here since MSFT has responded in a way that my dream MSFT should. ie: Find out how what users need and then build safe enablements to provide those that fall within reason.

I am often put off by colleagues with their uninvited advocacy for MSFT, always telling us what we can and cannot do with Azure, as if Azure was carved in stone and sent down from the Mount of God. These gentlemen end up shutting down open dialog and aborting the opportunity for MSFT to really gather up a full plethora of ways that users can be enabled. This is a crucial time for the 'Azure evolution' (as I choose to think of it). It is also in evolution. And hey! preview environments are not for everyone. Some people want to rush to near-production release and then actually begin hoping that it doesn't change much thereafter because their code would break! The whole idea of a preview is to see how the 'purported solution' measures up against the 'utopian solution'. Hopefully, coming out of this activity, a great balance solution emanates that meets most people somewhere reasonable.

Anyone who followed the evolution of ASP.NET MVC 1.0 will know that this MSFT 2.0 is not in the mood of "This is what you've got, deal with it!". They want to know what we want and try to build facilities to support those easily, where feasible. I was a confidential tester for MSFT even in the years that you had to sign non-disclosure aggreements to get a crack at pre-beta bits. And I know that MSFT does change things because it is important to people.

Thank you Daniel for listening, and thank you mms_ for your persistence, bothering on righteous indignation.

My advice to the rest of us: Seriously, sometimes, silence is truly golden.

Answer 10

Pita,

I don't want to read into what you are saying because it appears you are somewhat upset at someone, or a group of people (I just hope it wasn't me).  That said, please remember that a lot of people who are responding on this forum are doing so properly.  Azure is a piece of software, and with all software, there is a set of capabilities and limitations.  From what I have seen in this forum, I don't see any people submitting "uninvited advocacy for MSFT".  I see a lot of people helping others out of problems, directing them with approaches that should work to achieve their goals within the limits of Azure, or letting them know what the limits are so that they don't spend any more time fighting with it.  In this case, the earlier CTPs could not send email out on any port other than port 25, and that was a small oversight by MSFT, but it was a real limitation until the latest CTP was released.  It is appropriate for these limits to be discussed here, as well as the solution when it is addressed in a future CTP.  I have benefited a lot from other people's posts on particular topics in this forum, and I am glad that they not kept their voices silent. 

Shan

Answer 11

I completely agree with you, Shan. Your latest sentiments  exactly echo mine: Let the voices be heard and let MSFT take in the input.

Having said that, I did address a pattern of comments which I consider unnecessary advocacy. I cannot fault your claim to not see those. It could be because they don't exist or because you are smack in the middle of it. I am a student of patterns and I have observed a tendency to overreach in this community.

See Shan, we cannot shine brighter than the light emanating out of us. There are lots going on in MSFT on the Azure platform that we don't know. When someone complains against the status quo, we can either (a) defend the status quo (b) solve the problem or (c) cut down the noise so the compainant can be heard by someone that has the solution.

For example: When a person says: "I want to send email through port 587", To tell him that he 'can only' do it through port 25 is defending the status quo. If you are MSFT, then that is fine because you know. If you are not, it is what I call advocacy and that's bad for this stage of the software.

Shan, I think you and I should do (b) and (c) right now until RTM. You think I am upset because I point these out? That's an unnecessary characterization  and is in fact, wrong. I just want to improve the quality of feedback we provide MSFT by fostering an atmosphere that promotes it.

I encourage the ability some of us have to make useful contributions and bring value to the Azure community as early adopters. But like the old Western said, "A wise man must know his limitations"

P

Answer 12

Hi Daniel,

Can you let me know if a resolution has been made since this post.  I'm currently trying to send smtp outbound on port 587 to gmail but no joy.  Has the full trust changes addressed the issue as stated below, and if so, how? I guessed that it would be some service definition file changes(possibly an OutputEndpoint) but it seems not to be the case.  Any light you could spread on this would be a great help.

Michael

Answer 13

So after testing I saw that Mohit's reply was correct:

"I believe this is now addressed via the full trust support we launched at MIX.  More detail here:
http://blogs.msdn.com/windowsazure/archive/2009/03/18/hosting-roles-under-net-full-trust.aspx"

Changing the Service Definition file to allow full trust mode fixes this issue: <WebRole name="WebRole" enableNativeCodeExecution="true">