Re: Mailing lists as 2822-Sender (was: Responsibility vs. Validity)

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