Mail is cut when using dots as only char on a line

When I send a mail that has a line with a single dot in it,

Sat, 26 Mar 2005 14:14:51 +0000

When I send a mail that has a line with a single dot in it, the mail is cut. Example mail: Test begin . . Test end As I understand it, the problem is that mail-agents use this single dot on a line as a mail-end marker. Using other webmail programs there I have no problems. The problem wouldnt be that serious, if this happens also under some other circumstances: After som investigation I found out that mail is cut when I have a long word at the end of a paragraph that contains a german umlaut and that ends with a dot. I set the automatic line break in horde to 80 chars. Here is a test mail: Test begin if I have a paragraph that ends with a german word with an umlaut in it, the mail is cut. My settings in horde are to do a line break when the line exceeds 80 chars. This is the paragraph: This is a paragraph that is two lines long. It ends with a dot. If the width is set to 80 the rest of the mail is cut if there is a long wor durchgeführt. Here is the next paragraph. You will not receive it, because the mail ist cut at the end of the previous paragraph. Test end

You need the (default) setting for $conf['mailer']['params']

Sat, 26 Mar 2005 16:36:08 +0000

You need the (default) setting for $conf['mailer']['params']['sendmail_args']. ('-oi').

I very much think this should be considered a bug. My sons t

Thu, 07 Jan 2010 18:44:04 +0000

I very much think this should be considered a bug. My sons teacher and I wasted a lot of time because most of her email texts did not reach me (she tried several times but copied some of the same text). Eventually she printed one of the emails and delivered it by hand. It turned out she had (accidentially I suppose) written a dot as the only char on a line. The dot and everything following it was cut off and of course she did not understand why and neither did I until I found this thread. I know of no other email clients behaving like this. I tested 3 email clients (MS Outlook, GMail, and an other web mail client - all of them both with HTML and plain text) and none of them behaves like this. I admit that pressing . is a little faster than pressing e.g. SHIFT+CTRL+END DEL but for most users this is a very annoying and obscure behaviour. Please remove this "feature". I don't have access to IMF myself, so I can't test a minimal example and I obviously does not have an electronic version of the email texts. But this is a reproduction of what must be the lines that trigged the "feature" (the second letter in the line just before the line with the single dot is the Danish letter ae concatenation - don't know if it makes any difference): [various texts] Kære Anders . Godt nytår også til dig. [much more text]

> this is a very annoying and > obscure behaviour. Please

Thu, 07 Jan 2010 19:02:01 +0000

> this is a very annoying and > obscure behaviour. Please remove this "feature". This is not a "feature", it's a misconfiguration by the administrator of your Horde install.

> This is not a "feature", it's a misconfiguration by the ad

Thu, 07 Jan 2010 19:13:28 +0000

> This is not a "feature", it's a misconfiguration by the administrator > of your Horde install. Thanks Michael for clearing that up. (a minor clarification: it is not "my" Horde install, as I am just the receiver of emails sent by Horde/IMP). It seems that the administrator is not quiet up to the job. I wonder if this misconfiguration is the default configuration. Anyone knows? Best regards Anders Høgsbro Madsen

> I wonder > if this misconfiguration is the default conf

Thu, 07 Jan 2010 19:30:37 +0000

> I wonder > if this misconfiguration is the default configuration. Anyone knows? As explained in the earlier comment (http://bugs.horde.org/ticket/1628#c2) the default configuration value is the correct value.

> As explained in the earlier comment > (http://bugs.horde

Thu, 07 Jan 2010 20:25:46 +0000

> As explained in the earlier comment > (http://bugs.horde.org/ticket/1628#c2) the default configuration > value is the correct value. Thanks again Michael. Over and out. Best regards Anders

Changes have been made in Git (master): commit e03b93b3ade8

Wed, 06 Sep 2017 08:17:02 +0000

Changes have been made in Git (master): commit e03b93b3ade8a3ec9ec593ef03847e252b8c2662 Author: Paul M Jones Date: Mon Jun 14 02:06:39 2004 +0000 fixed bug 1628 git-svn-id: https://svn.php.net/repository/pear/packages/Text_Wiki/trunk@161297 c90b9560-bf6c-de11-be94-00142212c4b1 package.xml | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) http://github.com/horde/horde/commit/e03b93b3ade8a3ec9ec593ef03847e252b8c2662

Changes have been made in Git (master): commit 3ae847948696

Wed, 06 Sep 2017 08:17:03 +0000

Changes have been made in Git (master): commit 3ae847948696cdbb862992abfd4077bef00961ee Author: Paul M Jones Date: Sat Jun 19 16:02:12 2004 +0000 * Fixed bug 1628 (encoding of URLs and freelinks) * Updated "Table" parser and Xhtml renderer to mark a header cell (e.g., "||~ this is a header ||") * Added "Anchor" parser and Xhtml renderer to mark anchors on a page, submitted by Manuel Holtgrewe (e.g., "[[# anchorName nice anchor text]]" to mark anchor, "#anchorName" to link to it) * Updated "URL" parser and Xhtml renderer to recognize on-page anchors git-svn-id: https://svn.php.net/repository/pear/packages/Text_Wiki/trunk@161723 c90b9560-bf6c-de11-be94-00142212c4b1 Text/Wiki.php | 1 + Text/Wiki/Parse/Anchor.php | 67 +++++++++++++++++++++++++++++++++++++++ Text/Wiki/Parse/Table.php | 33 ++++++++++--------- Text/Wiki/Parse/Url.php | 3 +- Text/Wiki/Render/Xhtml/Anchor.php | 31 ++++++++++++++++++ Text/Wiki/Render/Xhtml/Table.php | 47 ++++++++++++++++++++------- Text/Wiki/Render/Xhtml/Url.php | 11 +++++-- package.xml | 5 ++- 8 files changed, 166 insertions(+), 32 deletions(-) http://github.com/horde/horde/commit/3ae847948696cdbb862992abfd4077bef00961ee