[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MIME and "weird" conversions (TAB -> =09)
Matti Aarnio writes:
> > > =09Sure, but Solaris 2.3 diff doesn't have those switches..
> > > =09(Now I installed there GNU diff, so I could do it..)
> >
> > Is converting TABs to =09 desired behavior?
>
>
> Yes, if you had looked wider, you would have noticed some other
> QP-coded characters on (most likely) Matthias Ulrichs signature.
> Even one such 8-bit character will cause QP encoding, when the
> message is transferred to non-8-bit-transparent MTAs.
> (Isn't the MIME lovely ?)
I do understand your point in general, but encoding of _TABs_ looks
oddly to me, and is not required by RFC 1341 in that particular case.
-1341- 5.1 Quoted-Printable Content-Transfer-Encoding
[skipped]
-1341- Rule #3: (White Space): Octets with values of 9 and 32
-1341- MAY be represented as ASCII TAB (HT) and SPACE
-1341- characters, respectively, but MUST NOT be so
-1341- represented at the end of an encoded line. Any TAB (HT)
-1341- or SPACE characters on an encoded line MUST thus be
-1341- followed on that line by a printable character. In
-1341- particular, an "=" at the end of an encoded line,
-1341- indicating a soft line break (see rule #5) may follow
-1341- one or more TAB (HT) or SPACE characters. It follows
-1341- that an octet with value 9 or 32 appearing at the end
-1341- of an encoded line must be represented according to
-1341- Rule #1. This rule is necessary because some MTAs
-1341- (Message Transport Agents, programs which transport
-1341- messages from one user to another, or perform a part of
-1341- such transfers) are known to pad lines of text with
-1341- SPACEs, and others are known to remove "white space"
-1341- characters from the end of a line. Therefore, when
-1341- decoding a Quoted-Printable body, any trailing white
-1341- space on a line must be deleted, as it will necessarily
-1341- have been added by intermediate transport agents.
-1341-
> I am curious, how do you solve the 8-bit character problem in the
> Russian ? "Just-send-8-bit" or are there any plans to jump to the
> MIME-bandvagon ?
For now, "just-send-8-bit". There is some software using
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=koi8-r
but it is still not in common usage.
And SMTP-servers...
...neither sendmail 5.65, nor 8.6.x commonly used here implement
8BITMIME, so they just quietly send and accept 8-bit mail.
Just as anywhere else, I believe. Is your version of Zmailer the only
8BITMIME-capable software now?
--
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Joint stock company "GVC Energeticy", North-Caucasian Branch, Pyatigorsk
Andrew Petrovich Kokarev, postmaster andrew@skfgvc.pyatigorsk.su