Re: Corrupted Subject and From header in Amazon.co.uk mail

On Sat, 27 May 2006, Chris Lawrence wrote:

No arguments with that, but what I'm trying to establish is the
actual cause of the gibberish in the headers.

It looks as if they're encoding the subject text (or rather, trying to
encode it and doing it wrongly), even though in this case it contained
only US-ASCII characters and so there was no need to encode it.

RFC2047 (end of section 5):
Use of 'encoded-word's to represent strings of purely ASCII
characters is allowed, but discouraged

It appears that Amazon's mails are not correctly following
standards, and I wasn't aware that headers like Subject and From
were encoded - that makes no sense to me at all,

If they contained 8-bit (i.e non-ascii) characters, they would *have*
to be encoded in this way.

so I feel there's more to it than first seems.

Maybe. I really don't know. Spammers certainly do it in the hope of
slipping past content-based filters - though our content-based filters
award *extra* penalty points for useless encoding, and even more for
broken encoding, over and above the penalty points for the spam
content itself. But, as I say, we were forced to stop treating broken
encoding as grounds in itself for outright rejection.

I feel that I may have to ftp into the mailbox later and download
it, in order to inspect the mail in a text editor to see what it
actually contains.

Amazon.co.uk recommends Michel Thomas Advanced French (CD) and more

I still don't understand how the Subject header contains encoded
text, nor why the From header looks okay with the standard view but
wrong with the header view in Pine.

In the normal view, PINE is refusing to decode the defective subject
header, for the reason we discussed. It *is* decoding the encoded
From: header.

In the full-headers view, the decoding is turned off, by design - so
that you see the headers in their original form.

I agree althought there's room for a more pragmatic approach too -

There are potential security issues with broken headers. Just because
you and I can't exactly see how to achieve a security compromise, does
not mean that it isn't possible. We should be able to draw worthwhile
lessons from a certain vendor, whose sloppy approach to specifications
leads to a continual stream of half-baked fixes, without the
underlying weaknesses ever really being resolved. It's so much safer
to start from a basically secured system. Enforcing mandatory
requirements of the specifications is certainly defensible as a
component of such an approach, IMNSHO.

When Postel said "be liberal in what you accept", I'm confident that
being tolerant of clear violations of mandatory requirements was NOT
what he had in mind.

Pine could adhere to the standards itself but be more generous in
accepting the flaws of other clients.

It could; but I'd prefer it if the others would tighten up their
behaviour instead.

There's a certain school of thought that a mail client could alert the
user to the fact that there's a defect in the mail, and offer to try
some kind of a fixup if the user consents to any security compromise
which might result. But, to be realistic, many users would have no
basis for deciding one way or the other in response to such an alert;
and maybe those who have the competence to decide, would also have no
difficulty in applying their own workaround if they wanted to.

I'm simply trying to identify exactly what it going wrong with those
messages so I can relay it to Amazon, for all the good it may do.

"for all the good it may do", indeed. Most commercial enterprises
would tell you to abandon the Internet-conforming software that you
use, and throw yourself open to anything that the commercial software
would force-feed you. And as long as they have an apparently endless
stream of sucker^W uncomplaining customers, why *would* they be
interested in spending time and effort with a few people who know what
they're doing and who are trying to stick up for standards?

all the best
.

Relevant Pages

  • Re: HTTP Request, character encoding and fsockopen
    ... You could try using HTTP/1.0 or simply leaving off the HTTP version. ... which is the encoding you're seeing. ... send a regular GET header without any specific HTTP headers regarding ... alphanumeric characters, ...
    (comp.lang.php)
  • Re: The word "rasismi" in Finnish (was Re: unnatural languages)
    ... as the default encoding for this ng, but perhaps that was a mistake. ... everyone using UTF-8 has an appropriate line in their headers, ... explicit encoding header line if I am in a default mode. ... usually change the View/Encoding to Unicode ...
    (sci.lang)
  • Re: problems with messages FROM GroupWise users
    ... The issue is in the encoding, not the decoding (Groupwise) ... with all the internet headers in the body of the message and the ... My users are running Outlook 2003, and we have Exchange 2003. ... patch breaking some of the base64 encoding on the Exchange side. ...
    (microsoft.public.outlook)
  • Re: [Gravity] Send 8 bit chars doesnt work *anymore*
    ... Sending posts is not critical since I don't use any specific ... Sending (encoding) and reading are two different things. ... Reading should be based on the headers of the post you are reading, ... If there are no headers I assume gravity maps the characters to the ...
    (news.software.readers)
  • Re: mail charset in subject and body [bds2006+indy10]
    ... Because while you can encode the _body_ of the email any way you ... in the _headers_. ... of what the encoding is. ... Maarten Wiltink ...
    (comp.lang.pascal.delphi.misc)
Loading