hello iam mohit sharma i want to know how outlook express mail is opened in ASP.NET. i have so many code search code find but not find a proper coding.pls help me. if anyone have oulook express code that are using in asp.net pls send me a proper code that iam able to send a mail throgh asp.net ....
System.Net.Mail is full of bugs... It's all about "Content-transfer-encoding". The implementation of "quoted-printable" is broken. First it's possible to create lines above 76 characters in length. That's against the RFC and it's also a criteria for some SPAM blockers to recognize those mails as SPAM.) And the class also converts CRLF's to =0D=0A. It's not even against the RFC again, it's also very dirty to look at if you don't have a MIME-Client.
But the greatest is this: if you're going to use TransferEncoding.SevenBit it's doing what it's supposing: "content-transfer-encoding: sevenbit". Again, it's not RFC standard, and clients like AOL are getting totally out of line.
So for me, it's useless! And you even cannot get to fix it because all of those classes are sealed or internal or whatever! It just sucks...
Hopefully there're librarys outhere like DotNetOpenMail... I'm going to use it!
EDIT: Let me add this: After further investigation, I must admit, the performance and features of System.Net.Mail are actually pretty good. So it's even more sad, that those little bugs at the end makes this .net library nearly useless, at least at this time. So I hope, that somebody at MS will quickly fix those things...
I don't understand why you are duplicating what .NET provides. I send emails using the .NET libraries all of the time, it doesn't take 100s of lines of code, it is no more comlicated than your code. ex:
System.Web.Mail.MailMessage message = new System.Web.Mail.MailMessage();
message.Subject = "Why duplicate .net functionality?";
message.From = "email@example.com";
message.To = "firstname.lastname@example.org";
message.BodyFormat = System.Web.Mail.MailFormat.Html;
message.Body = "<H1>Really big text</H1>";
System.Web.Mail.SmtpMail.SmtpServer = eServer; // my network smtp server
System.Web.Mail.SmtpMail.Send( message );
Attachments are not much more difficult. The Visual Studio help has a complete example, including adding attachments. What is the value added of using your code that I am missing?
My Friend if you ask me to select what API to use to send emails when we compare MS.Net 1.1 and DotNetOpenMail i will prefer DotNetOpenMail, and if you you give the choise between DotNetOpenMail and MS.Net 2.0 i will prefer MS.Net 2.0, MS.Net 2.0 has rich API to send emails, the System.Web.Mail was deprecated in 2.0 for many reasons. And when it come to System.Web.Mail, it is OpenSource and you can also be the part of the DotNetOpenMail developer, its API has tested and richer, just use it you will konw then ok
There is always a cost associated with using additional libraries. The cost may be compatibility, it may be additional training, it may be the time spent integrating the new libraries into your environment. The cost is frequently the expense of support years down the road when the application becomes legacy and the non-standard libraries cannot be easily found or reintegrated.
At our site, 'preference' is not a compelling argument to bring in sofware libraries that duplicate the functionality of what we already have. We must be able to demonstrate cost efficiencies, or additional capabilities that are required but not available in the standard libraries.
Your original article stated the case for using dotnetopenmail with the introduction "Sending an email is easy if you know some networking concepts and can write about 100+ lines of code if you are a Visual Studio .Net 2003." As I showed in my previous post, neither of these is true in my case.
Thanks my friend you are right i had edited my article, please check my it.
Actually im a J2EE Developer, for some reasons i was forced to work on MS.NET environment. Now i think I'm getting used to it. Thanks for your support, and guiding me properly.
My rationale for writing DotNetOpenMail was to provide access to the basic capabilities of email construction, since System.Web.Mail in .Net 1.x doesn't allow much beyond the absolute minimum. For example, you can't do multipart/related emails with embedded images, you can't include in-memory attachments, you can't add your own text version, and so on. I don't think you can even control the encoding (base64 or qp) with System.Web.Mail.
System.Net.Mail in .Net 2.0 is a complete rewrite and consequently it's exponentially better than System.Web.Mail in .Net 1.x. I doubt there's any reason to use DotNetOpenMail in preference to it.
But if you're stuck in .Net 1.x and you need an email feature which isn't provided by System.Web.Mail, you pretty much have to go with a third-party product. (Or you might just not like the ugliness of running via CDONTS, which is what System.Web.Mail uses.)
Your explanation is a help. Just goes to show that one size seldom does fit all. Because I don't need those advanced features, they have never crossed my radar. From your explanation I can see that for someone who needs to go beyond the basics, DotNetOpenMail would be a valuable addition. For those of us with basic email needs, the .Net libraries are good enough.