ietf-dkim
[Top] [All Lists]

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

2007-12-05 10:17:17


Pete Resnick wrote:
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.


Well, let's get back to first princples.  RFC 2822 3.6.2:

     "The "Sender:" field specifies the
   mailbox of the agent responsible for the actual transmission of the
   message."

Is a message fully delivered to a mailing list processor, or is the mailing
list processor merely an odd kind of MTA?  I think there is no controversy
that it is fully delivered, with respect to the mail handling service.  This
means that the mailing list does indeed then "post" the message (back) into
the message stream. In the abstract, then, each posting is for a "new" message.

However...

Perhaps the new posting is really exactly the same as the original message,
except for the addressee list, so that the original Sender field value is
semantically valid?  To me, this has the benefit of being the most relevant
question and the detriment of being pretty subjective.  But then, email
identity strings involve a fair amount of subjectivity already, so it's
probably no major burden to have this one (too.)

Perhaps the mailing list has made significant changes to the message.
Certainly taking multiple messages, to produce a digest, qualifies but I think
other changes do, too.  Where is the limit?  I have no idea.  Since the
mailing list and the original author have a cooperative arrangement, I'm happy
to let them decide.

But the key point is that it means that retaining or replacing the Sender value is not a rigid decision. In other words, it *is* a decision that the mailing list operator needs to make explicitly, but the choice entirely depends upon the amount of violence that list software does to messages it re-posts.

As you (Pete) said in a separate conversation, the underlying question is what the Sender address needs to be used for and what will serve that need best.

I don't know that we have much culture around legitimate use of that value, by receivers or downstream handlers.


Section 3.6.6 describes resent headers. One could make a plausible argument that a list should add a Resent-Sender: rather than a Sender: but it's reasonable to do it either way.

Mailing lists using Resent-* fields gives me the willies. Resent-* fields were intended for MUAs resending mail. They weren't intended for mailing lists.

Resent was an entirely reasonable idea, but it is one that proved far more
problematic than beneficial. It works from a simplistic model that seemed like a wonderful idea at the time and, IMO, has since shown to merely add confusion and complexity rather than benefit.

Frankly I think it should be deprecated, because it causes so much trouble.

d/

--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html