 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / ASP.NET / General / June 2007Subject text length limit in system.net.mail?
Is anyone aware of a size limit imposed on the subject text when using the System.Net.Mail library? I'm getting problems of message not being recieved if the subject exceeds 15 chars. Thx Hello Alec, I assume that it is the mail server limitation, because the Subject in System.Net get the string type and doesn't trim it Relation the standard, below, there is no 15 chars limitation for the subject "RFC 2822 ("Internet Message Format")" 2.1.1. Line Length Limits There are two limits that this standard places on the number of characters in a line. Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF. The 998 character limit is due to limitations in many implementations which send, receive, or store Internet Message Format messages that simply cannot handle more than 998 characters on a line. Receiving implementations would do well to handle an arbitrarily large number of characters in a line for robustness sake. However, there are so many implementations which (in compliance with the transport requirements of [RFC2821]) do not accept messages containing more than 1000 character including the CR and LF per line, it is important for implementations not to create such messages. --- WBR, Michael Nemtsev [.NET/C# MVP]. My blog: http://spaces.live.com/laflour Team blog: http://devkids.blogspot.com/ "The greatest danger for most of us is not that our aim is too high and we miss it, but that it is too low and we reach it" (c) Michelangelo AM> Is anyone aware of a size limit imposed on the subject text when AM> using the System.Net.Mail library? AM> AM> I'm getting problems of message not being recieved if the subject AM> exceeds 15 chars. AM> AM> Thx AM> Thanks for that info Michael. Ok. It must be something else then. I'm using Exchange Server 2003 and am aware that subject lines can normally be much longer than 15 chars. What I'm trying to do is send a batch of marketing messages (HTML format) from our CRM database. The HTML of the body, plus the subject line and the list of recipient email addresses all come from the SQL db. By doing a lot of trial-and-error testing yesterday I found that I had to either reduce the HTML in size such that it was going to be useless (literally no more than a bare minimum valid doc with a single "hello" paragraph), or reduce the subject text to 15 chars or less. While going over those limits does not cause an exception, the message just seems to vanish into the ether - not even being present in the Exchange log file. I have wondered if this is partly due to the Symantec AV client (Corp/Enterprise ver 10.1). This certainly introduces a lengthy 1.5 - 2 minute delay in the message being handled, but I cannot be certain if it is stopping the messages altogether. I have tried stopping all the Symantec services. This allows the messages to be delivered far more quickly (I'm using my own address for testing), but it doesn't seem to prevent the larger content variations from disappearing. I'm at a real loss to know what's going on here. I have used Net.Mail very successfully in other projects, but in those cases, the content of the message had very little DB-sourced content (though there was interaction to SQL in terms of lookups and saving of data). Using the same project to test a "plain text" version of sending works every time, so I have been checking the content of the DB stuff for invalid characters that might cause the process to "stall", but as yet have not found anything obvious. The subject text is input via a simple Win-form textbox. The HTML content is create using an HTML editor component based on the Nikhil Kothari component. While it does introduce unwanted variations in the html source, I don't think its anything that would cause such an issue. Any further help would be deeply appreciated. Regards, Alec > Hello Alec, > [quoted text clipped - 35 lines] > AM> AM> Thx > AM> Hello Alec, Well.... I'm not the expert in Exchange server, suggest to refer this question to the exchage group I see the other problem in the approach you choose. If u fix your issue and everything will be working fine, than what if the client, who u ship the app, decided to change the mail server? You are not assured with new mail server limitation I'd suggest to review your architecture, and add feature to send the links to pre-generated html pages published somewhere. So, if client's mail server works wrong, you can switch on alternative way --- WBR, Michael Nemtsev [.NET/C# MVP]. My blog: http://spaces.live.com/laflour Team blog: http://devkids.blogspot.com/ "The greatest danger for most of us is not that our aim is too high and we miss it, but that it is too low and we reach it" (c) Michelangelo AM> Thanks for that info Michael. AM> AM> Ok. It must be something else then. AM> AM> I'm using Exchange Server 2003 and am aware that subject lines can AM> normally be much longer than 15 chars. AM> AM> What I'm trying to do is send a batch of marketing messages (HTML AM> format) from our CRM database. The HTML of the body, plus the AM> subject line and the list of recipient email addresses all come from AM> the SQL db. AM> AM> By doing a lot of trial-and-error testing yesterday I found that I AM> had to either reduce the HTML in size such that it was going to be AM> useless (literally no more than a bare minimum valid doc with a AM> single "hello" paragraph), or reduce the subject text to 15 chars or AM> less. AM> AM> While going over those limits does not cause an exception, the AM> message just seems to vanish into the ether - not even being present AM> in the Exchange log file. AM> AM> I have wondered if this is partly due to the Symantec AV client AM> (Corp/Enterprise ver 10.1). This certainly introduces a lengthy 1.5 AM> - 2 minute delay in the message being handled, but I cannot be AM> certain if it is stopping the messages altogether. I have tried AM> stopping all the Symantec services. This allows the messages to be AM> delivered far more quickly (I'm using my own address for testing), AM> but it doesn't seem to prevent the larger content variations from AM> disappearing. AM> AM> I'm at a real loss to know what's going on here. I have used AM> Net.Mail very successfully in other projects, but in those cases, AM> the content of the message had very little DB-sourced content AM> (though there was interaction to SQL in terms of lookups and saving AM> of data). AM> AM> Using the same project to test a "plain text" version of sending AM> works every time, so I have been checking the content of the DB AM> stuff for invalid characters that might cause the process to AM> "stall", but as yet have not found anything obvious. AM> AM> The subject text is input via a simple Win-form textbox. The HTML AM> content is create using an HTML editor component based on the Nikhil AM> Kothari component. While it does introduce unwanted variations in AM> the html source, I don't think its anything that would cause such an AM> issue. AM> AM> Any further help would be deeply appreciated. AM> AM> Regards, AM> AM> Alec AM> AM> "Michael Nemtsev" <nemtsev@msn.com> wrote in message AM> news:a279a63a3f83138c9801711e88fa8@msnews.microsoft.com... AM> >> Hello Alec, >> [quoted text clipped - 36 lines] >> AM> AM> Thx >> AM> Finally figured what it was - Internet Message Filter for Exchange settings were a little too protective. Had it on a setting of 5, but this seems to be sinking any message that has long subject lines, or certain HTML tags, such as "<pre>". Al > Hello Alec, > [quoted text clipped - 102 lines] >>> AM> AM> Thx >>> AM> Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.