Phishing Warning for GRC signup email in ProtonMail

  • SpinRite v6.1 Release #3
    The 3rd release of SpinRite v6.1 is published and may be obtained by all SpinRite v6.0 owners at the SpinRite v6.1 Pre-Release page. (SpinRite will shortly be officially updated to v6.1 so this page will be renamed.) The primary new feature, and the reason for this release, was the discovery of memory problems in some systems that were affecting SpinRite's operation. So SpinRite now incorporates a built-in test of the system's memory. For the full story, please see this page in the "Pre-Release Announcements & Feedback" forum.
  • Be sure to checkout “Tips & Tricks”
    Dear Guest Visitor → Once you register and log-in please checkout the “Tips & Tricks” page for some very handy tips!

  • BootAble – FreeDOS boot testing freeware

    To obtain direct, low-level access to a system's mass storage drives, SpinRite runs under a GRC-customized version of FreeDOS which has been modified to add compatibility with all file systems. In order to run SpinRite it must first be possible to boot FreeDOS.

    GRC's “BootAble” freeware allows anyone to easily create BIOS-bootable media in order to workout and confirm the details of getting a machine to boot FreeDOS through a BIOS. Once the means of doing that has been determined, the media created by SpinRite can be booted and run in the same way.

    The participants here, who have taken the time to share their knowledge and experience, their successes and some frustrations with booting their computers into FreeDOS, have created a valuable knowledgebase which will benefit everyone who follows.

    You may click on the image to the right to obtain your own copy of BootAble. Then use the knowledge and experience documented here to boot your computer(s) into FreeDOS. And please do not hesitate to ask questions – nowhere else can better answers be found.

    (You may permanently close this reminder with the 'X' in the upper right.)


New member
Feb 9, 2021
While signing up, I noticed that the signup "GRC Public Forums - Account confirmation required" email is marked as a possible phishing attempt by ProtonMail, which links to the following page:

The structure of the email HTML seems fairly innocuous, and is fairly simple (standard email clutter of odd whitespace, table formatting, and inline CSS aside):
table > table​
tr > td​
a - GRC Forums title​
tr > td​
p - in order to complete...​
p - confirm button​
tr > td​
div - Visit GRC Public Forums​

So I doubt the HTML itself is the issue. However, when I looked at the export from ProtonMail, I could not see a plain-text multipart section, and the HTML segment appeared to be base64 encoded entirely. If true, this could be what is tripping some filters; I have heard of spammers relying on HTML to mask the nature of their email, so I wonder if there are filters that see the use of HTML-only emails and/or base64 as attempted obfuscation. The multipart structure I see, is

Root: Content-Type: multipart/mixed
Content-Type: mulipart/related
Content-Type: text/html & Content-Transfer-Encoding: base64

A caveat: If I understand correctly, ProtonMail encrypts the contents of emails stored at-rest, so there is a chance that the lack of plain-text and base64 encoding could be the effects of ProtonMail's system, which only interoperates with its webmail, apps, and bridge program, not with email clients directly. If someone else could confirm what the raw email content looks like for them, I would be curious if you can this same multipart structure, or if you can see something else which might be

A privacy warning: If you are not sure what to look for in raw email data and share it here, please be careful about posting full email headers, these can sometimes contain your home/work IP address or your email address in multiple places; if you want to keep either of those private please look over the headers carefully.
I have removed my content
Last edited by a moderator:
Perhaps a stupid question on my part, but if Proton is sending you messages warning that an email might be a phishing attempt, then doesn't that indicate that Proton is reading your mail? Which seems counter to what a private email provider should be doing.

Most, if not all all, email providers scan emails as they come in for virus and spam potential, and to check via SPF/DKIM/DMARC if the server sending them was allowed to. Then they add some form of header to indicate whether or not the email is possibly dangerous. For example, this is what Thunderbird’s Trust junk mail headers set by: ___ option uses.

According to the Mail Servers section of their 2016 whitepaper, ProtonMail processes incoming mail with OpenDKIM, OpenDMARC, ClamAV, and SpamAssassin before encrypting it for delivery to the user. So at most, inbound unencrypted email stays unencrypted for only a moment longer, but I think this is probably necessary to let the spam/virus/phishing prevention systems work correctly. You could in theory push these checks onto the client (webapp, app, bridge), but I imagine that could leave the server more susceptible to DOS attacks, and decrease effectiveness, since the spam/virus/phishing prevention systems system are no longer looking at the original unmodified email as it was received.

Anyway, the phishing warning is then displayed by the client (webmail in my case) where it appears in between the To/From/Subject info and the body of the email. For an example, it looks like the domain authentication warning shown here, but with different text, and a different link. So it is not really a message being sent by ProtonMail, it is probably a flag added by the receiving SMTP server that the web client understands.

A further note on ProtonMail: Since PGP (which ProtonMail is built around) is not normally able to encrypt email headers, and ProtonMail warns that Subject lines and recipient/sender email addresses are not end-to-end encrypted, this means that headers are likely not encrypted. So since the spam/virus/phishing assessment is probably being stored as a header, ProtonMail could theoretically be able see which of your stored emails are potentially spam, but not what the body of those emails contains.
Last edited:
As far as I am concerned it is rarely (if ever) the correct response for a sender to alter the way they send content to make a receiver happy. If your mail server is potentially flagging or blocking messages as malicious when they are not, then you should address your issue to the mail server owner and not to the sender of the emails you receive.
  • Like
Reactions: hyperbole