Pete Resnick wrote:
[Apologies for duplicates, if any. List issues and decided to Cc
ietf-822 and ietf-smtp.]
On 12/1/07 at 3:30 PM +0000, John Levine wrote:
RFC 2822 section 3.6.2 describes originator fields. By my reading it
is pretty clear that a list should add a Sender: field with the list's
name since it's the list that's sending the mail.
Uh.....not by my reading. Lists add List-* fields (RFC 2369, RFC 2919)
if they want to indicate something. Fields in the original message
should be preserved as-is.
Unfortunately, that is not the common practice by many MLS (Mail List
Server) systems.
Both Sender: and Reply-To: are quite often changed.
The practice is to match the Sender with the Return-path or more
specifically who was the x821.Mail From address. That why it works for
MUA users in the first place and naturally falls in line when a mailing
list owner redistributed the mail.
The problem of course, we have complicated the 1 to 1 email system into
a 1 to Many group ware, conferencing system and there are all kinds of
considerations here. It is not a simple CC concept and its not a old
school SMTP level group list forwarding concept where we don't have a
full blown, feature rich separate but integrated List Server products
out there.
You also have the school of thought that once an "Conference Message",
and that is what it really is, reaches the final destination/delivery,
only the message and TO: FROM: SUBJECT and DATE: is "copyrighted" by the
user. The transparent network control header trace lines are no longer
his business. That is a long time deeply held practice across different
mail networks.
But if the concern is the Sender: header will be replaced a MLS, thats
really a small potato in the big barrel of many other common MLS common
optional offerings:
- Sender: replacement
- Reply-To:
- MIME, HTML, Attachments stripping
- Footers and quite possibly headers
- Message Wrapping with HTML FRAME, IF RAME or DIV tags
- Digest Consolations
what else?
To me, DKIM needs to conform with what exist. Not the other way around.
Of course, we can make changes to our MLS systems to help make DKIM
work better, but the idea that we will be eliminating long establish
ideas like above, is probably a little unrealistic, not going to happen.
The better idea is for the new system (DKIM signer) to have better
knowledge of where it is sending its mail and do not sign headers that
are very likely to change. This is indicated in RFC 4871 as one of many
possible strategies in deciding which headers to sign. Thats the more
realistic approach to this issue.
Of course, my opinion.
--
Hector Santos, CTO
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html