Exact match. Not showing close matches.
'[OT]: [ADMIN] Attachment problems go bye-bye (I ho'
|part 1 1538 bytes content-type:text/plain; charset=us-ascii (decoded quoted-printable)
William Chops Westfield wrote:
> However, after reading over the RFC delineating the Quoted-Printable
> encoding, there is still the possibility of the same problem reoccuring due
> to a regular message. It seems the Q-P encoding is extremely fragile.
> > I was thinking it was only a problem because the list server was appending
> non-QP compatible text on a message that was mime-tagged as using QP
> formatting. A message originating on a non-QP system may contain "invalid"
> "=" constructs, but it won't be tagged as being QP-format in the first
> place, either. So things should be OK?
Uhh ... I think so. Basically it should be fixed, but I can't guarantee
that something like some code snippets or an alogrithm explanation won't
still trip this problem in the future.
One of the "fun" things to be dealt with here is the possibility that the
message might not be *sent* as Q-P, but one of the transfer points might
change it to be Q-P. I've seen a few times my ISP has done this. No, I'm
*not* pleased with that.
As near as I can tell I've done what can be done as far as list config. I
suppose only time will tell as to whether it really is fixed or not.
-- Mike Werner KA8YSD | He that is slow to believe anything and
| everything is of great understanding,
'91 GS500E | for belief in one false principle is the
Morgantown WV | beginning of all unwisdom.
part 2 233 bytes content-type:application/pgp-signature (decode)
part 3 136 bytes
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email mitvma.mit.edu with SET PICList DIGEST in the body listserv
|>>> However, after reading over the RFC delineating the Quoted-Printable
>>> encoding, there is still the possibility of the same problem reoccuring
>>> due to a regular message. It seems the Q-P encoding is extremely fragile.
I disagree. But then I commute to work with one of the MIME
Without quoted-printable, any email message containing 8-bit
characters must be encoded. Originally, the only mechanism for
this was Base 64. This turns an entire text part, even if it
only contained 1 character with the high bit set (such as an
accented character in a signature line), into an effectively
human unreadable opaque blob.
Quoted-printable was introduced to rectify this. With Q-P
encoding, that same text message would still be primarily
human readable text with a couple embedded encoded characters.
If the transfer point properly converts the message part into
quoted-printable, then all existing equal signs ('=') are encoded.
In the above example, the input string "=3D" becomes "=3D3D" after
the quoted-printable encoding. Later, when decoded, it reverts to
the original "=3D" string. As part of the conversion process, the
message part is tagged with "content-encoding: quoted-printable".
Now if the transfer point does _not_ encode the message part, but
simply tags it with a "content-encoding: quoted-printable" line,
then the transfer point software is broken. It is not compliant
with the RFCs. It needs to be replaced or fixed. Period.
In other words, any time software tags an object as having a
specific encoding, such as quoted printable, when that object
is not encoded, then the software is broken.
Hopefully, you can coerce the list software to do the right
http://www.piclist.com hint: To leave the PICList
More... (looser matching)
- Last day of these posts
- In 2000
, 2001 only
- New search...