The "View HTML" banner when reading a message now displays full html (images) when engaged

[p45cal]

Regarding this update:
- The "View HTML" banner when reading a message now displays full html (images) when engaged; this removes the need to double-click twice (except when the message is evaluated as Junk)

First, I'm not sure of my facts - so put me right if I'm on the wrong track.

One of the things that I liked about this was that there was a two-stage process to viewing email content.
I view messages I'm not sure about initially as plain text. Most of the time that allows me to identify unwanted messages. However, often, messages viewed as plain text appear completely empty, so I double-click that View HTML banner once, hoping that the sender still can't determine whether I've viewed their email or not. 999 times out of 1000 that is sufficient for me to determine whether I want this email.
What concerns me now is that this View HTML now goes and fetches images too, which I think (I may be wrong here!) is a way for the sender to identify who's looked at their email.
Some image links are like:
https://assets.jobserve.com/image=s/Email/jobservelogo140.gif
others though are very much more complex with a whole series of apparently meaningless characters within the link which I'm guessing is a way for them to identify which emails have been viewed.
Am I being paranoid?!

So might it be an idea to allow a choice of one or two double-clicks to reveal images somewhere in the POP Peeper options or PPTweaker (I haven't found one)?

[Jeff]

If you already read the post from lakrsool, please disregard that. The fact is, what you suspect is possible -- spammers (and newsletters and even regular users) can put "web bugs" (aka web beacons) in email which is often disguised as an image which can let the sender know that you've opened the email. For spammers, this can legitimize the email address; for newsletters: this is usually just used for statistical analysis to know how many people signed up for the newsletter are opening it.

The reason that the process was changed in v4.5 so that only a single double-click action is required is because I had received a number of complaints about this over the years. If you have AntiJunk, then the old policy (2x double-click) will still be required if the message is evaluated as Junk.

If you still want to follow the same process as before -- where you can view html without the images -- then what I suggest is that you add the "HTML" button to the toolbar (if it's not already there, you can select "View / customize toolbar" from the menu, and then add "HTML"). Instead of double-clicking the banner when it says "double-click to view HTML" you can press the "HTML" button instead. In order for this to work as expected, verify the following:
1) Main menu: Tools / Options
2) Select the "View messages" page
3) Ensure that "block external images and data" is enabled (checkmark'd) and that "process attachments" is disabled (not checkmark'd)

[p45cal]

If you already read the post from lakrsool, please disregard that.

Well, it did raise an eyebrow, and it prompted me to do a little research which confirmed:

The fact is, what you suspect is possible -- spammers (and newsletters and even regular users) can put "web bugs" (aka web beacons) in email which is often disguised as an image which can let the sender know that you've opened the email. For spammers, this can legitimize the email address; for newsletters: this is usually just used for statistical analysis to know how many people signed up for the newsletter are opening it.

It's the 'legitimize the email address' for which I also read: 'verify the email address', that bothers me. I don't want to have to reveal that my email is correct when faced with a totally blank email when viewed in plain text, before I know whether I want to keep the email or not.

The reason that the process was changed in v4.5 so that only a single double-click action is required is because I had received a number of complaints about this over the years.

OK, I can understand that, but it seems it does remove a level of security, which is one of the things I use POP Peeper for; why not instead have that single double-click as the default, but allow people the option configure it to double-click twice as before? It was so simple and straightforward (no mouse movement required between double-clicks) as one assesses whether one wants to keep the email or not.

If you have AntiJunk, then the old policy (2x double-click) will still be required if the message is evaluated as Junk.

I don't think I have; that's a Pro version thing isn't it? So far I've been too much of a skinflint to buy the Pro version! In any event, what if the message hadn't been identified as junk?

In the interim, I may take your advice regarding customising the toolbar, or I may revert to the previous version.

Thank you for responding so clearly.

regards, p45cal

ps. here's the sort of image source that might be doing what I suspect:
https://pixel.monitor1.returnpath.net/pixel.gif?r=3Dc87cac7fe6442cce12c7a618e3df2c2464b5a350
(I don't mind the sender of the message containing the above knowing I've opened their message)

[Jeff]

I'll keep your opinion under advisement and if other people feel the same way then they should let me know. But this change was made with the knowledge that the "html" toolbar button would be an effective substitute. Also discussed with this change was the capability to provide more options directly within the banner (via buttons, drop-down menus, clickable text, etc.) -- but this kind of feature would be in a post-v4.x release.

One other suggestion I can make -- you might try defaulting to using Rich Text instead of Plain Text. Rich text is just as safe as plain text, but it bases its structure on the HTML format of the message. It looks like a complete mess with newsletters that make use of tables, etc. but it usually shows you *something* in the cases where the sender has intentionally obscured the plain text (and, in most cases, when that happens, the message is usually not from a regular person so that can be a clue as to whether the message is legit or not).

[mjs]

If you already read the post from lakrsool, please disregard that.

Well, it did raise an eyebrow, and it prompted me to do a little research which confirmed:

The fact is, what you suspect is possible -- spammers (and newsletters and even regular users) can put "web bugs" (aka web beacons) in email which is often disguised as an image which can let the sender know that you've opened the email. For spammers, this can legitimize the email address; for newsletters: this is usually just used for statistical analysis to know how many people signed up for the newsletter are opening it.

Since I'm still part of the discussion I thought I'd explain the reasoning behind my incorrect conclusion and therefore misleading post. I was thinking in terms of "legitimate" messages which if not "malicious" would of course not have the potential of any of these kinds of malware embedded in the message presumably. There was a reference to a "gif" file and with that in mind I am not aware that the simple "gif" file format can be a potential source of malicious code as is the case with other types of image files which I frankly did not think applied to "gif" files. So clearly my mistake for not thinking in terms of the potential of "malicious" messages, but my personal approach is if I am unable to identify the source of a message then it gets immediately deleted so I was incorrectly limiting my answer to my perspective in the realm of "friendly" or "familiar" messages in which there would be no risk in opening and if I'm not mistaken in these specific cases there would be no way for the sender to know if the recipient had "read" their message or not absent what I referenced in regards to the optional "return receipt". I incorrectly assumed that the concern was whether an innocuous sender would know whether or not their message was opened (read) and not whether a message was maliciously tracking the recipient.

[Jeff]

The specific type of image format could be any of them (gif, png, jpg, etc.); it's the URL being used to fetch the image that's suspicious, just like in the examples that p45cal mentioned.

There is a certain email client (and maybe more than one) which is notorious for using web beacons. Whether they're selling it as a feature to users or using it for their own data collection is debatable. My personal opinion is that if a user agrees (knowingly or not, if they read the license agreement) to use such software or services then that's on them, but when they drag the unwitting recipients of their email into it, that's another. That's just my humble opinion.

[Godiva]

Jeff,

Because of this issue, I have not yet installed v4.5 (I am running v4.4.1). I have several concerns with this change, and will discuss them below. But I am willing to try your HTML button suggestion to see if it works well enough. However:

1. I don't see the HTML button in the 'Customize Toolbar' screen, is this new to v4.5? If not, can you help me troubleshoot how to add the button to v4.4.1? I'd rather try it with my current version before upgrading.
2. If I need to upgrade to v4.5 to add the HTML button, will I be able to easily downgrade to v4.4.1 (or at least v4.4.2 if necessary) if it doesn't behave as I want?

Now on to the discussion!
I also have always liked the two-step approach to retrieving embedded HTML emails for at least four reasons:

1. Security: This has been previously discussed, but is the one that most concerns me.
2. Privacy: I often don't want email senders (mainly commercial ones) knowing when (or even if) I've read their messages. From what I understand (and have read from multiple sources), retrieving the HTML without the images still does not send anything back to the sender, but retrieving the images can inform them that I have read (or at least opened) the message.
3. Avoiding advertisements: This happens a lot with commercial email, I'll give you one specific example - The NY Times weekly 'Personal Tech' newsletter (but this is a common issue I have encountered with many senders): Viewing this email as Text is useless, as RTF it's very hard to read, but as HTML (without images) it gives me usable headlines and clickable links to read the full article online. However, as soon as I also download images, it adds a slew of unrelated advertisements in between the headlines. This makes the email much harder to read and slows down the retrieval of the email. Which leads me to my next point...
4. Speed: Using PopPeeper is my fastest way to retrieve email, even including HTML code doesn't noticeably affect the retrieval speed (and the HTML is often necessary to view a usable message). However, including images can severely affect the retrieval speed (especially when there is other heavy traffic happening).

Evaluating a message as Junk is not always a good solution, since for the reasons b,c & d stated above, legit senders can send me email that I still don't want (or need) to retrieve images from.

I'm sure I will add to this thread as the discussion continues, but I feel the above is a good enough starting point to express my multiple concerns.


On a related note, about a year ago (viewtopic.php?f=3&t=6730#p33592) I brought up the issue of needing to click on the banner multiple (more than 3, often at least 6) times to completely retrieve an entire email with HTML and images. I felt that the 1st click should always retrieve the entire message, the 2nd click should retrieve the HTML, and the 3rd click should retrieve the images. You disagreed, and ended a post with the statement

End result: I think the order is actually good and must be why I made it that way

At that point, I decided to let it go and live with what I still consider an illogical retrieval order (and I can provide several email examples that will demonstrate why I think this). If the new v4.5 banner behavior was created for ease-of-use and was included due to user demands and complaints, be prepared for me to revisit my complaint about retrieval order. You've been warned!

[p45cal]

I don't see the HTML button in the 'Customize Toolbar' screen, is this new to v4.5? If not, can you help me troubleshoot how to add the button to v4.4.1? I'd rather try it with my current version before upgrading.

I think that menu is available while you're viewing a message.

[Godiva]

I think that menu is available while you're viewing a message.

You're right, that works fine, thanks! I've been using PP for so long, I just haven't bothered to change things in quite awhile (if it ain't broke...), so I've forgotten a lot of the settings.

So since I can use the toolbar method to view HTML without downloading images, I'll probably give v4.5 a try. I'll just have to get into a new habit of what I click.

At this point (admittedly without yet playing with it much), I'd suggest the following: Add a "Display Images" button to the set of message toolbar icons and message View submenu (maybe hover & menu-name it to "Retrieve & Display All Images", since that is a more accurate description). That way the user would have total control over the order in which message parts are retrieved (in my case, Retrieve Entire Message first, then HTML, then (optionally) Display Images), and they're all conveniently on the message toolbar.

Also maybe give the user the option to remove the banner line (to reduce accidental clicking on it)? This last change isn't critical, but if I'm going to put all its functions on the message toolbar, then the banner line becomes redundant, and having the option to remove it also makes for a cleaner display.

[Jeff]

I don't see the HTML button in the 'Customize Toolbar' screen, is this new to v4.5? If not, can you help me troubleshoot how to add the button to v4.4.1? I'd rather try it with my current version before upgrading.

It is there in v4.4 and what p45cal said is correct -- you have to be viewing a message to modify the appropriate toolbar. "HTML" will be near the top of the "available" list.

I think I started writing this post last year and in the mean-time, you've posted a new message.

If I need to upgrade to v4.5 to add the HTML button, will I be able to easily downgrade to v4.4.1 (or at least v4.4.2 if necessary) if it doesn't behave as I want?

Yes. As long as you don't enable full-ini file encryption (which you would have to go out of your way to do; it's not something you'd accidentally do and then forget).

Evaluating a message as Junk is not always a good solution, since for the reasons b,c & d stated above, legit senders can send me email that I still don't want (or need) to retrieve images from.

I didn't mean to suggest that as a work-around; I mentioned that as a security-feature. That is: IF POP Peeper evaluates a message as junk, then you will get the extra protection of having to double-click twice in order to view HTML with images.

At that point, I decided to let it go and live with what I still consider an illogical retrieval order

If my statement sounded like the final verdict, then I apologize. I don't normally write 7 paragraphs of text just to end the conversation. I consider myself very open to opinions and if you can convince me to change it, then I will. I'm not going to change something that has been a certain way for a long time unless there's a good reason to, though (that is, all things being equal, I'm more likely to leave it the way it is).

Since this is straying from the original topic, I've thought about suggesting that you resurrect the other topic, but there are several points that I would probably forget so I'm going to mention them now. After re-reading the other topic you linked to, this is why I think that the order (view html/images/retrieve) is "good":
As I mentioned in the other topic, there are reasons why the order may change and it's hard to make a blanket statement to cover all situations. But you specifically mentioned that sometimes you have to retrieve the entire message for the html format to look correct, so I'm going to assume that that implies that you're using POP3 with "preview."

The way that the raw source of an email message is structured usually means that the text portions (plain text and html text) come first, and then the attachments. When you retrieve a POP3 "Preview", POP Peeper requests the first XXX lines of the message. This means that it could stop right in the middle of one of portions of text and it will be incomplete -- this is likely what you're experiencing.

If this happens frequently, then I would suggest increasing the number of lines (and, as I'm thinking about it, perhaps I should increase the default value accordingly). POP Peeper does not use "preview" by default for POP3, but if you change it to preview, it uses 500 lines. The actual length of a line can vary, but standards suggest that the *maximum* length of a line should be 80 characters. So, at worst case, 500 lines x 80 characters = 40KB. Ironically, using preview can often be *slower* than retrieving the entire message because the server has to process the message in the case of preview, whereas with "entire" it doesn't require as much computation.

So, if you still prefer using "preview" over "entire", what number of lines should you use? Ideally, you want to set it at a number where you'll always get the full text. If you have incredibly long conversations with someone (that keep getting quoted), that number is impossible to gauge. But one thing you could do is open the source of several of your email messages (without attachments) and see how many lines it has (assuming you're using a decent text editor that displays that information. I use Notepad++ and it does). Doing this on my own messages (newsletter-type messages), I think that 2000 might be a good number.

Using the formula: 2000lines x 80characters = 160KB. But, again, that's worst case. In actuality, the messages I opened that were pushing >1000 lines were 40-75KB (newsletters are ridiculously inefficient...). Point being: unless you're on a severe data cap, it's probably not something to worry about.

Ugh, I got side-tracked and I almost submitted this without getting to the point -- the reason that "view html" comes before "retrieve entire" is that you may not *need* to "retrieve entire" if you're able to read the HTML. The point you made is that sometimes the HTML isn't formatted correctly, but it might be if you increase the number of lines. So try doing that, and as long as the HTML is formatted correctly (ie. you may need to increase the number of lines), get back to me and let me know if you still think the order should be changed.


And to address some of what you wrote in the last message:
The toolbar buttons "block ext" and "process att" are the equivalent of "display images"
I probably won't add a separate "display image" button as that might just be redundant with changes that will come to the banner anyway. I'll try to keep this discussion in mind when those banner-related changes come so hopefully it will make everyone happy.

[Sentinel]

I agree with OP. I also prefer the old way of having to click twice separately in order to view the images. I almost never showed the images but quite often I had to click once to see it in HTML to see what the heck it was. I very much preferred the ability to see it without showing the images. It seemed a simple task to me to just click it again if I deemed it safe enough.

The reason I use PP as opposed to the other more mainstream email programs is because of security. Other email programs just default to full on HTML and give you little or no choice of anything. I hope that PP doesn't start down that road.

[Godiva]

The toolbar buttons "block ext" and "process att" are the equivalent of "display images"

The hover text description of "Block Ext." says "Remove data from remote servers (HTML)". The use of the word "Remove" sounds destructive (I first tried on an email I didn't care about). Maybe rename the hover text to "Retrieve/Block images from remote servers (HTML)"?

When it's clickable, the "Process Att." button doesn't seem to perform any visible function other than cause the banner line to disappear. I've tried it on various messages, all with the same result. What is this button actually supposed to do? Any suggestions on how to test it to makes its function more obvious?

That said, I agree with you that the Block Ext button (and maybe the Process Att. button) make a "Retrieve Images" button redundant. Maybe for consistency's sake you can also add them to the View menu? But for someone who doesn't know what they are, those button titles are a bit cryptic.

Honestly, with the ability to use the buttons as mentioned in this thread, it now really doesn't matter to me what order you present in the banner line (since I can now use the buttons to always choose the order I want). I'm not saying that to be snippy, but it was just that I always found it a bit annoying to have to click the banner bar 4-6 times to retrieve a complete message on many of my emails (maybe, for some reason my emails are unusual). Now with the buttons, I can choose the order and know that it will never take more than 3 clicks (maybe 4 if I can figure out the Process Att. button! ).

[Jeff]

Ok, thanks for everyone's feedback. Here's what I'm going to propose:
- Please give the new method (of adding and using the "HTML" button to the toolbar) a chance. I know it can be hard to break habit, but this method is actually the way it was before v4.0 (the banner was added in v4.0).

- If you think that this will be the end of humanity, please let me know ASAP and I will try to release a quick patch that disables the new method. Note that by ASAP I mean literally within the next few hours (by tomorrow morning at the absolute latest). My Christmas holiday is starting Wednesday and I will be unable to make changes.

The hover text description of "Block Ext." says "Remove data from remote servers (HTML)". The use of the word "Remove" sounds destructive (I first tried on an email I didn't care about). Maybe rename the hover text to "Retrieve/Block images from remote servers (HTML)"?

Yeah, you're right; probably not the best choice of words. And I've said this before (I don't have a good solution for changing the text, so it hasn't been changed yet), but I hate that the "block ext" and "process att" are similar but the wording is the opposite; that is, the text for each should either be "block" or "allow". e.g. "block remote" and "block attachments" OR "allow remote" and "allow attachments". My hesitation is that "block ext" and "process att" only have meaning if you know what the full description is. But if longer text is used, it makes the buttons look gigantic in proportion to the other buttons... I wish I could show different text in the "customize toolbar" but I don't think I can...

Anyway, rambling again -- "process att" is "process attachments" which will generally display any inline HTML images that have been included as attachments (as opposed to a URL).

Maybe for consistency's sake you can also add them to the View menu?

They're under Options / Html options. Maybe they should be moved to under the 'view' menu...? Let me know what you think.

[Sentinel]

I never realized this before but, for me at least, when looking at an email that is HTML I can just go to the "view" menu and there is an option for HTML. If I click that then it does HTML only with no images. This works fine for me and is just as easy (maybe even easier) than the banner.

So for me I am fine with the way it is now. I usually don't look at HTML, I just simply delete it. But if I get something that is HTML and I have to see what it is before I delete it I can just go to view and click HTML. Nice thing is that in that way you can switch back and forth between plain text and HTML; something I could not do before with the banner, so I actually like it better.

So this change forced me to find some way around which it seems was always there and I like it even better so ... thank you

[Jeff]

Glad to hear that works for you. What you found is essentially what I proposed to the OP with adding the "HTML" button to the toolbar, which should be more convenient than using the menu (you can add "plain text" and "rich text" too, if you want). Here's how in case you missed it:

While viewing a message, from the menu select View / Customize toolbar (or right-click on the toolbar)
Find the appropriate button on the left ("available") and move it to the right ("current")

Also, a pro-tip that not many people know about: you can re-order buttons directly from the toolbar by holding down shift and dragging the button where you want. If you nudge the button, you can add and remove a separator. And you can remove buttons by dragging the button off the toolbar.

[henry66]

i know i am late (as usual) - but then at least i did not spoil jeff's christmas and new years celebrations - so all the best for a happy, fruitful and harmonic 2018.

as to the VIEW HTML issue: i am 1000% (yes, one thousand, i am european, and we have this here) for the old three-step-approach !!!

several reasons: i can usually already tell on step one, only occasionally on step two, if i want or need the mail, or if is deleted right away. and i get some 100+ per day, and on 'good' days, two thirds are nonsense.

also, i am VERY often on very expensive internet lines, counting both time and size. so pure text is the only solution, and one of the major reasons why i use PP rather than going into the full blown internet. which would now also mean i would go back to the older 4.4xx version if i find no better solution. the toolbar solution, and the many workarounds mentioned earlier, seem far to complicated, but also one sided for me - shooting a rabbit with a cannon. the old version was perfect - why change it?

if you ever paid $5 for looking at a fancily desinged letter, with little contents, or $10 for an attachment that just came along (yes, i know, there are ways to block it) - and if this happens several times a day - then you become very careful with all these issues.

greetings - heinz -

[Jeff]

i can usually already tell on step one, only occasionally on step two, if i want or need the mail, or if is deleted right away. and i get some 100+ per day, and on 'good' days, two thirds are nonsense.

hm, strange -- that's the same argument I have for removing the 2-step process...


I highly recommend that you try the toolbar solution; I don't think it's as complicated as it may sound. Besides, there may be other buttons that you find in the list that you may want to use:
While viewing a message, from the menu select View / Customize toolbar (or right-click on the toolbar)
Find the appropriate button ("HTML") on the left ("available") and move it to the right ("current"); you can use double-click or drag&drop

Keep in mind that I designed the original 2-step process with my own interests in mind, but I now think that there are better solutions that work for the entire community. Incidentally, I started working on the replacement last week and it's already functional; I'll post more information in the next post.

[Jeff]

As I mentioned in my previous post, I've been working on the next iteration of the banner. Here's a screenshot of the current progress:

PPv5BannerClickableObjects.png (7.17 KiB) Viewed 7365 times

- This screenshot shows the state of 3 different banners when I clicked on a clickable text
- The red-highlighted text shows what I clicked on to display the subsequent banner (the text highlights red when the mouse is over it, but the mouse cursor wasn't included in these screenshots so you can't see it)

Notes:
- This is not necessarily what the final product will look like. I used text instead of buttons (even though text turned out to require more work) because I thought it looked better, but let me know if you have any suggestions.
- I'm on the fence about what the last banner does. That is, the "Get entire" text when the banner is already "double-click to retrieve entire." One can make the argument that the "Get entire" text should be there for consistency (ie. you can always look on the right to see the available options and essentially ignore the "double-click" action). On the other hand, removing the redundancy would be a cleaner look and cause less confusion (and be aware, avoiding potential confusion is a *very* good reason for doing something). Again, let me know what you think.

[henry66]

similar (or even same related) issue: why do some mssgs show up immediately as HTML with no choice at all? despite using the > "html" toolbar button < ??? and strange too, that button not always shows up (same mssg), but when it does, it is already engaged.

the very same mssgs show up as a pure TEXT mssgs in other readers, and are perfectly readable.

i am really looking forward to an update that solves all this.

greetings - heinz -

[Jeff]

why do some mssgs show up immediately as HTML with no choice at all?

It's because of the "Smart HTML" feature -- if the message is evaluated as legit and the sender is in your whitelist/addrbook, then PP will show the message with full html if available.

and strange too, that button not always shows up (same mssg), but when it does, it is already engaged.

By "that button" are you referring to the "html" button that you've presumably added to the toolbar? Once it's added, the button itself will always be there, but there may be circumstances when the button is disabled. For example -- and this can be a very common occurrence -- if you use Imap and it's set to "preview" (which is the default), then the "html" button may be disabled because "preview" got the plain-text portion of the message and not the html. If you then retrieve the entire message, the "html" button may become available, and whether "html" engages by itself will depend on the "smart html" feature. Also understand that not all messages have an "html" portion (e.g. messages sent from POP Peeper); and some messages *only* have an html portion (e.g. newsletters), in which case POP Peeper will retrieve the html as part of the "preview".

i am really looking forward to an update that solves all this.

Do you think that the options on the banner will directly resolve this? If not, then I ask that you provide suggestions that would resolve it because, right now, the basic system isn't going to change dramatically in v5. I *do* admit UIs are not my strong point and that there is a lack of understanding/information that I'm hoping to address in v5. The previous screenshots only showed the options for the yellow banner, but the AntiJunk (green/red banner) also had some options added to it; one of which is a "help" button (although, while replying to this post, I wrote some additional notes to myself that may help further -- so that "smart html" specifically is mentioned in the text on the banner, which may answer the question of "why was this message displayed in full html when others are not?").

Actually, I have another idea that may help a lot, too..... more on that after I see how feasible/practical it is....