View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0007683 | phpList 3 application | Statistics | public | 05-09-06 00:12 | 27-05-16 07:33 |
| Reporter | h2b2 | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | new | Resolution | open | ||
| Product Version | 2.10.2 | ||||
| Target Version | next minor | ||||
| Summary | 0007683: suggestions for improvements of open tracking | ||||
| Description | This issue has been reported by guyguylou in the French forum: see http://forums.phplist.com/viewtopic.php?t=6264 HTML messages using the usertrack placeholder are not received by Hotmail accounts. When the same HTML message is sent without the usertrack placeholder, there is no problem in receiving it in Hotmail. The message is not transferred to the Junk mail folder. Phplist reports all message were succesfully sent. This problem does not occur on other mail accounts, where html messages with or without the usertrack placeholder are received. Message tracking has been correctly set up in config.php. Server info: Linux PHP: 4.4.2 MySQL: 4.0.25 - standard. Phplist: 2.10.2 | ||||
| Tags | No tags attached. | ||||
|
|
these kind of things are hard to debug, and probably even worse to find a way to fix it. But I'll have a look at systems I use and see whether it's the same. Some of them with 80k users have easily 25% hotmail, so that would be quite disastrous. |
|
|
hmm, just did a quick check and a message that has 14k+ "views" has already on the first page quite a few hotmail users. The views are based on the "tracker" so not only does the tracker work, the message actually arrived, otherwise it would not have been a hit. So, the question is, what is the problem then? |
|
|
I haven't a clue what could be the cause. As far as I can tell, no one else has reported this problem on the forum. |
|
|
I don't know if this is related, but I've a similar issue. See forum http://forums.phplist.com/viewtopic.php?t=6482 |
|
|
When running a test with the [USERTRACK] placeholder, I noticed the link to the tracker image is modified -probably by the outgoing mailserver (i.e. Mailscanner)- to this: <img src="MailScannerWebBug" width="1" height="1" alt="Web Bug from http://www.mydomain.com/lists/ut.php?u=4f9cf3f7884....&m=32" /> It is possible that Hotmail's incoming mail scanner reacts to this "MailScannerWebBug" string and sends the message to oblivion. This is just an assumption for the moment, as I haven't had the time to check this. But, if confirmed, this might explain the issue reported by guyguylou. The "MailScannerWebBug" issue has previously been reported on the internet, e.g.: http://forum.ev1servers.net/showthread.php?t=54003 https://www.activecampaign.com/support/tt/index.php?action=kb&article=251 http://www.archivesat.com/MailScanner_discussion/thread640042.htm One article suggests this fix, provided you manage your own server: SSH as root #pico -w /etc/MailScanner/MailScanner.conf search for the line: "Allow Webbugs" and put the value in yes Allow Webbugs = yes save it and restart MailScaner #service MailScanner restart |
|
|
could it be the width and height being detected? emaillabs does not add the width and height to thei web beacon |
|
|
you could try that by hacking it out. Alternatively we can go even further, make it width=large height=large but in a hidden div or something. |
|
|
bzcoder made some interesting suggestions in this forum post: http://forums.phplist.com/viewtopic.php?p=47405#47405 =====START QUOTE===== Open tracking: instead of embedding a spacer image, which is stripped by many email services, add the option to set class="track" to an image tag. That image will then be converted to a tracking image. Advanced open tracking: option to enable htaccess/mod rewrite to create custom urls to avoid issues of email providers caching the tracking image(so instead of http://www.mydomain.com/images/tracking.png?uid=something a better url is http://www.mydomain.com/images/tracking/uid.png which mod rewrite converts back to the correct url) Embedding image options: class="embed" or class="noembed" to indicate images which should be sent with the email as opposed to images to be loaded from the server. Advanced image embedding option: class="embed2k" where 2 can be replaced with any number, so only small images are embedded while large ones are loaded from the site. This can be used to send spacers and small icons that provide positioning so they will be displayed, wheras the bigger images load off the site. Clicktracking: class="track" or class="notrack" to flag url links that should be tracked or not tracked. =====END QUOTE===== |
|
|
that's indeed interesting. I've been thinking along that line as well, and we'll include it in future devs. |
|
|
changing subject, as the thread has gone a different direction |
|
|
community contribution by email: SpamAssassin is enabled by default on Linux Servers running CentOS, Apache, Exim, and CPanel (WHM). This is by far, the most widely used web hosting configuration. There are only 4 possible ways an image can be evaluated to see if it's "an image explicitly meant for Tracking". 1) It's a remote image and not an embedded image. 2) There's no hyperlink on the image. 3) The image is either clear, white, or the same color as the location it's placed. 4) It's dimensions are smaller than whatever minimum image size they decided to use as a standard to assume that the image isn't intended for viewing. (There's a 5th, but it's not definitive and I can't think of a reasonable solution.) I would be guessing if I told you how many of these 4 criteria are required to flag the image. The reason why image substitution would resolve the issue isn't a matter of "Tricking" SpamAssassin. It's a matter of getting into compliance. As always, I'm offering a white-hat solution and not trying to game the system. By tracking an arbitrary remote image that is part of, and pertinent to the email, the 4 criteria above are no longer valid, and our email becomes more compliant with the rules. As far as " what approach others are taking in response " is concerned... Probably nothing because I haven't made this issue & solution public knowledge, and I think it would be best if it stays that way. I don't believe it's in anybody's best interest to disclose any reason why Chronwin IT & PHPList.com have a higher deliverability rate than the competition. When it comes to open-source mass mailing systems, PHPList isn't the easiest to setup or use. It isn't the prettiest one either. It is the best however. This, among other things I may disclose in the future, gives us a simple edge to implement. I know I didn't answer your questions in the matter in which you asked, but I believe I addressed your concerns. Let me know if I didn't. |
|
|
Duncan adds: Not being too aware of spam assassin I had a search for the KAM rules and found this set of rules https://www.pccc.com/downloads/SpamAssassin/contrib/KAM.cf In that file this is the rule for KAM_TRACKIMAGE rawbody KAM_TRACKIMAGE /<img[^>]*\ssrc=["']?https?:\/\/track/i describe KAM_TRACKIMAGE Message has a remote image explicitly meant for tracking score KAM_TRACKIMAGE 0.2 The regex matches an image whose src attribute has a url beginning with "track", which doesn't match the phplist tracking URL. So I was wondering whether you have a customised rule set or whether there is something else in the email that is triggering the rule? |
