OpenEMM Technical Support Forum

Which OS do you use? And do you have a specific example for us we can replicate to reproduce this behaviour? CentOS 5.5 My best recommendation to replicate the problem would be to use a setup like I described above, but I imagine getting yourself one of those isn't easy. I can facilitate a test mac...

I should also mention that my single pixel tracker that gets inserted at the top or bottom of the email is also missing the http:// <img src=3D"news.mypage.com/g.html?uid=3D1.l.2d.0.o91p83f7nq" alt=3D"" border=3D"0" height=3D"1" width=3D"1"> pace

I've reported this as a bug: https://forum.openemm.org/bugs-bug-fixe ... c1709.html


pace

When I change a link to be trackable, both on my FullView link and my unsubscribe link, the "http://" gets removed from the beginning of the URL. I end up with a link like this: <a href=3D"news.mysite.com/r.html?uid=3D1.k.2d.3v.t69jbw521c">Full view!<a> If I remove the trackable ...

Okay, I spoke too soon. The UTF8 thing fixed my regular links, but my trackable links are missing the "http://". It seems that the magic that places the uids in there is also removing the http:// for me.


pace

I would like to request that in future versions we be able to set the transfer encoding that the emails use. Right now we are forced to use quoted-printable, it would be nice to have the option to use base64. You can see the issues this is causing here: https://forum.openemm.org/post5429.html#p5429 ...

I love talking to myself. The fix for me was to set the character set of the mailing to UTF8. Of course I know this will break old old Mac Mail, but oh well.


pace

After checking around about this it looks like the "quoted-printable" transfer encoding that the email is being sent as is causing the problems with Thunderbird and creating the "3D". Anyone know if there is a way to change this to use base64?


pace

I'm seeing the same issue with my new install of 6.2. The emails work in some mail clients, but in others they do not. I've got "3D" inserted all over the place in the HTML. For example: <table cellspacing=3D"0" align=3D"center" width=3D"600" cellpadding= =3D&...

Some extra information that may help track down the issue:

• I'm on a virtual server (openVz).
• Timezone on the virtual was initially set to US/Pacific (it is now set to UTC and it is working)
• Timezone on the host machine is set to US/Pacific.
• Hardware clock of the server is in UTC.

pace

maschoff wrote:Which version of OpenEMM do you use?

6.2


pace

And survey says I've been busted by the Timezone (others have noted this in posts). I had my server in the Pacific Time Zone, but somewhere in the mix it was queuing the META files for the current GMT time (+8 hours) and then pickdist.py was waiting then until Pacific Time caught up with the time GM...

Update: About 10 hours later the emails that had piled up over the course of my evening of testing started slowly going out. I've just gone and requested another confirmation email and it is sitting in the META directory again (probably waiting for 10 hours). So I guess my problem is more around why...

I'm able to send test emails, but my confirmation emails are not going out. Here's what I've found out so far: Test emails work properly. Files are created in spool/META, including the xml.gz, .stamp, and .final. These files appear to be properly formated and the xml.gz is created with the informati...