John R. Levine wrote:
> So here's a 0th cut at a list of headers where we should recommend
> N+1 entries in the h=
>
> rfc 5322
>
> From
> Sender
> Reply-To (maybe not, since often smashed by mailing lists)
> To
> Cc (not Bcc even though it's 0/1)
> Message-ID
> Subject
> Date
>
> rfc 4021
>
> MIME-Version
> Content-Type
I would focus on the main rendering items, the ones common across the
mail universe of devices, gated systems, etc.
From: required by 822/2822/5322
Date: required by 822/2822/5322
Subject: optional 822/2822/5322
To: required by 822, optional 2822/5322
The others are related to Network Control Lines and are generally
hidden and only the ones necessary for a "reply" (if different than
the From) may be kludged in. I know this is old school but it still
applies today.
Many systems do a "Valid Header" check in order to see if a header
block needs to be generated. This is what allows a human or simple
mail bot (print, fax job, etc) to enter no headers in a DATA state and
still get mail through because the fields can be filled:
From: <--- 5321.MAIL FROM
To: <--- 5321.RCPT TO
Date: <--- Local Computer Timestamp
Subject: <--- left blank or filled with (NO SUBJECT)
That said....
I don't see incentives to spoof:
Message-ID
MIME-Version
Content-Type
What are the gains?
The Sender: can change too, like in a list.
Not sure about CC: I guess it should be included.
I think for 4871bis, we should keep it simple with focusing on the
main security hole, 5322.From (and also make a statement that
regarding RFC5322).
--
HLS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
