View Issue Details

IDProjectCategoryView StatusLast Update
0007683phpList 3 applicationStatisticspublic27-05-16 07:33
Reporterh2b2 Assigned To 
Status newResolutionopen 
Product Version2.10.2 
Target Versionnext minor 
Summary0007683: suggestions for improvements of open tracking
DescriptionThis issue has been reported by guyguylou in the French forum: see

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:
PHP: 4.4.2
MySQL: 4.0.25 - standard.
Phplist: 2.10.2
TagsNo tags attached.


related to 0002705 closed PHPList v2.11 release 
related to 0008786 acknowledged view message tracking is not accurate 
related to 0015259 new Patch to customise usertrack image. 



05-09-06 02:33

administrator   ~0017945

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.


05-09-06 02:37

administrator   ~0017946

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?


05-09-06 03:40

manager   ~0017947

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.


24-09-06 18:46

reporter   ~0019138

I don't know if this is related, but I've a similar issue. See forum


18-12-06 19:48

manager   ~0022109

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" />

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.:

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


21-12-06 08:42

reporter   ~0022154

could it be the width and height being detected? emaillabs does not add the width and height to thei web beacon


22-12-06 23:20

administrator   ~0022168

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.


22-05-08 07:11

manager   ~0047672

bzcoder made some interesting suggestions in this forum post:

=====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 a better url is 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=====


22-05-08 11:18

administrator   ~0047692

that's indeed interesting. I've been thinking along that line as well, and we'll include it in future devs.


18-05-11 14:28

administrator   ~0051350

changing subject, as the thread has gone a different direction


27-05-16 07:32

administrator   ~0057742

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 & 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.


27-05-16 07:33

administrator   ~0057743

Duncan adds:

Not being too aware of spam assassin I had a search for the KAM rules and found this set of rules

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

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?