Michael Nemtsev said: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>
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>
Michael Nemtsev said: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>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>
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.