CiviCRM Community Forums (archive)

the below is for TESTING only. do not use in production (no mails will be sent). The setting you can use in your civicrm.settings.php file is:

define( 'CIVICRM_MAIL_LOG' , '/dev/null' );  // sends mail to /dev/null
define( 'CIVICRM_MAIL_LOG' , 1 ); // puts a copy of all mails sent in uploadDir/mail/*. uses a md5 hash to name the files

all mail sent via civicrm respects the above settings. so use with care

lobo

Is there any chance that the truncated body happens to be all in a single line? IIRC, there are SMTP implementations that simply cut off lines longer than X characters (where X is some large three-digit number).

define( 'CIVICRM_MAIL_LOG' , '/dev/null' );  // sends mail to /dev/null
define( 'CIVICRM_MAIL_LOG' , 1 ); // puts a copy of all mails sent in uploadDir/mail/*. uses a md5 hash to name the files

all mail sent via civicrm respects the above settings. so use with care

I don't get it. I tested on a standard (download of 2.0.3 tgz from SF) install and this define works as expected with CiviMail.

However, on our SVN (r14412) version, adding this to civicrm.settings.php still results in mails sent from CiviMail being delivered by SMTP:
define( 'CIVICRM_MAIL_LOG' , 1 );

I did capture a receipt from CiviContribute using the same setting. Is it possible that CiviMail only could ignore this setting?

Or perhaps it's because I'm re-using an existing mail?

solved

The reason my debug wasn't working was that civimail.cronjob.php requires the settings_location.php file in the CiviCRM root directory to be set correctly. Because I'd recently moved the site files, this was pointing to my old settings location, so when cron fired off the sends for CiviMail, the debug wasn't defined. CiviMail documentation on settings_location.php is here. Thanks Donald for helping me solve this.

Is there any chance that the truncated body happens to be all in a single line? IIRC, there are SMTP implementations that simply cut off lines longer than X characters (where X is some large three-digit number).

Nail on the head, Piotr. RFC2821 (4.5.3.1) specifies a maximum line length of 1000chars for any message body line. The Dojo HTML editor doesn't insert linefeeds at all in the HTML, so this results in truncated messages by any mailserver which puts the brakes on at 1000chars.

I'm having a look to see if it's easily fixable.

Thanks

Quote from: Piotr Szotkowski on May 13, 2008, 04:47:48 am

Is there any chance that the truncated body happens to be all in a single line? IIRC, there are SMTP implementations that simply cut off lines longer than X characters (where X is some large three-digit number).

Nail on the head, Piotr. RFC2821 (4.5.3.1) specifies a maximum line length of 1000 chars for any message body line. The Dojo HTML editor doesn't insert linefeeds at all in the HTML, so this results in truncated messages by any mailserver which puts the brakes on at 1000chars.

I'm having a look to see if it's easily fixable.

We should wrap the lines coming from the Dōjō anyway, then. CRM-3133 filed.

Your suggested fix tested and worked for us - emails displayed normally when sent via the mailserver which was chopping them (and via all normal routes as well).

Thanks for testing this! Lobo fixed this in r14556.

It only affects CRM/Mailing/BAO/Mailing.php - I'm sure there are other places the same fix might need to be applied. (I assume we don't modify code in the packages/ tree?)

We do when we need (like in this case), keeping the original file in packages.orig (so we can diff for our changes on packages upgrades).