[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