newsletters not sending in HTML format - using newsletter subscribe mod

[TheOracle]

It would be best to uninstall the previous version of the newsletters MOD and then install the new one to avoid any unexpected problems with your online store.

[shopjackiesjewels]

I hit remove on the subscription manager then downloaded the newest version of the newsletter subscribe. now i am allowed to send text only emails and not html emails and I still do not get notifications of new orders placed on my online store. please advice.
thanks

[Chuckl]

In Admin-Configuration-Email Options, please check the setting of the 3rd item down - Use Mime HTML when sending emails.
Please check the 10th item down - Email Admin Format.
In Customers-Subscription Manager, 2nd column-Preference, is there a mix of TEXT and HTML, or predominantly one or the other.
If your admin email address is a web based mail service such as Gmail or Hotmail, please log on to the service and check the spam/blocked mail folder for your any missing messages.

[shopjackiesjewels]

everything is set correctly and it still doesnt work.

[Chuckl]

Then I'd suggest temporarily replacing the new 1.3.7 /includes/functions/functions_email.php with the functions_email.php from your old version. Another forum member had a similar problem, and this cured it.

[shopjackiesjewels]

just tried that still no luck. sorry guys

[Chuckl]

Thanks for the test email, to say it is sparse is an understatement...

Firstly, Could you check Amind-Tools-Server Info for the PHP version (at the top), and in the PHP Core section, what memory_limit is set to, and post the result here?

Secondly your host seems fairly set on using sendmail -f or smtpauth as the mail transport, as well as having the mail come from a mail address at your domain - i.e. that the sent FROM email address is something@your_domain.

Finally, the mail headers are to me a bit wierd, as there is 'anti abuse' tracking stuff inserted not quite in the mail body, but not where I would expect to see it.

Here is a typical piece of text mail header from a ZC store

Received: by xxxxxxx.xxxxxxxx.xxx (Postfix, from userid 33)
id 86B4B3F041; Thu, 26 Apr 2007 12:50:38 +0100 (BST)
To: [email protected]
Subject: PO #8
FROM:[email protected]
Message-Id: <[email protected]>
Date: Thu, 26 Apr 2007 12:50:38 +0100 (BST)
X-Virus-Status: No
X-Virus-Checker-Version: clamassassin 1.2.3 with clamscan / ClamAV 0.90.2/3164/Thu Apr 26 10:13:10 2007

and the message follows

However the test mail from your shop is as follows

Received: from xxxxxxxx by xxxxxx.xxxxxxxxxxxxx.xxx with local (Exim 4.63)
(envelope-from <[email protected]>)
id 1HiVng-0003Ex-HI
for [email protected]; Mon, 30 Apr 2007 08:20:20 -0500
To: [email protected]
Subject: Test email from zen cart issue
Date: Mon, 30 Apr 2007 08:20:20 -0500
From: xxxxxxxx xxxxxx <[email protected]>
Reply-to: xxxxxxxx xxxxxx <[email protected]>
Message-ID: <[email protected]>
X-Priority: 3
X-Mailer: PHPMailer [version 1.73] via Zen Cart
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="iso-8859-1"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - xxxxxx.xxxxxxxxxxxxx.xxx
X-AntiAbuse: Original Domain - xxxxxxxxxx.xx.xx
X-AntiAbuse: Originator/Caller UID/GID - [32248 750] / [47 12]
X-AntiAbuse: Sender Address Domain - xxxxxx.xxxxxxxxxxxxx.xxx
X-Source:
X-Source-Args:
X-Source-Dir:
X-Virus-Status: No
X-Virus-Checker-Version: clamassassin 1.2.3 with clamscan / ClamAV 0.90.2/3183/Mon Apr 30 12:41:06 2007

with the strange anti-abuse tracking placed inside and after the PHPMailer header, which is generated by the Zen Cart store code. Don't think I've ever seen that before. Could just be mail server setup tho.
The content transfer encoding header is also a bit strange on a text only email, but it is at least setting up as 8 bit mime.

If you could post those server info numbers we will dig some more.

[Chuckl]

Jackie,

Could you replace /includes/functions/functions_email.php with the attached file and repeat the test with the test email address please

[Chuckl]

Whoops, got a bit enthusiastic there, could we try that again with this one

[Chuckl]

We took this 'off forum' to conduct some tests, from which it appears that the hosting service mail server might be responsible. Any text email is sent 'as is', with the addition of an x-antiabuse tracking header.
Any HTML mail also has the x-antiabuse header added after the Mime Content-Type header line, and the rest of the email is truncated/thrown away.
This occurs whether the mail is sent to another mail server or one of the web based services.

Only suggestion I can make to double check is to enable email archiving to verify that the full email body is indeed being generated, and if so, to pursue it with the Hosting Service.