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

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 1 Dec 2007 13:07:50 +0100

Scott Kitterman wrote on the DKIM list:

> On Thursday 29 November 2007 06:32, Charles Lindsey wrote:
>> Note that a mailng list expander is supposed to insert a Sender.
 
> IIRC it's a SHOULD and not a MUST, so one really can't rely on it.

Can you (Charles + Scott, or anybody else who knows it) please
check this ?  I thought that mailing lists are NOT supposed to
insert Sender (or Resent-*) header fields unless they wish to 
participate in PRA checks (RFC 4406).

Example:  Charles + Scott as authors (2822-From) post an answer
to a mailing list (with 2822-Sender Scott), what's the mailing
list software supposed to do if it doesn't support a 4406 PRA ?

 Frank (cc rfc822, maybe it's not exactly a DKIM question)

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

---

From: Hector Santos <[email-masked]>
Date: Sat, 01 Dec 2007 08:56:51 -0500

> participate in PRA checks (RFC 4406).

Sender predates PRA so how can PRA regulate it?

>  Frank (cc rfc822, maybe it's not exactly a DKIM question)

Unless I am mis-understanding here, if so, I apologize for jumping in ....

No,  for a mailing list, Sender: is generally the mailing list's "Pseudo 
Admin Agent",  like for this list IETF-DKIM message:

     Sender: [email-masked]

or like in our setup in our support lists:

     Sender: [email-masked]

So Scott should not be in the Sender: field.

The key thing is that it should never be part of a HUMAN reply process, 
and as far I recall in our various MUA testing, none include it in a 
"Reply To All" concept.  IMO, this is one reason why the PRA algorithm 
is flawed.

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

---

From: John Levine <[email-masked]>
Date: 1 Dec 2007 15:30:53 -0000

>participate in PRA checks (RFC 4406).

Since Sender-ID is at most an experimental RFC, no sensible mailing list
does anything just to make S-ID happy.

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.  

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.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Sat, 01 Dec 2007 10:53:58 -0500

> name since it's the list that's sending the mail.  

+1.

A mailing list agent often and reasonably changes a message in substantial 
ways.  Even if a particular agent does not make changes (other than 
re-posting) it is, in fact, re-posting.  That makes the mailing list agent the 
address that is appropriate for the rfc2822.Sender field.

> but it's reasonable to do it either way.

My own feeling is that resent headers were a good idea that have proved far 
more problematic that beneficial. One could make a very plausible argument for 
deprecating them...

ps. Having this list discuss Sender-ID seems a bit odd.  Worse is the idea 
that Sender ID or DKIM or any adjunct protocol enhancement could be viewed as 
modifying anything as basic as the content of rfc2822 Originator fields...
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 1 Dec 2007 18:51:26 +0100

> Sender predates PRA so how can PRA regulate it?

List owners can decide that they wish to support PRA checks based
on RFC 4406 (or based on an IESG note repeated in "other" RFCs ;-)
 
>> list software supposed to do if it doesn't support a 4406 PRA ?
[...]

> No,  for a mailing list, Sender: is generally the mailing list's
> "Pseudo Admin Agent",  like for this list IETF-DKIM message:

> So Scott should not be in the Sender: field.

Would the mailing list software replace the Sender: Scott header
field, or would it reject the submission ?  What I really wanted
to know, Scott mentioned a SHOULD about this issue, but which RFC
(apart from RFC 4406) talks about Sender header fields set by a 
mailing list ?  I'm looking for an RFC number, not for an example
what some lists actually do.  I think the RFCs about List header
fields and the List-ID don't mention Sender, but I could be wrong.

> The key thing is that it should never be part of a HUMAN reply
> process, and as far I recall in our various MUA testing, none
> include it in a "Reply To All" concept.

ACK, that's very clear in (2)822(upd), let alone the four or more
RFCs explaining the purpose of an "envelope sender address" again
and again - only the creators of Sender ID never got the idea. :-(

> IMO, this is one reason why the PRA algorithm is flawed.

Let's be fair, they don't use the PRA for human or auto replies.

 Frank

---

From: John Levine <[email-masked]>
Date: 1 Dec 2007 18:34:58 -0000

>field, or would it reject the submission ?

Replace it, since the list is the Sender: for the mail it sends.

This has nothing to do with DKIM, Sender-ID, or anything other than
RFCs 2822 and 822.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Sun, 2 Dec 2007 00:42:45 -0800

On Dec 1, 2007, at 1:11 PM, Frank Ellermann wrote:

> John Levine wrote on the DKIM list:
>>
> Doug's SSP-TPA is related to DKIM and I think it mentions the PRA.

SSP-TPA can deal with PRA related headers, but only because headers  
other than From may also represent who originated the message.

The SSP-TPA draft provides a means to assert scope.  Scope is broken  
down into three areas:

1) From originating header (Normal SSP scope)
2) Other than From originating headers (Sender, and Resent-*)

For example, a mailing list might wish to assert identities associated  
with email-addresses within the Sender header are "authenticated".   
The current DKIM base specification prevents i= semantics from being  
able to make this assertion.

3) TPA-SSP also provides a MAILFROM policy assertion that might be  
used when issuing a DSN.

Currently, there is the F-i, O-i, and M-i assertions.  From feedback  
on the list, perhaps F-a, O-a, and M-a, could be added, where the i=  
identity would then track the account gaining access, rather than  
indicating an identity associated with an email-address found in an  
originating header (Originating with a small 'o') has been  
authenticated.

In addition to ensuring a mistake is not made regarding an assumption  
of authentication or uniqueness, being able to express scope better  
defends a DKIM validation process.

<rant>
Levels of abuse are doubling at an interval far less than that for  
hardware's performance doubling.  Several product lines have been  
dropped when coping with abuse was not economically practical.  In  
addition, detecting obfuscation techniques also demands a steep  
increase in resources.  (The sky is not falling, but the horizon looks  
very dark.)

Source reputation may be a means to deal with this growing abuse  
problem.  Unfortunately, a rising percentage of abuse is being sent  
through large provider's outbound MTAs.

Users being blocked by their own provider confronts a conflict of  
interest.  Often the provider's desire is to reduce operational costs  
and minimize support efforts.  When the large provider is completely  
blocked by receiving domains, a sizeable support cost will be created  
for both transmitting and receiving domains due to a resulting high  
level of collateral blocking.  When users are blocked individually by  
many receiving domains, the user just might understand the problem to  
be theirs.  This understanding could be reinforced when many different  
failure notifications clearly indicate their account has earned a bad  
reputation.  When these users contact those blocking them, support  
costs will also be distributed, often to those in the business of  
blocking abusive sources.

DKIM might allow such a clear user notification when SSP or TPA-SSP  
records include a scope parameter.

DKIM could help solve the large domain abuse problem in a way that  
justifies resources needed to validate DKIM signatures.  Without an  
ability for the receiver to resolve problems at a smaller granularity  
than the domain, issues related to bots and replay abuse will likely  
cause DKIM validation to be bypassed for all but those domains being  
phished.
</rant>

> RFC 4406 requires to violate the quoted 2821(bis) MUSTard for its  
> purposes, it even got an IESG note about the fact.  And (2)822(upd)  
> doesn't mention mailing lists explicitly.  Now is a good time to get  
> this right, as my attempt to switch to the rfc822 list failed, I now  
> try the smtp list, it's a potential bug in 2821bis.

The conflict appears to be in RFC4406 section 7.2 regarding  
recommendations to inject Resent-From or Sender headers when forwarding.

While Sender-ID has created problems for mailing-lists, forwarding  
also causes problems.  Resolving all addresses used by a domain makes  
abuse less tractable, in addition to placing DNS itself in peril.  If  
email ever embraces IPv6, this would double the related overhead and  
risk related to IP address path registration.

It this weren't such a rate-hole, TPA-SSP records could include scope  
assertions declaring DKIM's relationships to SMTP clients, and whether  
all outbound messages are always signed by the domain's SMTP clients.   
SMTP client assertions would provide a far safer alternative to IP  
address path registrations.

-Doug

---

From: <[email-masked]>
Date: Mon, 3 Dec 2007 11:13:47 -0500

A mailing list is an original mail object that is comprised of vetted
submitted material much like a newspaper. It should take submitted
material, empty the accompanied envelope and remail using a fresh clean
envelope with new headers.
Thanks, 

Bill Oxley
Messaging Engineer
Cox Communications
404-847-6397

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Dave Crocker
Sent: Saturday, December 01, 2007 10:54 AM
To: [email-masked]
Subject: Re: [ietf-dkim] Mailing lists as 2822-Sender

+1.

A mailing list agent often and reasonably changes a message in
substantial 
ways.  Even if a particular agent does not make changes (other than 
re-posting) it is, in fact, re-posting.  That makes the mailing list
agent the 
address that is appropriate for the rfc2822.Sender field.

> but it's reasonable to do it either way.

My own feeling is that resent headers were a good idea that have proved
far 
more problematic that beneficial. One could make a very plausible
argument for 
deprecating them...

ps. Having this list discuss Sender-ID seems a bit odd.  Worse is the
idea 
that Sender ID or DKIM or any adjunct protocol enhancement could be
viewed as 
modifying anything as basic as the content of rfc2822 Originator
fields...
-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Mon, 03 Dec 2007 08:58:18 -0800

Bill,

> envelope with new headers.

In the abstract, the model you describe is probably the best to use.  I think 
it is obviously true for a "digest" mode of mailing out a collection of postings.

For the case that we are all most used to, it is probably still true, but less 
obviously, since recipients perceive the message as "from" the original author.

That difference between actual responsibility, versus reader-perceived 
responsibility, is the issue.

d/
-- 

   Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Mon, 3 Dec 2007 10:43:00 -0800

On Dec 3, 2007, at 8:58 AM, Dave Crocker wrote:

>> A mailing list is an original mail object that is comprised of  
>> vetted submitted material much like a newspaper. It should take  
>> submitted material, empty the accompanied envelope and remail using  
>> a fresh clean envelope with new headers.
>
> In the abstract, the model you describe is probably the best to  
> use.  I think it is obviously true for a "digest" mode of mailing  
> out a collection of postings.
>
> For the case that we are all most used to, it is probably still  
> true, but less obviously, since recipients perceive the message as  
> "from" the original author.
>
> That difference between actual responsibility, versus reader- 
> perceived responsibility, is the issue.

When SSP makes a STRICT assertion, then From email-addresses not  
signed by the same or parent domain are suspicious (and likely  
rejected).  The STRICT assertion is incompatible with the use of  
mailing-lists.  It is more likely that for a mailing-list the Sender,  
and not the From, last modified (flattened) message content.  With a  
mailing list, it is also unlikely that the identity represented by the  
 From email-address had been authenticated.

Even when SSP makes a STRICT assertion, there is no assurance the  
identity represented by the From email-address will have been  
authenticated.  Making a STRICT SSP assertions may necessitate the  
DKIM signature to lie or remain ambiguous as to who's behalf the  
message had been signed.  Remaining ambiguous may be necessary simply  
because there is _no_ means to achieve STRICT policy compliance for  
other headers.  The STRICT SSP assertion intentionally breaks many  
normal use scenarios, and in doing so, places restrictions on the use  
of the i= semantics.

Should DKIM reinforcing a perception that From field email-addresses  
_always_ represents the responsible identity for message content?   
DKIM is limited to the domain, and of course the domain _never_  
creates message content.  A STRICT SSP policy is domain-wide and  
_breaks_ email.  Tactics to overcome this breakage, along with the  
dubious recognition of email-addresses creates more opportunities to  
mislead recipients.  Repair tactics using visible sub-domains email- 
addresses having different policies will increase recipient  
confusion.  As internationalization becomes prevalent, identities  
represented by email-addresses will become even more ambiguous.

Having said that, TPA-SSP can minimize breakage while also eliminate  
some of the i= semantic restrictions.  TPA-SSP also improves the  
ability to obtain a higher granularity than just the domain, as well  
as establish FULL "strict" compliance based upon Sender in addition to  
just From headers.  This is done by allowing policy compliance to  
include more than just the From header, and by allowing transparent  
use of signing sub-domains (which is considered a third-party  
domain).  Messages signed with authorized sub-domains can express  
different policies and scope without recipients ever seeing this  
complexity.  TPA-SSP follows KISS from the recipient's perspective.   
The complexity of TPA-SSP is well hidden and does not increase  
overhead beyond that needed to implement a CNAME. : )

-Doug

---

From: Mark Martinec <[email-masked]>
Date: Tue, 4 Dec 2007 20:32:26 +0100

> This has nothing to do with DKIM, Sender-ID, or anything other than

Such practice is problematic with DKIM, see below.

Dave Crocker wrote:
> re-posting) it is, in fact, re-posting.  That makes the mailing list agent
> the address that is appropriate for the rfc2822.Sender field.

I'm observing regular cases of originator signature breakage
by mailing lists which DO NOT modify mail body or header in
intrusive ways. This happens every time the poster included
a Sender header field in its original posting, and then sign it.
A mailing list which replaces the original Sender by its own
causes a signature breakage, quite unnecessarily.

Unfortunately the RFC 4871 wants a Sender signed:

  The following header fields SHOULD be included in the signature,
  if they are present in the message being signed:
    o  From (REQUIRED in all signatures)
    o  Sender, Reply-To ...

and RFC 2822 only allows one instance of a Sender header field.

It would be nice to have a clear guideline on what a mailing list
should do with a Sender, and/or a guideline that DKIM should not sign
the Sender field if message is intended for posting.

  Mark

---

From: Michael Thomas <[email-masked]>
Date: Tue, 04 Dec 2007 11:47:42 -0800

> the Sender field if message is intended for posting.

This is a good point. What I do is _not_ sign Sender: if it is
not present in the message. Thus a mailing list that inserts Sender
won't break the first party signature. This seems to work pretty
well in real life.

		Mike

---

From: "J D Falk" <[email-masked]>
Date: Tue, 4 Dec 2007 17:44:55 -0500

> the Sender field if message is intended for posting.

+1 on clear guidelines for discussion lists, but let's make that a new
BCP rather than trying to cram it into any of the currently open
documents.

---

From: Hector Santos <[email-masked]>
Date: Tue, 04 Dec 2007 18:52:47 -0500

> and RFC 2822 only allows one instance of a Sender header field.

Note that it is a SHOULD not a MUST.

Hmmmm, I seem to recall a discussion and consensus that signatures 
should not include headers likely to change.

Yes, see 5.4.  Determine the Header Fields to Sign

       INFORMATIVE OPERATIONS NOTE: The choice of which header fields to
       sign is non-obvious.  One strategy is to sign all existing, non-
       repeatable header fields.  An alternative strategy is to sign only
       header fields that are likely to be displayed to or otherwise be
       likely to affect the processing of the message at the receiver.

It is indicated as one possible strategy and it is prudent this logic 
must be part of new DKIM systems signing configuration options.

The long time reality is such it is long established Mail List Servers 
(MLS) may strip/replace a Sender header.  It just is. Therefore new 
systems need to fit with the process. Originating DKIM signature signing 
systems MUST be aware of where its signed mail is going, especially if 
it is expected to be re-distributed.

 > the Sender field if message is intended for posting.

I would be willing to volunteer to write a I-D of BCP on this or at 
least put the initial considerations together. I provided many 
considerations for interfacing a MLS with DKIM/SSP.  In my (now expired) 
DSAP I-D, I had this written:

    3.3.  Mailing List Servers

    Mailing List Servers (MLS) applications who are compliant
    with DKIM and DSAP operations, SHOULD adhere to the following
    guidelines:

     Subscription Controls

         MLS subscription processes should perform a DSAP check to
         determine if a subscribing email domain DSAP policy is
         restrictive in regards to mail integrity changes or
         3rd party signatures. The MLS SHOULD only allow original
         domain policies who allow 3rd party signatures.

     Message Content Integrity Change

         List Servers which will alter the message content SHOULD
         only do so for original domains with optional DKIM
         signing practices and it should remove the original
         signature if present. If the List Server is not going
         to alter the message, it SHOULD NOT remove the signature,
         if present.

So, MLS systems can adapt, but the original systems also need to take 
into account where they are sending mail too.  Signing headers that are 
very likely to change is just not a smart idea for DKIM signers.

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 05 Dec 2007 12:51:18 -0000

> causes a signature breakage, quite unnecessarily.

But if RFC 2822 is followed, then Sender SHOULD NOT be present unles there  
are explicit reasons for doing so. The usual examples given are:

1. The secretary is sending on behalf of her boss
2. There are multiple entries in the From (in which case the Sender MUST  
be included).

Neither of those commonly arises in mailing lists.

In the few cases where an already signed Sender arrives at a mailing list,  
then the mailing list should do the same as if it makes any other change  
which invalidates the signature. My preference for that situation is for  
the mailing list to:

1. Check the existing signature (and maybe reject outright if it is  
'suspicious').
2. Record his (hopefully correct) check result in an  
Authentication-Results header.
3. Re-sign the message, including that new Authentication-Results header.
>     o  From (REQUIRED in all signatures)

Yes, but I would be inclined to modify that by only signing it where it  
was NOT identical to the From (i.e. in the secretary and multiple Froms  
cases above).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Mark Martinec <[email-masked]>
Date: Wed, 5 Dec 2007 16:14:35 +0100

> Neither of those commonly arises in mailing lists.

It happens with every posting signed by  d=googlemail.com; s=gamma

The From is a home/native address of the author,
the Sender is presumably [email-masked],
but is replaced by a Sender address of a mailing list.

> was NOT identical to the From (i.e. in the secretary and multiple Froms

The original Sender is not identical to From.

  Mark

---

From: Dave Crocker <[email-masked]>
Date: Sun, 09 Dec 2007 08:27:33 -0800

SM,

I can't recall whether your suggested received a response, but thought it 
worth making sure:  the change is being incorporated to the draft.

The difference in language does a nice job of being completely accurate and 
precise without being cumbersome.

d/

SM wrote:
> At 10:17 27-11-2007, Dave Crocker wrote:
>> Rather, DKIM's task is to allow an organization to say this it has 
>> some responsibility for the message; that is, come to them if there is 
>> a problem.
> 
> In the abstract of draft-ietf-dkim-overview-07
> 
>   "DomainKeys Identified Mail (DKIM) allows an organization to take
>    responsibility for a message, in a way that can be validated by a
>    recipient."
> 
> I suggest having:
> 
>   "DomainKeys Identified Mail (DKIM) allows an organization to take
>    responsibility for transmitting a message, in a way that can be 
> validated by a
>    recipient."
> 
> as the organization, an ISP for example, is not responsible for the 
> "content" of the message.  The signer is merely offering a means for the 
> original or intermediate transmission to be validated.
> 
> The above comment applies to draft-ietf-dkim-deployment-00 as well.
> 
> Regards,
> -sm

-- 

   Dave Crocker

---

From: Jeff Macdonald <[email-masked]>
Date: Mon, 10 Dec 2007 17:07:58 -0500

I'm a bit behind on this but:

On Thu, Nov 29, 2007 at 03:43:55PM -0500, J D Falk wrote:
>I agree, that would be extremely helpful -- but DKIM's i= won't give it
>to us.  (Unless you're assuming that these same botnet operators will
>allow themselves to be corralled into a single identifer, which clearly
>isn't the case.)

this thinking needs to be applied to d= too. And once you do that, then
the logical conclusion (well, to me :)) is that d= isn't any better as
an identifier.

-- 
:: Jeff Macdonald | Director of Messaging Technologies
:: e-Dialog | [email-masked]
:: 131 Hartwell Ave. | Lexington, MA 02421
:: v: 781-372-1922 | f: 781-863-8118
:: www.e-dialog.com

---

From: "J D Falk" <[email-masked]>
Date: Wed, 12 Dec 2007 20:57:52 -0500

Jeff Macdonald wrote:

> this thinking needs to be applied to d= too. And once you do that,
> then the logical conclusion (well, to me :)) is that d= isn't any
> better as an identifier.

A bad guy buying another domain name is a threat we already have to deal
with today.  It's not a high barrier, but it is a barrier.

The same bad guy having an infinite number of entirely distinct i=
identities at each of those domains would be a new threat, equal to
forging the From: header -- and the obvious conclusion will be to ignore
i= and instead concentrate on d= (along with other reputation inputs.)

But since this is about reputation, it's out of scope.

---

From: Jim Fenton <[email-masked]>
Date: Thu, 13 Dec 2007 00:49:10 -0800

J D Falk wrote:
>>> I agree, that would be extremely helpful -- but DKIM's i= won't give
>>>       
> it
>   
>>> allow themselves to be corralled into a single identifer, which
>>>       
> clearly
>   
>>> isn't the case.)
>>>       

The bad guy can still create subdomains and publish keys there:  Create
a key under foo._domainkey.sub.example.com and they can sign with s=foo;
d=sub.example.com.  In other words, using d= doesn't get away from being
able to create a whole bunch of entirely different identifiers. 
Creating key records is really cheap.

This is part of the reason that I consider d= to be just the location
where the key is stored, and nothing more than that.
> But since this is about reputation, it's out of scope.

Sure enough.

-Jim