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

From: Pete Resnick <[email-masked]>
Date: Tue, 4 Dec 2007 15:52:16 -0800

[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.

>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.

pr
--
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: [email-masked]
Date: Tue, 04 Dec 2007 16:27:55 -0800 (PST)

> fields were intended for MUAs resending mail. They weren't intended

Rathole alert.

The question of what mailing lists should or should not do to message headers
in general and originator fields in particular has been one of the most hotly
debated topics in email over the years, and I've seen no indication that any
consensus has formed around a particular position.

The working that was chartered some years back to attempt to deal with this
self-destructed.

Plenty of people (like Pete, apparently) believe that mailing lists should not
mess around with originator headers at all, ever. There was a time when this
position was so prevalent that the operators of mailing list expanders
routinely got flamed for operating in any other way.

Others believe that it is perfectly OK for mailing lists to insert Sender:
fields. There's even a school of thought that says a From: should be inserted
(haven't seen too many proponents of that one since 2822 came out, but it may
still exist).

I don't recall anyone considering using Resent- fields for this until just now,
but I could easily have missed it - these debates frequently have descended
into nasty personal attacks, causing me to tune out.

Speaking as an implementor of mailing list software, I've long since given up
trying to tell people how this should be configured. As a result our software
lets people do whatever they want in this regard. And that's exactly what
people do - whatever they want.

My personal opinion is that a rule either way on originator field issue would
be better than the current situation. But I also think it is unlikely that
consensus can be reached on one.

				Ned

---

From: Hector Santos <[email-masked]>
Date: Tue, 04 Dec 2007 20:16:29 -0500

Pete Resnick 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

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 5 Dec 2007 02:35:04 +0100

<[email-masked]> wrote:
 
> I don't recall anyone considering using Resent- fields for this until
> just now, but I could easily have missed it - these debates frequently 
> have descended into nasty personal attacks, causing me to tune out.

They also descended into something styling itself as RFC 4406 with
records in numbers of appeals filed, number of ABSTAINs recorded, 
length of IESG note, the works.  But Sender ID doesn't "replace" an
existing Sender (as proposed by JohnL for mailing lists).

> I also think it is unlikely that consensus can be reached on one.

We can't keep 2821bis 3.9 as is if it conflicts with the List RFCs.

RFC 4406 can fight for its own, it has caused enough trouble.  But
why folks still continue to propose *worse* ideas is beyond me. :-(

 Frank

---

From: Dave Crocker <[email-masked]>
Date: Wed, 05 Dec 2007 09:14:37 -0800

> 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.

>> argument that a list should add a Resent-Sender: rather than a Sender: 
>> but it's reasonable to do it either way.
> 
> 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

---

From: Mark Martinec <[email-masked]>
Date: Wed, 5 Dec 2007 19:22:12 +0100

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

Heretically rejecting the RFC 2822 restriction to one Sender header
field appears to put things back in order and opens up new grounds.

There could be one Sender for the secretary (mailing on behalf of...),
one by a googlemail.com remailer, one by a final mailing list
(each one prepended to a header), and each hop may sign whatever
fields it desires, ragardless of what might next hops be.

  Mark

---

From: Tony Finch <[email-masked]>
Date: Wed, 5 Dec 2007 19:44:12 +0000

On Tue, 4 Dec 2007, [email-masked] wrote:
> just now, but I could easily have missed it

I think it's a cute idea, but Resent- fields are an interop nightmare
because the 822 specification is too weak to work in general (e.g. a
sequence of multiple resendings) and the 2822 specification is not
entirely compatible and not widely implemented.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
SOUTHEAST ICELAND: CYCLONIC 5 TO 7, OCCASIONALLY GALE 8 AT FIRST IN SOUTH.
ROUGH OR VERY ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Tony Finch <[email-masked]>
Date: Wed, 5 Dec 2007 19:53:20 +0000

>    mailbox of the agent responsible for the actual transmission of the

Popular MTA implementations (Sendmail, Postfix) do not implement the
Sender: header the way 822 and 2822 suggest, so even before you consider
mailing list managers you need to be very careful about RFC lawyering.

Microsoft MUAs present message headers in a way that works best if normal
messages do not have a Sender: field and mailing list messages do have one.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
LUNDY FASTNET IRISH SEA SHANNON: WEST OR SOUTHWEST 6 TO GALE 8, PERHAPS SEVERE
GALE 9 LATER. HIGH OR VERY HIGH IN FASTNET AND SHANNON, ROUGH OR VERY ROUGH IN
LUNDY AND IRISH SEA. RAIN OR SQUALLY SHOWERS. MODERATE OR GOOD, OCCASIONALLY
POOR.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave Crocker <[email-masked]>
Date: Wed, 05 Dec 2007 13:14:24 -0800

Tony Finch wrote:
> Sender: header the way 822 and 2822 suggest,

How would you describe what they do do?

d/

-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Wed, 05 Dec 2007 16:14:38 -0500

Ha! Yammer-To-Author! Hilarious!

Thanks for making my day. :-)

Steve Dorner wrote:
> 
> At 9:14 AM -0800 12/5/07, Dave Crocker wrote:
>> Frankly I think [Resent-] should be deprecated, because it causes so 
>> much trouble.
> 
> Along with From, Sender, and Reply-To.  :-)
> 
> I see no straightening out of the tangle we are in regarding all these 
> fields.  We keep trying to tweak the rules, tweak compliance, etc, so 
> that we get a system where everybody can conveniently do what they want, 
> and I don't think it's possible.
> 
> Frankly, I think we either just give it up and live with it, or define 
> entirely new fields with narrow, specific meanings that enable agents to 
> put together the operations we like.
> 
> Eg, deprecate (softly and over time) Sender, and replace with:
> 
> Original-Injector:
> List-Injector:
> Translated-Injector:
> Fuelled-Injector:
> ...
> 
> Deprecate Reply-To:, and replace with:
> 
> Yammer-To-Author:
> Yammer-To-List:
> Yammer-To-Mother-In-Law-of-Cousin-Of-Mailing-List-Owner:
> ...
> 
> We have to get very specific about labelling who did what to whom if we 
> hope to have a situation that is satisfying to our sense of the right 
> progression of the universe.
> 
> Some of these fields probably would need to be multiple, and even 
> order-maintained.  They might need syntax above and beyond what is 
> currently allowed for recipient fields.  There would probably be a fair 
> number of them.
> 
> But there's so much useless junk flying around in email now, several 
> dozen more addressing fields would hardly be noticed.  :-)
> 
> My guess is that "living with it" is going to win.
> 
> 
>

---

From: Hector Santos <[email-masked]>
Date: Wed, 05 Dec 2007 16:29:31 -0500

> How would you describe what they do do?

Well, if SendMail/PostFix is operating like the rest of the world... If 
missing, a SMTP receiver MIGHT do:

    Sender: <-- x821.MailFrom

in the same vain many SMTP receivers will fill in the missing 822 
required fields.

    FROM:  <<-- x821.MailFrom
    To:    <<-- x821.RcptTo

and they MUST do this if they want to SUPPORT the presentation layers.

But sender is not a given because it is not a 822 required field. In 
fact, I seem to recall, it was only in recent years that we even 
bothered with Sender in our mailers.

Only a few sites will reject such empty headers in the DATA block. Off 
hand, I know of one, HOTMAIL.COM and they only started to reject mail 
without the headers when SENDER-ID support was added to HOTMAIL.COM.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: Tony Finch <[email-masked]>
Date: Thu, 6 Dec 2007 15:17:18 +0000

> How would you describe what they do do?

Sendmail and (recent versions of) Postfix never add a Sender: field to the
header. Exim (by default) adds a Sender: field corresponding to the
authenticated sender if this is different from the From: field, which is
what 822 and 2822 and 4409 suggest. Traditional Unix MUAs don't bother
showing the Sender: field, but Microsoft Outlook is quite keen on it.
Therefore in our environment messages from role addresses tend to show up
in Outlook as "from person on behalf of role" which is annoying. I'm
inclined to give up on adding Sender: fields as specified and instead use
non-standard annotations in the Received: fields to record the
authenticated sender (as in this message).

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
FITZROY SOLE LUNDY FASTNET: WESTERLY 7 TO SEVERE GALE 9, PERHAPS STORM 10
LATER IN SOLE, LUNDY AND FASTNET. ROUGH OR VERY ROUGH, OCCASIONALLY HIGH. RAIN
THEN SQUALLY SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html