home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / mail / mime / 119 < prev    next >
Encoding:
Internet Message Format  |  1993-01-12  |  3.2 KB
  1. Path: sparky!uunet!pipex!bnr.co.uk!uknet!gdt!aber!fronta.aber.ac.uk!pcg
  2. From: pcg@aber.ac.uk (Piercarlo Grandi)
  3. Newsgroups: comp.mail.mime
  4. Subject: Re: Using MIME without extra mail headers
  5. Message-ID: <PCG.93Jan13022930@decb.aber.ac.uk>
  6. Date: 13 Jan 93 02:29:30 GMT
  7. References: <1993Jan7.191810.1857@infodev.cam.ac.uk> <wBk7wB2w165w@blues.kk.sub.org>
  8. Sender: news@aber.ac.uk (USENET news service)
  9. Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
  10. Organization: Prifysgol Cymru, Aberystwyth
  11. Lines: 60
  12. In-Reply-To: kosta@blues.kk.sub.org's message of 10 Jan 93 21: 31:55 GMT
  13. Nntp-Posting-Host: decb.aber.ac.uk
  14.  
  15. On 10 Jan 93 21:31:55 GMT, kosta@blues.kk.sub.org (Kosta Kostis) said:
  16.  
  17. kosta> (Alasdair Grant) writes:
  18.  
  19. Alasdair> Is there any convention for transmitting MIME messages if
  20. Alasdair> extra mail headers (Content-Type etc.) cannot be used for one
  21. Alasdair> reason or another?  Do any mailers understand messages whose
  22. Alasdair> first (text) line begins "MIME-Version..." or something?
  23.  
  24. Good question, and good subsequent discussion. In particular I agree
  25. with your idea that MIME can be used outside RFC based mail, for non RFC
  26. based mail, or indeed for any sort of document encoding.
  27.  
  28. kosta> The MIME-headers should be in the headers only.
  29.  
  30. Is is so difficult to contemplate that this is not an option in some
  31. mail systems, which are *not* RFC based, and have nothing to do with the
  32. Internet? The Internet is large, but it is only one of many mail
  33. domains.
  34.  
  35. kosta> Well, "my ideal" MTA would only analyse the headers of a message
  36. kosta> needed for routing (if at all), transfer everything without
  37. kosta> changing any bit (except adding "Received"-lines perhaps) and
  38. kosta> forward the message to next next MTA on the way to the
  39. kosta> receipient.
  40.  
  41. Within the Internet this is (barely) possible; within other mail systems
  42. it is not. All they undertake is to deliver message bodies.
  43.  
  44. kosta> It's the MUA's job to interpret the content of the message, only,
  45. kosta> but the MUA must know about the encoding used and stuff like
  46. kosta> that.
  47.  
  48. kosta> but you'll have to tell your MUA manually to convert the message,
  49. kosta> if at all possible. It's like using uuencode/uudecode.
  50.  
  51. What about defining an in-band, very obvious, "magic string", sort of
  52. cookie, that says to a MUA (or to *any* file manipulation program), that
  53. 'hey this is a MIME thingie'? Then cookie aware MUAs can apply metamail
  54. or whatever MIMEry automagically, even if it is impossible to tag the
  55. message envelope appropriately or even if there is no envelope.
  56.  
  57. As long as the cookie is *standard*, and damn unlikely to occur as part
  58. of "normal" text.
  59.  
  60. There ought to be an option within the MUA/file viewer with three
  61. values:
  62.  
  63.   CHECK:    ask every time if the file should be MIMEd.
  64.   ALWAYS:    MIME the file every time there is a MIME cookie.
  65.   NEVER:    don't MIME the file even if there is a MIME cookie.
  66.  
  67. kosta> What's your problem changing header lines? Maybe we can help you
  68. kosta> to do this somehow.
  69.  
  70. Often this is not an option. Some mail systems have fixed headers.
  71. --
  72. Piercarlo Grandi, Dept of CS, PC/UW@Aberystwyth <pcg@aber.ac.uk>
  73.   E l'italiano cantava, cantava. E le sue disperate invocazioni giunsero
  74.   alle orecchie del suo divino protettore, il dio della barzelletta
  75.