Subject text length limit in system.net.mail?

[Alec MacLean]

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

[Michael Nemtsev]

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

AMIs anyone aware of a size limit imposed on the subject text when
AMusing the System.Net.Mail library?
AM>
AMI'm getting problems of message not being recieved if the subject
AMexceeds 15 chars.
AM>
AMThx
AM>

[Alec MacLean]

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
"Michael Nemtsev" <ne*****@msn.comwrote in message
news:a2***************************@msnews.microsof t.com...

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

AMIs anyone aware of a size limit imposed on the subject text when
AMusing the System.Net.Mail library?
AMAMI'm getting problems of message not being recieved if the subject
AMexceeds 15 chars.
AMAMThx
AM>

[Michael Nemtsev]

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

AMThanks for that info Michael.
AM>
AMOk. It must be something else then.
AM>
AMI'm using Exchange Server 2003 and am aware that subject lines can
AMnormally be much longer than 15 chars.
AM>
AMWhat I'm trying to do is send a batch of marketing messages (HTML
AMformat) from our CRM database. The HTML of the body, plus the
AMsubject line and the list of recipient email addresses all come from
AMthe SQL db.
AM>
AMBy doing a lot of trial-and-error testing yesterday I found that I
AMhad to either reduce the HTML in size such that it was going to be
AMuseless (literally no more than a bare minimum valid doc with a
AMsingle "hello" paragraph), or reduce the subject text to 15 chars or
AMless.
AM>
AMWhile going over those limits does not cause an exception, the
AMmessage just seems to vanish into the ether - not even being present
AMin the Exchange log file.
AM>
AMI 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
AMcertain if it is stopping the messages altogether. I have tried
AMstopping all the Symantec services. This allows the messages to be
AMdelivered far more quickly (I'm using my own address for testing),
AMbut it doesn't seem to prevent the larger content variations from
AMdisappearing.
AM>
AMI'm at a real loss to know what's going on here. I have used
AMNet.Mail very successfully in other projects, but in those cases,
AMthe content of the message had very little DB-sourced content
AM(though there was interaction to SQL in terms of lookups and saving
AMof data).
AM>
AMUsing the same project to test a "plain text" version of sending
AMworks every time, so I have been checking the content of the DB
AMstuff for invalid characters that might cause the process to
AM"stall", but as yet have not found anything obvious.
AM>
AMThe subject text is input via a simple Win-form textbox. The HTML
AMcontent is create using an HTML editor component based on the Nikhil
AMKothari component. While it does introduce unwanted variations in
AMthe html source, I don't think its anything that would cause such an
AMissue.
AM>
AMAny further help would be deeply appreciated.
AM>
AMRegards,
AM>
AMAlec
AM>
AM"Michael Nemtsev" <ne*****@msn.comwrote in message
AMnews:a2***************************@msnews.micros oft.com...
AM>

>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

AMIs anyone aware of a size limit imposed on the subject text when
AMusing the System.Net.Mail library?
AMAMI'm getting problems of message not being recieved if the
subject
AMexceeds 15 chars.
AMAMThx
AM>

[Alec MacLean]

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
"Michael Nemtsev" <ne*****@msn.comwrote in message
news:a2***************************@msnews.microsof t.com...

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

AMThanks for that info Michael.
AMAMOk. It must be something else then.
AMAMI'm using Exchange Server 2003 and am aware that subject lines can
AMnormally be much longer than 15 chars.
AMAMWhat I'm trying to do is send a batch of marketing messages (HTML
AMformat) from our CRM database. The HTML of the body, plus the
AMsubject line and the list of recipient email addresses all come from
AMthe SQL db.
AMAMBy doing a lot of trial-and-error testing yesterday I found that I
AMhad to either reduce the HTML in size such that it was going to be
AMuseless (literally no more than a bare minimum valid doc with a
AMsingle "hello" paragraph), or reduce the subject text to 15 chars or
AMless.
AMAMWhile going over those limits does not cause an exception, the
AMmessage just seems to vanish into the ether - not even being present
AMin the Exchange log file.
AMAMI 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
AMcertain if it is stopping the messages altogether. I have tried
AMstopping all the Symantec services. This allows the messages to be
AMdelivered far more quickly (I'm using my own address for testing),
AMbut it doesn't seem to prevent the larger content variations from
AMdisappearing.
AMAMI'm at a real loss to know what's going on here. I have used
AMNet.Mail very successfully in other projects, but in those cases,
AMthe content of the message had very little DB-sourced content
AM(though there was interaction to SQL in terms of lookups and saving
AMof data).
AMAMUsing the same project to test a "plain text" version of sending
AMworks every time, so I have been checking the content of the DB
AMstuff for invalid characters that might cause the process to
AM"stall", but as yet have not found anything obvious.
AMAMThe subject text is input via a simple Win-form textbox. The HTML
AMcontent is create using an HTML editor component based on the Nikhil
AMKothari component. While it does introduce unwanted variations in
AMthe html source, I don't think its anything that would cause such an
AMissue.
AMAMAny further help would be deeply appreciated.
AMAMRegards,
AMAMAlec
AMAM"Michael Nemtsev" <ne*****@msn.comwrote in message
AMnews:a2***************************@msnews.micros oft.com...
AM>

>>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

AMIs anyone aware of a size limit imposed on the subject text when
AMusing the System.Net.Mail library?
AMAMI'm getting problems of message not being recieved if the
subject
AMexceeds 15 chars.
AMAMThx
AM>