Subject: [ietf-dkim] SSP and mailing lists

From: "Thomas A. Fine" <[email-masked]>
Date: Mon, 11 Sep 2006 14:57:52 -0400 (EDT)

Some here have proposed adding a clause statement to the
standard all-signed policy that waters it down to effectively
mean that receivers might get valid messages damaged by
gateways, and adds a new policy that says a domain guarantees
it's addresses will not go through non-compliant gateways.

The standard policy becomes to weak.  It doesn't mean anything
besides "please accept mail that looks like it might be from us.
It means the domain remains unprotected.

And who could set the stricter policy?  The odd bank or tightly run
corporate entity maybe.  Who could not?  Universities, ISPs, email
address providers, technical corporations -- all these groups expect
their users to have some amount of freedom participating in mailing
lists.

So if the only way a domain can set a policy that permits* recipients
to drop unsigned or broken mail is to set a policy that it will
not use non-compliant mailing lists, then this is doomed to failure,
and I would go so far as to say that nobody would bother with DKIM
at all, because they couldn't use it to protect their domains.

One serious point about a policy such as the one described above is that
it seems to attempt to describe the transitional state of the entire
internet, rather than the transitional state of a particular site.  As
such, almost no one could have any other policy besides this until DKIM
acceptance approached 100%.

Maybe this is just a question of wording.  Perhaps everyone would be
satisfied with these two policies:

"I sign all email"

"I sign all email, and do NOT permit email through any body or
signature altering gateways"

Now this might accomplish what is desired, but it reads entirely
differently.  The first is still strong, not weakened as has been
suggested.  And they describe what the site does, not what the
internet is doing.  The second statement is very strong.  It
may be rarely used but I can see it's utility.  It would probably
be more useful on a per-address basis than it would be on a
per-domain basis.

First, note that basically what this almost seems to be saying is that
the envelope-from must match the From: and/or DKIM address.

Second, note that this may only useful in a policy-first environment.
In the current spec, the assumption is we never know the policy if we
have a valid key.  So without gutting and reworking that fundamental
concept (which might be a good thing), such a policy of more strict
email control is not really implementable.

So basically, I think that policy should be designed for the long
term steady state, and not designed primarily for a transition
period.  The implementors can take care of the transition.

       tom

* another spin on who dictating versus recommending versus asking is
this:  an all-signed policy gives the sending domain's _blessing_ to
the receiver to drop the mail on the floor if it is not verifiable.
It doesn't say they have to do it, but it says that it is fine to
do that.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 11 Sep 2006 20:11:20 +0100

Hi Thomas,

This isn't really directed at you, but I've wondered each time
someone has said something like:

> signature altering gateways"

I've no idea how a sending domain could enforce the "do NOT permit"
there. Neither in practice, nor in principle. Does anyone? (This may
just be my own ignorance of course, I don't claim to be a mail
expert.)

If its unenforceable, then I don't see why anyone would bother making
the statement.

Stephen.

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 11 Sep 2006 15:26:30 -0400

Thomas

You raised good points, but I don't think it is that complex at all.

We have a mailing list server (MLS) product and I feel that if we want to
accomodate DKIM, there are some things that we can do:

 - The MLS should use SSP to pre-emptive email subscribers
   with restrictive domains. This would be done at the
   subscription level. It will help protect the domain owner
   from any possible malicious abuse from their own employees,
   users, students, or bad actors.

 - If the MLS is prepared for signing, it should use SSP to
   determine which domains allow it.

 - If the domains allows it, the MLS should be allowed to
   STRIP broken signatures or signatures it will break by
   resigning and then resign itself. NOTE: This is currently
   against DKIM-BASE specification (No stripping).

In short, iff the DOMAIN doesn't care about the potential abuse of its
domain by promiscuously or blindly sending it to a MLS, then the DOMAIN
should be explicit with relaxed SSP policies saying it really doesn't care
or not use DKIM at all for this particular mode of operation.   At this
point, the receiver will treat it like any other mail because the DOMAIN
simply doesn't care one way or another.

To me, it doesn't make sense for an organization to invest in a new SECURITY
framework only to leave the key under the "Porch Potted Plant" thus breaking
its own new DKIM security policies for the organization.  (See ** below)

With just DKIM-BASE, the threats are well documented. See the TA draft.

SSP is about offering a possible solution, if only partial, to this problem.

The main issue is feasibility.  If you want DKIM to work via a MLS, then I
think it is naive to believe (speaking in general) it will work very well
without some sort of MLS change to consider the redistribution process of
original DKIM signed mail.

** Take for example this mailing list:

There are signatures here from various people; Mike, Jim, Arvel, etc.

Guess what?

All of them will fail the DKIM test because the mailing list server hosting
IETF-DKIM is breaking the integrity of the message without correcting it.
Yet we continue the downlinks ignore it and accept it - the CRY WOLF
syndrome.

What is to prevent the BAD ACTOR to use this "cry wolf", borrowing Mike's,
Jim's, etc signature and use it in ATTACKING other systems?

Or even here, how will I know that the post here from Jim or Mike actually
come from them?

In short, what this will promote is a damage DKIM concept where receivers
will ignore DKIM altogether just like users ignore Popup Errors from MUA
saying a SMIME/PGP message has failed.

This is what you want to avoid.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 11 Sep 2006 15:40:50 -0400

----- Original Message -----
From: "Stephen Farrell" <[email-masked]>
To: "Thomas A. Fine" <[email-masked]>

> If its unenforceable, then I don't see why anyone would bother making

It is programmable Stephen.   If it feasible?  That depends.

It could be a few things:

 - Probably less reliably, it can use the Received headers to
   trace the hops.

 - A MDA which is actually a relay or router or forwarder is
   DKIM compliant and it might have a different set of routing
   rules.

 - The Verifiers along the chain see a restrictive SSP policy
   and keeps with the traditional "Thou should not tamper"
   passthru philosophical.

And probably some other possibilities, but I think the most feasible are the
latter two.

The way I see it, the domain that is really intent in using DKIM to the
"notion" that it will help protect its message transactions and the final
end user will have a higher confidence in its originality, these people are
direct their mail to systems known to have a safe and/or DKIM compliant
path.

And I don't mind looking at our ROUTER software to see we can make DKIM work
better with protocol consistency in mind.

PS:  SPF ran into the same problem with its FORWARDING ISSUE and the group
still has the thorn on its side about WHO is responsible for the damages,
the MDA who was really a RELAY?  or the SPF domain for its desire to get
maximum benefit using restrictive (-ALL, ~ALL) policies.  I predict the same
will happen with DKIM as well. When damages happen, they will wonder who is
really at fault. DKIM domains with restrictive policies at the software for
not having the standardize mandate to properly program it.   To me, its the
same issue, but with DKIM it is less of an issue because DKIM does solve the
forwarding problem, but it doesn't address when there is additional
tampering and/or uncontrolled resigning that might break the integrity of
the message.

---

From: wayne <[email-masked]>
Date: Mon, 11 Sep 2006 15:06:45 -0500

> just be my own ignorance of course, I don't claim to be a mail

Well, you can't 100% enforce a "we don't send to mungers" requirement
any more than you can enforce a "we sign all email" requirement.
There are a lot of fairly easy steps you can take though:

1) If you can, set up domains such as accounts.bigbank.com that have
   no user mailboxes and is only used to send transactional email to
   customer accounts.

2) If you use domains where there are user mailboxes, have corporate
   policies that you can't sign up for mailing lists and such.  If
   anyone violates the rule, deal with them the same way you would any
   other violation of customer policies.

3) When a customer gives you an email address to use, send a test
   email to them to verify that it is valid.  To activate, make them
   either forward the email back or have them cut and paste it into a
   web form, very similar to how spamcop has dealt with the "mailhost"
   configuration stuff for several years now.

4) When you find out that there are problems sending email to $customer or
   $domain, work with the customer/mail-admin to fix the problem, and
   if it can't be fixed, disable sending email to $customer and/or
   $domain.

Of course, you also have to do all the work to make sure that all your
email is signed, that all your MTAs are working right, that employees
working at home don't send through their ISPs, that you don't use
greating-card/send-news-article stuff, etc.

Yes, this is a bunch of extra work that most will not be willing to
do, but I don't expect everyone to do it.  This is also the kind of
work that the receiver can not easily tell if the sender is doing or
not, but which the receiver can find very useful in deciding whether
they should accept or reject an email that has been munged.  So, this
is exactly the kind of information that needs a way for the sender to
communicate with the receiver about.  It benefits both parties.

-wayne

---

From: "Thomas A. Fine" <[email-masked]>
Date: Mon, 11 Sep 2006 16:12:21 -0400 (EDT)

>If its unenforceable, then I don't see why anyone would bother making

Lot's of businesses have email policies that their employees are expected
to follow.  Many say that personal email is not allowed with a business
account.  A bank might be an example of someone who could have such
a tight policy that the bank email addresses can only be used for
inter-office email, or to a limited degree for customer correspondence,
and for no other purpose.

So for a bank, or another entity with very high security standards, this
might be a good policy.  But for almost no one else.  As far as
enforceability goes, the point would be that a DKIM/SSP compliant
receiver would be able to enforce this.  Other than that, it is as
enforceable as any corporate email policy.  Some corporations do
literally monitor all email traffic, and could catch people
violating their internal policy.

Note that I'm not advocating for this extra claim of where the email
has gone.  I can see that it would be useful in a few situations.  I'm
not sure how it would fit into the current system where policy is never
checked if the signature is valid.  Another approach to accomplish the
same protection might be to include a signed tag in the email header that
says something like "DKIM-forwardable: no", and then the MDA could
increase it's verification standards when that tag is found.
I'll have to think this idea through though...

         tom

---

From: <[email-masked]>
Date: Mon, 11 Sep 2006 16:24:02 -0400

It may well be unenforcable. If I send an email directly to
[email-masked] signed and with the SSP record of
> signature altering gateways"
I will open a session on port 25 at mx.cs.tcd.ie and hope that the
receiving mta does not add its own sig to the message before depositing
it to the inbox. Local rules might require the additional sig to ensure
that the inbox only gets mail from the edge mta. Now if Stephen is using
one of Doug's dkim aware MUA's that "see's" 2 signatures where only one
should be might flag the message with a red warning "suspicious mail
lies here" or inform Stephen that the message was deleted because the
SSP didn't match.
Thanks,
Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Monday, September 11, 2006 3:11 PM
To: Thomas A. Fine
Cc: [email-masked]
Subject: Re: [ietf-dkim] SSP and mailing lists

Hi Thomas,

Stephen.

---

From: Steve Atkins <[email-masked]>
Date: Mon, 11 Sep 2006 13:24:20 -0700

> communicate with the receiver about.  It benefits both parties.

Or you could just use S/MIME.

DKIM+SSP is not the only tool in the toolbox. Perhaps this is
one of the situations for which it isn't the right tool? If so, we
shouldn't blunt the tool we're developing to make it just barely
usable for a problem where a different tool would be more
appropriate.

Cheers,
   Steve

---

From: "Thomas A. Fine" <[email-masked]>
Date: Mon, 11 Sep 2006 17:01:21 -0400 (EDT)

>lies here" or inform Stephen that the message was deleted because the

Some different thoughts/questions on this one.

First, is this really likely?  Shouldn't such validation be handled
in the context of a closed network?

Second, does adding a new signature alter the original signature?
If not, then that would be fine.

Third, if the signature(s) verify, then would the policy even be
checked?  It's not in the single-sig context.  This leads back to
the unenforceable thing - you could always remove the original unremovable
signature, sign it again, and since the policy isn't checked, no one
would be the wiser.  Perhaps this is an argument for having policy-first
in effect all the time.

Finally, how is an MUA or an MTA supposed to validate mail that has more
than one signature?  Does it validate all of them, or only the outermost?

	 tom

---

From: Douglas Otis <[email-masked]>
Date: Mon, 11 Sep 2006 16:14:09 -0700

On Sep 11, 2006, at 1:24 PM, <[email-masked]>  
<[email-masked]> wrote:

> receiving mta does not add its own sig to the message before  
> depositing it to the inbox. Local rules might require the  
> additional sig to ensure that the inbox only gets mail from the  
> edge mta. Now if Stephen is using one of Doug's dkim aware MUA's  
> that "see's" 2 signatures where only one should be might flag the  
> message with a red warning "suspicious mail lies here" or inform  
> Stephen that the message was deleted because the SSP didn't match.

It is likely the initial method of retaining email-addresses will be  
through third-party lists.  People are normally  selective about what  
they place in their address-book, and that too can be a source of  
retained email-addresses.  Perhaps the third-party list comparisons  
get a gold-star, and the address-book comparisons get a silver-star.   
One might view retained email-addresses as being a form or  
reputation, but this will likely be something more along the lines of  
knowing their identity.  These domains may send a ton of spam and  
have a bad reputation from that aspect, but DKIM still allows safe  
transactions with this entity.  As such, one should be reticent at  
describing this as a reputation list.  It is not, at least not in the  
classic sense of an email reputation list.

When placing annotations upon email-addresses recognized as matching  
a retained email-address, other email-addresses do not require  
signature validations as there would be nothing gained in doing so.   
In addition, a signature not associated with the email-address would  
not be verified either.  It would not matter if there were ten  
signatures added to the message, only the signature assuring the  
email-address is valid would be verified.  As long as that signature  
is not damaged, the message can be annotated with a star next to the  
address.

There would not be any warnings needed when other signatures are  
added to the message.  In fact, just as with the web browser, without  
the lock-icon in the corner of the window, most people are  
conditioned not to enter critical data.  Of course people should also  
check the identity of the certificate that validated the lock, and  
the star annotations can work in the same manner.

Again, the critical aspect of offering annotations would be observing  
semantics that indicate the signing domain has validated the email- 
address.  A signing domain may sign messages where the email-address  
is not validated, and these email-addresses should not receive an  
annotation.  When there is some explicit association made via policy,  
one might assume only valid email-addresses are signed, but having an  
assurance made directly by the signing domain would improve upon  
security.

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 11 Sep 2006 21:32:47 -0400

----- Original Message -----
From: "wayne" <[email-masked]>
To: "IETF DKIM WG" <[email-masked]>

> 3) When a customer gives you an email address to use, send
>    a test email to them to verify that it is valid.  To
>    activate, make them either forward the email back or have
>    them cut and paste it into a web form, very similar to how
>    spamcop has dealt with the  mailhost" configuration stuff
>    for several years now.

+1

I predict high value companies investing in DKIM will eventually see the
need to establish a company policy of checking new customer email addresss
for security and/or DKIM readiness.

I can see that now being added to our list server product during the
subscriber process so that the owner doe not get embroiled in damaging
signatures, thus helping the domain protect themselves.

---

From: Steve Atkins <[email-masked]>
Date: Mon, 11 Sep 2006 18:44:25 -0700

> signatures, thus helping the domain protect themselves.

I'm hearing what sounds like a lot of FUD. Could you expand on
the details of what you perceive as a "damaging signature"?

Cheers,
   Steve

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 11 Sep 2006 22:13:33 -0400

----- Original Message -----
From: "Steve Atkins" <[email-masked]>
To: "IETF DKIM WG" <[email-masked]>

> the details of what you perceive as a "damaging signature"?

No FUD.

Just look at all the signed DKIM messages in this IETF-DKIM list.  They are
damaged DKIM signed messages. 100% failures!

No FUD.

Now, if this list server was DKIM-Ready, as suggested in the DSAP proposal,
it can take pre-emptive steps to deny restrictive domains from subscribing
to the list or atleast send a warning to the subscribing email address
saying any Signed Mail will be damage due to the MLS behavior to alter the
integrity of the message.

See section 3.3 in DSAP-00

http://tools.ietf.org/wg/dkim/draft-santos-dkim-dsap-00.txt

 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.

---

From: Steve Atkins <[email-masked]>
Date: Mon, 11 Sep 2006 19:54:02 -0700

> integrity of the message.

Ah, I misunderstood. Your concern is that some mail transports,
including mailing lists, will invalidate a messages signature,
causing it to be unsigned.

That's certainly true, though I see it more as an example of
the futility of expecting DKIM, and anything based on it,
to be able to decide between "this is authorized mail" and
"this is unauthorized mail" rather than between "this is
authorized mail" and "I don't know whether this is
authorized or not".

Cheers,
   Steve

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 11 Sep 2006 23:51:53 -0400

----- Original Message -----
From: "Steve Atkins" <[email-masked]>
To: "IETF DKIM WG" <[email-masked]>

> authorized mail" and "I don't know whether this is

Practically, as we knew since the beginning, the main problem is with the
middle ware such as list servers, mail bots, etc, that offer the highest
potential for damage.

The more direct transports will probably survive because for the most part,
most systems, the BCP is to honor the passthru concept.  In fact, as a side
note, there is legal precedence and a current appeals court case dealing
with this very concept of "who owns passthru mail." (ISP was screwing around
with routed mail for anti-competitive reasons and was sued based on US EPCA
grounds; lower court ruled in favor of the ISP, but most experts agreed it
was a wrong decision based on decades old tradition. It is under appeal and
most legal experts believe it will be overturned).

So with normal email, I'm sure there are the exceptions, I have little or
less concern as it should naturally and expected to work.

But with list servers, that's a different story and since we are so intent
in making it work or "fit" with list servers, well,  I can only express what
we would need to do in changing our software to accommodate this DKIM
engineering request.

The main issue with the list server problem is the "cry wolf" syndrome and
the inevitable high potential to ignore DKIM signature simply because they
will have a high rate of failure in mailing list.   Isn't this what happen
with SMIME/PGP mail?  Whenever I see a OUTLOOK popup saying this message has
failed SMIME, I pretty much ignore it. I asked the mail author why he is
sending SMIME signed mail via a mailing list if its going to fail all the
time?  What's the point?  What happens if some bad guys spoofed him with
HTML virus mail?  The "cry wolf" dilemma now has the potential to hurt me.

If the MLS was supportive and added 3rd party signatures, then we simply
need to work out the consistency of what it means in regards to the original
domain.

This is the other source of conflict in the group:

        uncontrolled vs. controlled 3rd party signers.

I think once we get pass that hurdle, we are pretty much covered as best as
we can do it.

So overall, I think its doable but it will also mean the original domain
itself has to be more aware and responsible of what it is doing by adding
DKIM into its mail system.

Thanks

---

From: Steve Atkins <[email-masked]>
Date: Mon, 11 Sep 2006 21:14:11 -0700

> we would need to do in changing our software to accommodate this DKIM

I certainly think that not breaking DKIM signatures will be a mild  
positive
for mailing list software, and in product terms it's probably a smart  
thing
to do. Why break something if you can easily avoid doing so?

> HTML virus mail?  The "cry wolf" dilemma now has the potential to  

I don't expect MUAs to pop up warnings or anything similar when they
seen unsigned mail. I wouldn't be surprised to see something akin
to a web browser "locked padlock" or colored browser bar GUI element,
but I think it would be a big mistake and a big disservice to users to
do that.

There are several reasons I think that it would be a mistake, but the
dominating one is that a message being signed doesn't mean that
it's trustworthy (of which the c1t1bank.com problem, and it's i18n
parallels is just one example).

I wouldn't be surprised to see one or more external, non self- 
publication
reputation services that tie a DKIM-identity to a real-life identity  
(the
"This is a bank" popup, say), but given the standardisation of DKIM I
expect these services to just happen, and they don't need any
standardisation or much discussion in advance.

The primary value of DKIM and any extensions that seem to be directly
in scope for this group is at the ISP MTA point, where it can
be used to accurately send feedback reports and maintain reputation
statistics for "honest" senders. By "honest" I don't mean anything more
than a sender who consistently uses a DKIM identity.

As far as reputation is concerned I expect that an unsigned email
and a signed email from a new signer will be treated identically
by recipient ISPs that don't have a political axe to grind. The DKIM
signature will be used to identify the entity whose reputation will
be improved or damaged by each email they send. But I don't
expect that simple existence of a DKIM signature will ever
be a positive in itself, at the majority of recipient mailboxes. (I'd
expect it to be a mild negative, at most places, for a range of
reasons).

> I think once we get pass that hurdle, we are pretty much covered as  

I can happily agree that it seems to be a source of conflict. :)

> DKIM into its mail system.

That's true, and has a number of implications. One is that senders
need to understand what DKIM is, and isn't, which is going to make
the marketing of DKIM as solution a bit tricky. Another is that we don't
actually know yet exactly what the implications of DKIM signature will
be. I'm pretty sure I can predict it to a couple of decimal places, but
that's different from knowing.

So some decisions might best be deferred until we've deployed DKIM
and gained some operational experience with -base.

Cheers,
   Steve

---

From: Douglas Otis <[email-masked]>
Date: Mon, 11 Sep 2006 22:26:29 -0700

> parallels is just one example). 

I agree with this point.  However, when an email-address has been
retained in a third-party list of valid identities, or within a
recipient's address-book, messages _can_ receive safe annotations not
prone to these look-alike attacks.  The annotations would be based upon
DKIM assured email-addresses compared against these retained
email-addresses.

The use of an address-book may require conventions of using pass-phrases
in initial messages.  This pass-phrase could be something the recipient
enters at a web site to ensure proper recognition when a related email
does arrive.  Once entered into the address-book, their messages can
receive proper annotations.

This is safer and simpler to administer than deciding how to triage
messages with damaged signatures and wondering how much email disappears
into the DKIM cracks.  Annotation should allow recipients to drill-down
on the related details much as with a browser annotations.

-Doug

---

From: Graham Murray <[email-masked]>
Date: Tue, 12 Sep 2006 11:20:46 +0100

> not use non-compliant mailing lists, then this is doomed to failure,

Maybe one solution to the mailing list problem would be to approach
from a different angle. Would it be possible, for verification etc
purposes, to consider mailing list traffic to have come from the
mailing list not the person who submitted to the list? So, taking this
list as an example, the checking, reputation etc would be done on
[email-masked]' not on the individual submitters. As far as
phishing is concerned, by their very nature the type of messages which
phishers spoof would not legitimately be sent via a mailing list[1] to
which the recipient has subscribed. Therefore receipt of any such
messages via a mailing list should automatically be suspect without
needing DKIM (or other checks) on the submitter.

[1] Unless it is an 'announce' type list run by the actual
organisation in which case verifying that it genuinely came from the
mailing list should give just as much confidence and trust as
verifying the RFC2821/2 entities.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Tue, 12 Sep 2006 05:41:45 -0700

On Tue, 2006-09-12 at 11:20 +0100, Graham Murray wrote:

> [email-masked]' not on the individual submitters.

Evidence that a message is from a mailing-list, or that the message has
been signed, is not apparent without examining headers that few ever
see.  Most MUAs display the From, To, CC, and Subject.  Only some
attempt to show the Sender header in some fashion.  None of these
headers are ensured to represent the actual originator of the message.

If there is to be some added annotations, what should they be?

When the DKIM header verifies, assures a specific email-address, and
this assured email-address is recognized based upon some retained
email-address via a list or address-book, mark the message accordingly.

Reputation can be considered an orthogonal issue to that of a recognized
identity. 

-Doug

---

From: John Levine <[email-masked]>
Date: 12 Sep 2006 17:17:54 -0000

>mailing list not the person who submitted to the list?

That's the only sensible approach.

When I subscribe to a list, I do so because I want mail from the list,
and I have enough confidence that whoever runs the list will take care
to manage the traffic and keep the list worth reading.  I may bozo
filter the occasional contributor, but that's because they're bozos,
not because they're forged.  Lists have all sorts of way to verify
incoming traffic, from return address validation to challenges to
manual moderation.  That's not going to change, although of course
DKIM will be a fine way to improve address validation on incoming
mail.

I have trouble envisioning a use model that demands that lists pass
through incoming signatures.  As best I can figure it out, list
managers, who have spent the last decade developing ways to keep junk
off their lists, will suddenly give up, let the spam gush through
unimpeded, and list recipients will have to do all the filtering.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Tue, 12 Sep 2006 10:40:32 -0700

>DKIM will be a fine way to improve address validation on incoming
This probably works find for small domains where you --being the mail 
admin --
know all of the lists your users subscribe to and can make some educated
guesses as to which lists are naughty and nice. From our deployment at 
Cisco,
I can say without question that I only have the vaguest idea about a very
small subset, and no clue whatsoever for lots of them. To expect that there
be a good-mailkeeping seal of approval that involves wet rather than 
software
is... unrealistic.

>unimpeded, and list recipients will have to do all the filtering.
Good thing that this is a false dilemma then.

       Mike

---

From: John L <[email-masked]>
Date: Tue, 12 Sep 2006 13:54:43 -0400 (EDT)

> This probably works find for small domains where you --being the mail admin --
> guesses as to which lists are naughty and nice. From our deployment at Cisco,
> be a good-mailkeeping seal of approval that involves wet rather than software
> is... unrealistic.

I don't know half the lists my users subscribe to, either.  But your 
argument still makes no sense to me.

Say you get mail from a thousand lists whose reputation you don't know. 
You're proposing to ignore the lists, so instead you have ten thousand 
list contributors whose reputation you don't know either.  Why is this an 
improvement?

I realize you have an exotic application where in effect you whitelist 
Cisco's mail and everything else is secondary, but I still don't see how 
it helps you decide what list mail you want.

R's,
John

---

From: "Thomas A. Fine" <[email-masked]>
Date: Tue, 12 Sep 2006 14:12:35 -0400 (EDT)

>mailing list not the person who submitted to the list?

Ohhh boy.

In Tom's perfect world, there would be two separate mechanisms being
standardized.  One would be an email-session layer mechanism that would
be based on vouching for the validity of the envelope-header and
verifying it at the destination.  Headers would be strippable in cases
of forwarding, with the forwarder taking responsibility.  It's primary
use would be for MTAs, although it could be extended a bit to provide
some utility to MUAs.  Such a system is exactly what you are describing
above, and it would have no problems whatsoever with mailing lists or
other forwarders.  It would be a policy-first system.  This would be an
easy-to-implement upgrade to the parental filtering employed by most
sites right now, and in the long run would VASTLY reduce the cost
incurred by dealing with spam.

The second mechanism would be a presentation-layer mechanism that
would be based on vouching for the From: header, that would essentially
verify the identify of the originator to the recipient.  This is
inherently a much more complicated problem to solve.  There is the
problem of mailing lists and other formatters that want to make small
or wholesale changes to content along the way.  There is the problem
of sites that want to generate mail on behalf of someone, and how
do they get the priveleges to do that.  The point here though is
to offer something to the MUA that the user can use to guide their
security choices.  If such a system wants to be robust with
respect to gateways that may alter content, then it has to fully
encapsulate the original message and separate it from the alterations,
and that by it's very nature must all happen in the body of the message.
So we would end up with something like PGP.

DKIM is trying to do both, while at the same time trying to do
neither.  It wants to be useful to both the MTA and the MUA.  It
doesn't want to authenticate either the envelope-from or the From:
lines.  It wants things to work with mailing lists (or more generally
through content transormations), but it wants to keep the signature in
the header, and (up to this point) it isn't interested in real message
encapsulation.  If anything, at this point the MTA-utility of DKIM
seems to be diminished, while at the same time, it is clinging to
header-only standards which it impossible for an MUA to present
anything useful to the user about altered messages.

         tom