Discussion:
Meaning of 'Removing quoted-printable artifacts' ?
(too old to reply)
Mike Easter
2008-05-26 16:09:46 UTC
Permalink
Data for thread "Re: Meaning of 'Removing quoted-printable artifacts'
?" in NG Spamcop
Your newsreader made a uue attachment out of that instead of an
unencoded mime plaintext.

I'm not familiar with that version. On my OE, the uue is
configured/unconfigured in

OE/ Tools/ Options/ Send tab/ News sending format/ Plaintext settings
button/ Message format - check MIME not uuencode and Encode text using
None

The uue situation changes/clouds/obfuscates the issue about the original
7bit.

--
Mike Easter
kibitzer, not SC admin
Michael R N Dolbear
2008-05-27 01:02:23 UTC
Permalink
Post by Mike Easter
Data for thread "Re: Meaning of 'Removing quoted-printable
artifacts'
Post by Mike Easter
?" in NG Spamcop
Your newsreader made a uue attachment out of that instead of an
unencoded mime plaintext.
Much the same for me.

I do very little attached in NNTP so that setting went unnoticed

Trying again
--
Mike D
Mike Easter
2008-05-27 03:12:11 UTC
Permalink
Post by Mike Easter
Mike Easter
Post by Mike Easter
Your newsreader made a uue attachment out of that instead of an
unencoded mime plaintext.
Trying again
Hmmm. Somehow the advice I gave you about copying the source and making
a text file out of it is eliminating the extended ascii. That is, there
are no non-7bit characters in the attachment that were seen in the 'show
entire message' of the parse. They have been 'lost'.

However, there are plenty of 'quoted-printable' artifacts in this
attachment spammessage's spambody which are in this case lines ending
with '=20'

Strangely, the 'dropping' of the 8bit chars in this attachment spambody
is also associated with dropping some 7bit characters which follow the
8bits, so there are a lot of 'errors' or missing letters from this
attachment's content compared to what was at the tracker .

On top of /that/ curiosity, there is a lot of quoted printable character
handling seen here in this attachment in those headers which spamcop
added, so that diverts my suspicion about the QP arttifacts from 'silly
spammer behavior' in the spambody to something more fundamental, some
other discrepancy, but I don't understand what is going on. That is, I
suspect something between you and your spamcop mailbox.

You are showing me headers stamped by spamcop which contain quoted
printable 'artificacts'.

Explain to me how you use spamcop. This particular item was whitelisted
so it had to get/ be put/ into the spamcop parser somehow.

Also, presumably part of your mungeing must involve replacing some
domainname in the attachment here with qqqqqq.com and some address with
<yyy> because the headers show the qqqqqq.com domainname was
whitelisted. Nevermind about the qqqqqqq, I know what that is. I don't
need to know anything about what the munged values are, just what was
munged. qqqqqqq is munged and yyy is munged.

I'm wondering if something about the way you 'feed' the item from
nonblocked to the parser is introducing quoted printable encoding. And
I'm wondering if the 'tool' or editor you used to copy the source of
this message for saving to a txt file was responsible for losing the
8bit chars in the attachment.

--
Mike Easter
kibitzer, not SC admin
Michael R N Dolbear
2008-05-27 22:14:48 UTC
Permalink
Post by Mike Easter
Post by Mike Easter
Mike Easter
Trying again
Hmmm. Somehow the advice I gave you about copying the source and making
a text file out of it is eliminating the extended ascii. That is, there
are no non-7bit characters in the attachment that were seen in the 'show
entire message' of the parse. They have been 'lost'.
However, there are plenty of 'quoted-printable' artifacts in this
attachment spammessage's spambody which are in this case lines ending
with '=20'
Strangely, the 'dropping' of the 8bit chars in this attachment
spambody
Post by Mike Easter
is also associated with dropping some 7bit characters which follow the
8bits, so there are a lot of 'errors' or missing letters from this
attachment's content compared to what was at the tracker .
On top of /that/ curiosity, there is a lot of quoted printable
character
Post by Mike Easter
handling seen here in this attachment in those headers which spamcop
added, so that diverts my suspicion about the QP arttifacts from 'silly
spammer behavior' in the spambody to something more fundamental, some
other discrepancy, but I don't understand what is going on. That is, I
suspect something between you and your spamcop mailbox.
You are showing me headers stamped by spamcop which contain quoted
printable 'artificacts'.
Explain to me how you use spamcop. This particular item was
whitelisted
Post by Mike Easter
so it had to get/ be put/ into the spamcop parser somehow.
It was whitelisted so arrived in SC Webmail Inbox. In my browser I
copied it to my Leaked Spam folder and then moved it to the Held
folder, switched to the VER (report held) URL and ordered it queued for
reporting, switched to the Report Spam URL and clicked on Report Now.
Post by Mike Easter
Also, presumably part of your mungeing must involve replacing some
domainname in the attachment here with qqqqqq.com and some address with
<yyy> because the headers show the qqqqqq.com domainname was
whitelisted. Nevermind about the qqqqqqq, I know what that is. I don't
need to know anything about what the munged values are, just what was
munged. qqqqqqq is munged and yyy is munged.
I'm wondering if something about the way you 'feed' the item from
nonblocked to the parser is introducing quoted printable encoding.
And
Post by Mike Easter
I'm wondering if the 'tool' or editor you used to copy the source of
this message for saving to a txt file was responsible for losing the
8bit chars in the attachment.
Previous time I used my browser and SC Webmail to view the spam email
then clicked on SC Webmail's Message Source. I then copy/pasted to
Notepad and later used Notepad to munge. repeated qqq xxx and yyyyy are
all the munging.

This time I copied the spam back to the Webmail Inbox and POP to my
mail client then Save As to eml, rename as txt and munge
--
Mike D
Mike Easter
2008-05-28 16:05:32 UTC
Permalink
<my cite>
Post by Mike Easter
You are showing me headers stamped by spamcop which contain quoted
printable 'artificacts'.
Explain to me how you use spamcop. This particular item was
whitelisted so it had to get/ be put/ into the spamcop parser somehow.
It was whitelisted so arrived in SC Webmail Inbox. In my browser I
copied it to my Leaked Spam folder and then moved it to the Held
folder, switched to the VER (report held) URL and ordered it queued for
reporting, switched to the Report Spam URL and clicked on Report Now.
I've never had a SC mail account, so I don't exactly know what kinds of
mechanics are going on there. If I were to copy an item from either of my
webmail accounts, gmail or earthlink, from one folder to another, I'm sure
the process would not result in the introduction of any 'spurious'
encoding such as previously non-existent QP quoted-printable nor would it
result in the loss of any extended ascii characters such as dropping 8bit
characters and some of the 7bit chars which follow them.
Post by Mike Easter
I'm wondering if something about the way you 'feed' the item from
nonblocked to the parser is introducing quoted printable encoding. And
I'm wondering if the 'tool' or editor you used to copy the source of
this message for saving to a txt file was responsible for losing the
8bit chars in the attachment.
Previous time I used my browser and SC Webmail to view the spam email
then clicked on SC Webmail's Message Source. I then copy/pasted to
Notepad and later used Notepad to munge. repeated qqq xxx and yyyyy are
all the munging.
I don't think I've lost any 8bit chars when handling something with
NotePad, which I use very often. I would be curious if you were to repeat
that operation just for the purposes of viewing to see if you can see the
8bit characters in the spambody while the body is in NotePad. The 8bit
items consist of the c cedilla instead of c in the word 'Pharmacyy' at the
top, the 2nd 'a' acute in the line 'Sexual Health', and 3 chars in the
line 'Antii Anxiety' 1st n tilde, 1st i diaresis, and 2nd cap A diaresis.
This time I copied the spam back to the Webmail Inbox and POP to my
mail client then Save As to eml, rename as txt and munge.
And/But this attachment introduces QP by your newsagent which is
configured for QP quoted-printable as indicated by this transfer encoding
statement which can be found in your newsmessages properties source:

Content-Transfer-Encoding: quoted-printable

I'm puzzled about how that came about. Your news message itself does not
carry the QP encoding in the headers, and the/your message I'm replying to
here consists of 3 mime parts. The first mime boundary delimited part
after the message headers which announce mime multipart is the mime
announcement of parts. The 2nd mime boundary delimited part is your news
message body itself, and the 3rd mime boundary delimited part is a QP
announced QPed spamitem consisting of its headers and spambody, which
spambody is complete with the 8bit chars and the QP artifacts.

I had no idea this issue was going to be so complicated. I think we are
at a distinct disadvantage by your using a very primitive newsagent with
which I am completely unfamiliar.

I suspect that this attachment is most like what was to be seen in the
source in your SC mailbox, but it is not possible to comment on your
original issue about the QP because your newsagent attached the spamitem
(which I was expecting to find as a 'simple' 8bit text item) as a QP
attachment and the original issue is about where did the QP come from in
the parsed item.

At least the 8bit business was retained in this attachment.


--
Mike Easter
kibitzer, not SC admin
Michael R N Dolbear
2008-05-28 22:22:12 UTC
Permalink
Post by Mike Easter
I suspect that this attachment is most like what was to be seen in the
source in your SC mailbox, but it is not possible to comment on your
original issue about the QP because your newsagent attached the spamitem
(which I was expecting to find as a 'simple' 8bit text item) as a QP
attachment and the original issue is about where did the QP come from in
the parsed item.
At least the 8bit business was retained in this attachment.
I downloaded the attachment and a file compare (FC in DOS) said it was identical to the upload.

I attach a base64 version which is the only other likely option ('none', quoted printable, base64)

--
Mike D

Loading...