I've got a problem with Webmail currently. I'm getting legitimate emails from a major company that has the following form (in raw header):
X-spam-Level: *****
X-spam-Status: hits=5.6 tests=MIME_BASE64_TEXT,SUBJECT_NEEDS_ENCODING,
SUBJ_ILLEGAL_CHARS version=3.2.4
Subject: Company® Our Product® - 2nd Notification


I've stripped out everything else from the raw header. I'm guessing the embedded copyright symbols are freaking out Webmail. The problem is that in the folder view the Subject column is completely blank for that message. Ergo, I can't easily click a link to go to that message. Ideally, Webmail would be either stripping invalid characters or replacing them with some black square character or something.

Is there a good reason to not allow these characters in subject lines in the folder view?

Which actually hampers anyone else trying to take alook at what's going on .... especially with reference to the X-line data that you did provide.

Without seeing the whole header set, this is a bit if a waste of time.

For example; You make no mention of your location. You offer no clue as to the location of the sender. You make no mention of your OS and browser. So, it's hard to guess if there's a character-set issue involved just at that point.

Without seeing the whole e-mail (Tracking URL comes up yet again) it's hard to guess at the rest of the actual configuration and contents of the header that might )or might not) explain the X-line data complaints.

Per the RFC's, all characters in the header need to be represented by US-ASCII characters 1-127.

http://www.faqs.org/rfcs/rfc2822.html

2.1. General Description

At the most basic level, a message is a series of characters. A
message that is conformant with this standard is comprised of
characters with values in the range 1 through 127 and interpreted as
US-ASCII characters [ASCII]. For brevity, this document sometimes
refers to this range of characters as simply "US-ASCII characters".

Note: This standard specifies that messages are made up of characters
in the US-ASCII range of 1 through 127. There are other documents,
specifically the MIME document series [RFC2045, RFC2046, RFC2047,
RFC2048, RFC2049], that extend this standard to allow for values
outside of that range. Discussion of those mechanisms is not within
the scope of this standard.


http://www.faqs.org/rfcs/rfc2047.html says:

1. Introduction
...
When the term "ASCII" appears in this memo, it refers to the "7-Bit
American Standard Code for Information Interchange", ANSI X3.4-1986.
The MIME charset name for this character set is "US-ASCII". When not
specifically referring to the MIME charset name, this document uses
the term "ASCII", both for brevity and for consistency with RFC 822.
However, implementors are warned that the character set name must be
spelled "US-ASCII" in MIME message and body part headers.

This memo specifies a protocol for the representation of non-ASCII
text in message headers. It specifically DOES NOT define any
translation between "8-bit headers" and pure ASCII headers, nor is
any such translation assumed to be possible.

So, unless your ® was actually presented as something like: =?iso-8859-1?q?this is some text?=, it was in fact using illegal characters.

SpamCop is very strict when it comes to RFC's, otherwise unintended things can happen.

I found a workaround for you. I just injected a message into my own SpamCop email account with exactly the same Subject line you quoted to us (using the "registered" marks, but not encoding the Subject). I got the same behavior in the webmail, where there wasn't any clickable Subject displayed, but if you check the box to the left of the desired item(s), you can then click on the "View Messages" link just above the message index ("Delete | Forward | Report as spam | View Messages") and you'll be able to view the defective email messages. Problem solved....well, actually the best solution would be for you to contact the dummies at the "major company" and tell them that they need to change the way they're sending out email messages.

DT

[on edit] A quick followup....I just "took delivery" of my test message and checked the headers:

X-spam-Level: **
X-spam-Status: hits=2.8 tests=SUBJECT_NEEDS_ENCODING,SUBJ_ILLEGAL_CHARS
version=3.2.4

The bad Subject therefore only accounts for 2.8 out of the 5.6 score on your problem message. A score that high would result in a trip into my Held mail, unless I had previously whitelisted the sender. The higher score on your message was due to the use of Base 64 encoding in the body of the message you received. I just did a search on the 1615 messages currently in my Inbox and only *three* of them used base64 encoding for the actual message body (text), and they're all from the same little (misguided) company (and they all wound up in my Held mail initially). Message attachments, OTOH, are often encoded in base64, but not the bodies of messages.

My point is....nobody (with any brains) uses base64 encoding in email bodies any more. You ought to share that with the "major company" (and I'm really beginning have some doubts about just how "major" they are, given these "major" flaws in their technical practices).

Thanks for the info. I'll go beat up on the company. Yes they are major (one of the largest financial companies in the U.S., whatever that is worth in the current crisis).

Good for you, good luck. One supposes they will be somewhat distracted at the moment - on the other hand they should have a fair amount of spare capacity in their lending department.