Community Discussions and Support
Mail list entries are truncated

You're giving me nothing to work with - how about an example, or a more detailed description of what you're seeing? I'm not psychic.

That said, there are two general answers to this. The first is that if you can tell me specific places where you're having problems with truncation and can give me solid examples, I'll see what I can do to accommodate you... The second, however, is that if you are finding that some of your clients are sending mail with lines longer than 1000 characters, or messages that are not syntactically valid in terms of RFC2821/2822, then you should really be getting the *client* to get their programs fixed, not me. Just because I am approachable or available is not a sufficient reason to dump other developers' problems on me - problems should always be fixed at the source.

Cheers!

-- David --
 

<p>You're giving me nothing to work with - how about an example, or a more detailed description of what you're seeing? I'm not psychic. That said, there are two general answers to this. The first is that if you can tell me specific places where you're having problems with truncation and can give me solid examples, I'll see what I can do to accommodate you... The second, however, is that if you are finding that some of your clients are sending mail with lines longer than 1000 characters, or messages that are not syntactically valid in terms of RFC2821/2822, then you should really be getting the *client* to get their programs fixed, not me. Just because I am approachable or available is not a sufficient reason to dump other developers' problems on me - problems should always be fixed at the source. Cheers! -- David --  </p>

I have been running Mercury on Netware for around 15 years.  These days it is mostly to provide mail list facilities to charities.  My problem is that more and more of my users find that their emails are truncated as they go through the list process.  I know that if you can turn on MIME, this does not happen for obvious reasons. Most of the folks I serve do not have the option of modifying their email parameters. I also know that it does not happen for email forwarded by Mercury nor for email received by my few email users.  Just email distributed by the list.  I have been told that this is a function of SMTP mail.  But if there is a way to forward email without truncation, there must be a way to send to a list without truncation. Is there any way around this? Is there any fix likely in the future?

 
Thanks, Bob 

<p>I have been running Mercury on Netware for around 15 years.  These days it is mostly to provide mail list facilities to charities.  My problem is that more and more of my users find that their emails are truncated as they go through the list process.  I know that if you can turn on MIME, this does not happen for obvious reasons. Most of the folks I serve do not have the option of modifying their email parameters. I also know that it does not happen for email forwarded by Mercury nor for email received by my few email users.  Just email distributed by the list.  I have been told that this is a function of SMTP mail.  But if there is a way to forward email without truncation, there must be a way to send to a list without truncation. Is there any way around this? Is there any fix likely in the future?</p><p>  Thanks, Bob </p>

If the senders e-mail line length is not IAW RFC 2821 then it's quite possible that the lines will be truncated.  One way to solve this for the senders using these non-compliant mailers is to break-up their paragraphs with a enter once in awhile


If the senders e-mail line length is not IAW RFC 2821 then it's quite possible that the lines will be truncated.  One way to solve this for the senders using these non-compliant mailers is to break-up their paragraphs with a enter once in awhile

I have seen several popular modern mailers that replace the carriage return with a hex character (essentially send the whole message as a single line in HTML).  So that user breaking the text into paragraphs does not help.

I need a server side solution.  As I note, forwarding seems to work without problem, why does  an email list have to fail?

 

Thanks, Bob 

 

<p>I have seen several popular modern mailers that replace the carriage return with a hex character (essentially send the whole message as a single line in HTML).  So that user breaking the text into paragraphs does not help.</p><p>I need a server side solution.  As I note, forwarding seems to work without problem, why does  an email list have to fail?</p><p> </p><p>Thanks, Bob </p><p> </p>

RFC2821, the Internet standard governing electronic mail, is very specific that no line in an e-mail message body may exceed 1000 characters. This isn't optional - it's an absolute requirement.

Needless to say, there are plenty of developers out there who - whether through ignorance, laziness, carelessness or just stupidity - do not respect this type of requirement, unfortunately... For some reason, when they do, it's developers like me who actually *follow* the standards who seem to get hit with the problem. I never have understood that.

Mercury is *usually* generous about the 1000 character limit: in *most* places, it allows lines to be significantly longer than this, working on the traditional (and totally idiotic) Internet idea that you should be strict in what you offer and tolerant in what you receive. You'll notice that I'm not saying it does this everywhere - that's not a matter of design, it's just that a mail message can be read and manipulated in so many places in Mercury, and the code has been around for so long that I just haven't got around to being "generous" everywhere.

Mercury/32 v4.51 (which should be out later today or tomorrow) has had the "generosity" added in a great many places just as part of the general development process. If you find that you still have this problem with v4.51, bump this thread and I'll see if I can diagnose it in a little more detail for you.

Cheers!

-- David --

RFC2821, the Internet standard governing electronic mail, is very specific that no line in an e-mail message body may exceed 1000 characters. This isn't optional - it's an absolute requirement. Needless to say, there are plenty of developers out there who - whether through ignorance, laziness, carelessness or just stupidity - do not respect this type of requirement, unfortunately... For some reason, when they do, it's developers like me who actually *follow* the standards who seem to get hit with the problem. I never have understood that. Mercury is *usually* generous about the 1000 character limit: in *most* places, it allows lines to be significantly longer than this, working on the traditional (and totally idiotic) Internet idea that you should be strict in what you offer and tolerant in what you receive. You'll notice that I'm not saying it does this everywhere - that's not a matter of design, it's just that a mail message can be read and manipulated in so many places in Mercury, and the code has been around for so long that I just haven't got around to being "generous" everywhere. Mercury/32 v4.51 (which should be out later today or tomorrow) has had the "generosity" added in a great many places just as part of the general development process. If you find that you still have this problem with v4.51, bump this thread and I'll see if I can diagnose it in a little more detail for you. Cheers! -- David --

It appears even with v4.5.1 emails are truncating.  Any ideas when mercury will become more generous.  

It appears even with v4.5.1 emails are truncating.  Any ideas when mercury will become more generous.  
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
With selected deselect posts show selected posts
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft