duplicate header fields (was: MIME support (composing MIME messages))

duplicate header fields (was: MIME support (composing MIME messages))

Post by Steven D. Majewsk » Wed, 14 Sep 1994 11:05:49



[ This is cc-ed to comp.mail.mime and comp.mail.headers - to cut to the
  chase and ignore the followup part of this thread, the question is:
  What is the interpretation of duplicate, but different headers ?  
  in this instance, two different Content-Type: field values.  ]


> Apologies to everyone who is getting tired of seeing the same message from
> Steve... The last posting was an unexpected side-effect of me Resending
> the message to myself, and not realizing that the msg already contained a
> Resent-To: pine-info...

Also, some folks may have been confused by some references I made to a
malformed MIME message I sent out. It seems to have gone out on the
mailing list, but it looks like it was dropped from News distribution.

Quote:> (This is arguably a bug in either sendmail or Pine, but it may be tough to
> fix, since I don't think RFC822 specifies any significance to header
> ordering.)

I was sure I recalled some mention in rfc1521 about how to interpret
multiple occurrences of the same header. But searching thru the document,
I can't find any such note. Just my overactive imagination ?
( I also failed to find a note on this in 822, but I only skipped thru
them both quicky, and tried searching for "duplicate" and a half dozen
other likely words. )

Is there a rule to resolve the interpretation of:

Content-Type: TEXT/PLAIN
Content-Type: MULTIPART/MESSAGE

since it is possible to generate duplicate fields with Pine, and
I expect with other mail software ( especially automatic gateways,
remailers, etc. ). Or is this defined as illegal ? Or is it just
undefined ?

Except for the cases where it manufactured the malformed
Content-Type: header lines, Pine appears to use the first
occurence and ignore later ones.

I was also seem to have acquired the folk belief that *all* To:'s
are significant, but I expect that I'm just overgeneralizing some
past experience with sendmail.  :-)


- UVA Department of Molecular Physiology and Biological Physics

 
 
 

1. MIME support -- how to detect a MIME message

MH seems to detect MIME messages based on the existence of the
Content-Type field.  I sometimes get mail that uses some odd, old
encoding that is not MIME, but that *does* have a Content-Type field.
MHN barfs on the mail because it attempts to parse the Content-Type
field based on rules that (I presume) are defined in the MIME RFC.

Here's my question: if MHN is only going to support MIME (which makes
sense), shouldn't it check for the existence of a MIME-Version header
instead of a Content-Type header?

What would be "really nice" is the ability to use MHN for MIME messages and
to specify an alternate "viewer" for messages with a Content-Type,
but no MIME-Version.

Thanks,
Neil

p.s. -- here's my current MH setup in case I'm just behind the times:

version: MH 6.8 #16[UCI]  (daedalus.dcrt.nih.gov) of Mon Sep 13 13:41:45 EDT 1993
options: [ATHENA] [ATTVIBUG] [BIND] [BPOP] [BSD42] [BSD43] [FCNTL]
         [FOLDPROT='"0711"'] [MHE] [MHRC] [MIME] [MSGPROT='"0600"']
         [NNTP] [NTOHLSWAP] [OVERHEAD] [POP] [RENAME] [RPATHS] [SENDMTS]
         [SUN40] [SUN41] [TYPESIG=int] [UNISTD] [VSPRINTF] [ZONEINFO]

--

Nat'l Insts. of Health, 12A/2033         UUCP:     ...!uunet!nih-csl!weisen
Bethesda, MD  20892                      Voice:    301/402-4030

2. IOCTL in AVStrm on WinXP

3. mime-rt.el - Richtext composition aide for mime-compose.el

4. No Access to share on a NT4 box (Domain Member)

5. repl in MIME format to a MIME message?

6. Problems with emx 0.8 / gcc 2.5.4

7. Composing MIME Messages

8. Calling a Roaming Cellular Customer

9. composing MIME messages

10. Fixed MIME Content-Type header field (possible attack)

11. nmh and MIME support in mail headers

12. Viewing a message's headers if message has funky MIME-Type

13. Access by MIME Message-ID field ?