0012382: Long emails aren't sent and make Mantis freeze

ID	Project	Category	View Status	Date Submitted	Last Update
0012382	mantisbt	email	public	2010-09-21 11:04	2016-07-11 15:38

Reporter	sveyret	Assigned To
Priority	low	Severity	minor	Reproducibility	always
Status	acknowledged	Resolution	open
Product Version	1.2.3

Summary	0012382: 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.
Tags	patch
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)

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 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 2013-04-27 18:33 developer ~0036704	Removed assignment. dhx will not contribute to this issue in near future.

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 2014-03-28 05:14 developer ~0039777	+1 for limiting the number of notes in email notifications

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 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 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 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 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: change default + write an upgrade function to update user_pref table as suggested by vboctor, disable the user-specific setting and keep only a global one (using existing $g_default_email_bugnote_limit config) do nothing

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 2015-04-19 07:37 developer ~0050552	At least the part "Long emails make Mantis freeze" should be fixed by implementation of 0017460

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

Relationship Graph

View Issue Details

Relationships

Activities