[Top] [All Lists]

Re: [ietf-dkim] Mailing lists as 2822-Sender (was: Responsibility vs. Validity)

2007-12-04 18:23:13
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

NOTE WELL: This list operates according to