Newsletter Hyperlinks Dead in Webmail

[Beer_man]

Hi,

I know this problem is not restricted to myself as it also happens to a friend..

When a newsletter email with a hyperlink is sent to a webmail account, the webmail account sometimes removes the site name from the hyperlink..eg.

http://www.sitename.com/index.php?main_page=index&cPath=4

is changed into..

http://www.name-of-webmail-provider.com/index.php?main_page=index&cPath=4

and so the hyperlink is dead. I know that lycos.co.uk does it for sure.

Anyone know why?

Cheers

Beerman

[kobra]

I think that you are describing a condition that exists if the receiving account can only receive "Text" mail and not html/rich text mail format...

[Beer_man]

Thanks Kobra,

Trouble is, when I receive emails from say Amazon, all their hyperlinks work fine..it really does seem to be restricted to emails sent via my own and my friends ZC stores.

Cheers!

[Chuckl]

Examine the headers of the affected emails for Content type, charset and Mime or encoding headers.
This could be caused by 8bit header and 7bit ecoding in the body, or vice versa.

[kobra]

Trouble is, when I receive emails from say Amazon, all their hyperlinks work fine..it really does seem to be restricted to emails sent via my own and my friends ZC stores.

Check in your admin that you have mime enabled among others:
admin > config > email options

Use MIME HTML When Sending Emails  	true

[Beer_man]

Thanks Kobra and Chuckl

Email is set to send MIME (true) and also html (naturally!!)

If there is say, 8bit body and an 7bit header, (I haven't checked actually) can this be changed in Zen? Nothing that I can see in admin?

Cheers!

[Chuckl]

<Broad Brush On> Setting Use Mime 'assumes' encoding etc. However there are complicating issues where the actual encoding and the header do not match.

One issue is that /admin/includes/extra_configures/ does not have a copy of email_use_8bit.php, while /includes/extra_configures does, as documented here:

http://www.zen-cart.com/forum/showthread.php?t=60847

This causes newsletters etc sent from admin to use 7bit mime by default. Cure is to simply put a copy of the file there.

There is also an issue if you are sending test emails to 'Admin', where any use of HTML is problematic, discussed here:

http://www.zen-cart.com/forum/showthread.php?t=56507

[Beer_man]

Thanks Chuckl,

Seems like you had a similar problem as me. I'll give the first method a go and see what happens. Thanks to you and Kobra for taking the time to reply.

Cheers!

Beerman

[Beer_man]

Hi All,

Sorry to post again on this, but HTML is still going funny when sent to webmail accounts

If I send, for example a discount coupon to an email address with thunderbird as the email client it looks perfect..colours, images, HTML, all there.

If I send the same coupon to a webmail address (I have tried two accounts) its screwed up..no colours, no logo, some hyperlinks work..

I receive mail from three separate ZC stores, and this happens to all of them.

Anyone else who sends HTML based emails (either company or personal) to the webmail addresses gets there intact. This shows its a ZC issue and not a webmail issue.

Surely sending HTML embedded email is one of the most basic functions of the internet?

email_use_8bit.php has been copied and I have also uploaded a new version of functions_email.php. No change


Any help/advise appreciated.

[Chuckl]

You would indeed think that sending HTML mail would be a basic function; and you'd be wrong. Email predates the www by years, and HTML mail is a very recent (overall) addon.
Essentially, each service decides what it will and will not accept, and it is a matter of trying to juggle settings to please as many as possible. Anything wrong, and the HTML gets stripped out. Send from known domain is usually a very good idea, as well as sending from a real email address. Ditto having an MX record for the domain pointing at a real mail server. And not being blacklisted - your domain or your hosting co's mail servers.
That said, Zen Cart is not perfect, and it could have, and will need to have greater functionality and flexibility in the future; I'm busy looking at it.
A recent development is that some hosting companies are switching their mail servers to multibyte and UTF-8 character sets only, which also plays havoc with the above.

A useful guide to such things is here:

http://www.swiftmailer.org/wikidocs/v3/tips/spam