View Issue Details

IDProjectCategoryView StatusLast Update
0012382mantisbtemailpublic2016-07-11 15:38
Reportersveyret Assigned To 
PrioritylowSeverityminorReproducibilityalways
Status acknowledgedResolutionopen 
Product Version1.2.3 
Summary0012382: Long emails aren't sent and make Mantis freeze
Description

Mantis sometimes send very long e-mails (more than 50k characters), especially for old issues with many notes.
In our compagny the SMTP server does not accept those long e-mails and this makes the whole Mantis getting stuck.
I saw that some other issues (0008885, for example) where due to e-mail not sent. This may be the cause.

I made a patch which adds a configuration option which allow to limit the e-mail size. This patch is made with standard diff (to be applied with patch -p1) against version 1.2.3. Sorry, I did not have time to set up git correctly.

Tagspatch
Attached Files
long-email.patch (2,036 bytes)   
diff -Naur mantisbt-1.2.3/config_defaults_inc.php mantisbt-patch/config_defaults_inc.php
--- mantisbt-1.2.3/config_defaults_inc.php	2010-09-21 09:16:10.000000000 +0200
+++ mantisbt-patch/config_defaults_inc.php	2010-09-21 09:16:26.000000000 +0200
@@ -483,6 +483,12 @@
 	$g_phpMailer_method		= PHPMAILER_METHOD_MAIL;
 
 	/**
+	 * select the e-mail max length (in x1024 characters). Length is unlimited if set to 0.
+	 * @global int $g_email_max_length
+	 */
+	$g_email_max_length = 0;
+
+	/**
 	 * This option allows you to use a remote SMTP host.  Must use the phpMailer script
 	 * One or more hosts, separated by a semicolon, can be listed.
 	 * You can also specify a different port for each host by using this
diff -Naur mantisbt-1.2.3/core/email_api.php mantisbt-patch/core/email_api.php
--- mantisbt-1.2.3/core/email_api.php	2010-09-21 09:16:56.000000000 +0200
+++ mantisbt-patch/core/email_api.php	2010-09-21 09:17:08.000000000 +0200
@@ -871,7 +871,7 @@
 
 	$t_recipient = trim( $t_email_data->email );
 	$t_subject = string_email( trim( $t_email_data->subject ) );
-	$t_message = string_email_links( trim( $t_email_data->body ) );
+	$t_message = string_email_links( cut_long_email( trim( $t_email_data->body ) ) );
 
 	$t_debug_email = config_get( 'debug_email' );
 	$t_mailer_method = config_get( 'phpMailer_method' );
@@ -1014,6 +1014,28 @@
 }
 
 /**
+ * cut overlengthed emails
+ * 
+ * @param string 
+ * @return string 
+ */
+function cut_long_email( $p_string ) {
+	$t_max_len = config_get( 'email_max_length' ) * 1024;
+	$t_string = $p_string;
+	$t_cut_end = "\n\n(...)";
+	if( $t_max_len > 0 && strlen( $t_string ) > $t_max_len ) {
+		$t_string = substr( $t_string, 0, $t_max_len - strlen( $t_cut_end ) );
+		$t_pos = strrpos( $t_string, "\n" );
+		if($t_pos !== false && $t_pos > 0) {
+			# Clean cut at end of line
+			$t_string = substr( $t_string, 0, $t_pos );
+		}
+		$t_string .= $t_cut_end;
+	}
+	return $t_string;
+}
+
+/**
  * closes opened kept alive SMTP connection (if it was opened)
  * 
  * @param string 
long-email.patch (2,036 bytes)   
long-email-git.patch (2,330 bytes)   
From 14766bcdd0f0f678a5aa6c28c0f692a791ccf5cd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?St=82phane=20Veyret?= <sveyret@axway.com>
Date: Thu, 10 Feb 2011 13:54:37 +0100
Subject: [PATCH] 0012382: Long emails aren't sent and make Mantis freeze

---
 config_defaults_inc.php |    6 ++++++
 core/email_api.php      |   24 +++++++++++++++++++++++-
 2 files changed, 29 insertions(+), 1 deletions(-)

diff --git a/config_defaults_inc.php b/config_defaults_inc.php
index 8406f9e..47f6182 100644
--- a/config_defaults_inc.php
+++ b/config_defaults_inc.php
@@ -483,6 +483,12 @@
 	$g_phpMailer_method		= PHPMAILER_METHOD_MAIL;
 
 	/**
+	 * select the e-mail max length (in x1024 characters). Length is unlimited if set to 0.
+	 * @global int $g_email_max_length
+	 */
+	$g_email_max_length = 0;
+
+	/**
 	 * This option allows you to use a remote SMTP host.  Must use the phpMailer script
 	 * One or more hosts, separated by a semicolon, can be listed.
 	 * You can also specify a different port for each host by using this
diff --git a/core/email_api.php b/core/email_api.php
index 5fa2606..69cd167 100644
--- a/core/email_api.php
+++ b/core/email_api.php
@@ -871,7 +871,7 @@ function email_send( $p_email_data ) {
 
 	$t_recipient = trim( $t_email_data->email );
 	$t_subject = string_email( trim( $t_email_data->subject ) );
-	$t_message = string_email_links( trim( $t_email_data->body ) );
+	$t_message = string_email_links( cut_long_email( trim( $t_email_data->body ) ) );
 
 	$t_debug_email = config_get( 'debug_email' );
 	$t_mailer_method = config_get( 'phpMailer_method' );
@@ -1014,6 +1014,28 @@ function email_send( $p_email_data ) {
 }
 
 /**
+ * cut overlengthed emails
+ * 
+ * @param string 
+ * @return string 
+ */
+function cut_long_email( $p_string ) {
+	$t_max_len = config_get( 'email_max_length' ) * 1024;
+	$t_string = $p_string;
+	$t_cut_end = "\n\n(...)";
+	if( $t_max_len > 0 && strlen( $t_string ) > $t_max_len ) {
+		$t_string = substr( $t_string, 0, $t_max_len - strlen( $t_cut_end ) );
+		$t_pos = strrpos( $t_string, "\n" );
+		if($t_pos !== false && $t_pos > 0) {
+			# Clean cut at end of line
+			$t_string = substr( $t_string, 0, $t_pos );
+		}
+		$t_string .= $t_cut_end;
+	}
+	return $t_string;
+}
+
+/**
  * closes opened kept alive SMTP connection (if it was opened)
  * 
  * @param string 
-- 
1.7.1

long-email-git.patch (2,330 bytes)   

Relationships

related to 0017460 closeddregad Email notifications are sent in batches 
has duplicate 0008885 closeddregad Sending emails blocks the whole Tracker 

Activities

sveyret

sveyret

2011-02-10 07:59

reporter   ~0028199

Finally set up git and sent a git patch for that. Patch is for branch master-1.2.x

cor3huis

cor3huis

2011-04-07 11:09

reporter   ~0028554

Last edited: 2011-04-07 11:10

BUMP, patch is still not integrated in 1.2.5, no need for target 1.3.x this pach work in 1.2.x already :(

atrol

atrol

2013-04-27 18:33

developer   ~0036704

Removed assignment. dhx will not contribute to this issue in near future.

vboctor

vboctor

2014-03-28 02:59

manager   ~0039775

If we end up using a notification approach like the one in the pull request I submitted earlier as a prototype, then we won't have a problem with large attachments:
https://github.com/mantisbt/mantisbt/pull/101

However, till then if we want a quick fix for this, I would rather have a fix that would avoid the attachment getting too large by limiting the max number of notes, rather than the max number of characters. I would expect that having lots of notes is the reason why email notifications get too large and fail. We should also make sure that we are keeping the last N notes independent of how they are ordered based on configuration (new to old or old to new).

dregad

dregad

2014-03-28 05:14

developer   ~0039777

+1 for limiting the number of notes in email notifications

dregad

dregad

2014-03-28 11:44

developer   ~0039779

Just realized that we already have this option in the user's preferences (but it defaults to 0 = unlimited)

vboctor

vboctor

2014-03-29 23:02

manager   ~0039785

OK, so we seem to agree on the approach of having a limit on the number of issues. For example, 20?

I question the need for a per user configuration for this option. Should we deprecate this for 1.3.x+?

If we end up changing to the new notification model proposed, then both becomes unnecessary. I wonder if we just don't do anything here or just do a non-configurable limit to avoid adding a config and then deprecating it later.

dregad

dregad

2014-03-30 04:38

developer   ~0039786

Well the config is already there, so I'd propose to just change the default from 0 to (whatever) and postpone further action until it's time to revisit the new notification model.

atrol

atrol

2014-03-31 16:35

developer   ~0039799

Last edited: 2014-03-31 16:36

just change the default from 0 to (whatever)
This will not help that much.
It works only for users that are created after the change.
Existing users will go on using their stored setting in mantis_user_pref_table.

dregad

dregad

2014-06-30 05:43

developer   ~0040864

@atrol missed your update 0012382:0039799 sorry

Existing users will go on using their stored setting in mantis_user_pref_table.

So we'd have to update the individual user_pref from 0 to (whatever), matching the new default, leaving alone those users who have customized this.

So the options are:

  1. change default + write an upgrade function to update user_pref table
  2. as suggested by vboctor, disable the user-specific setting and keep only a global one (using existing $g_default_email_bugnote_limit config)
  3. do nothing
atrol

atrol

2014-07-24 16:16

developer   ~0040974

or option 4.

There are two quite different issues / settings:

a) user individual setting: number of notes to send via email
b) global setting for a technical limitation: number of bytes that can be send by email

We should not try to fix b) by using a)

I think it makes sense to introduce a new global option, but implement it in a better way (especially in terms of performance) than it's done in the attached patch:

Stop building the email if the limit will be reached instead of cutting the email at the end of the whole process.

atrol

atrol

2015-04-19 07:37

developer   ~0050552

At least the part "Long emails make Mantis freeze" should be fixed by implementation of 0017460