Subject: [ietf-dkim] Why mailing lists should strip DKIM signatures

From: John Levine <[email-masked]>
Date: 23 Apr 2010 04:34:16 -0000

For anyone who's working on the list management BCP:

I sign all my outgoing mail, and I have a feedback loop set up with
Yahoo, which being very modern and advanced keys on signatures, not IP
addresses.  A few days ago I sent some messages to one of the Freebsd
mailing lists.  Today some Yahoo user who subscribes to that list hit
the spam button.  Freebsd's list software (Mailman, I think) doesn't
sign, and doesn't strip any headers.  So what happened?  Yahoo saw my
signature and sent the reports to me, which was of course useless
since I don't run the list.

This is not a hypothetical problem--all of my recent Yahoo FBL reports
have been for mail I sent to mailing lists elsewhere.  The lists I do
run sign their mail, and FBL reports for those lists are handled
reasonably. My scripts do what they can with this stuff, but sending
unsub commands to [email-masked] doesn't work.

R's,
John
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 23 Apr 2010 12:06:53 +0100

> since I don't run the list.

Would this still be an issue if the lists were signing the outbound mail? 
You'd hope that Yahoo would then send the feedback reports to the list 
owner.

If that's the case, then the preferred behaviour must be to sign the 
message, DKIM header included.

-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/

---

From: "John R. Levine" <[email-masked]>
Date: 23 Apr 2010 09:38:36 -0400

> You'd hope that Yahoo would then send the feedback reports to the list owner.

Probably not.  It depends if the list owner has an FBL of their own, which 
small senders generally don't.

> If that's the case, then the preferred behaviour must be to sign the message, 
> DKIM header included.

The list should certainly sign, but the old signature has to go, since the 
reputation of a list's mail belongs to the list, not the contributors.

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 23 Apr 2010 07:19:41 -0700

> This is not a hypothetical problem--all of my recent Yahoo FBL reports

If I understand correctly, you established a private arrangement with Yahoo. 
Yahoo chooses to create a unique interpretation for the presence of a DKIM 
signature, which treats it as an override to the MailFrom.  And from this, you 
are asserting a new, general rule about DKIM handling?

Better still...

 > small senders generally don't.

You are extrapolating without any data.

The problem here is that Yahoo has added some deep semantics to a DKIM signature 
and probably has not even documented or discussed it properly.

Is there some reason not to first discuss this with Yahoo?

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Fri, 23 Apr 2010 09:50:54 -0400

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of John R. Levine
> Sent: Friday, April 23, 2010 9:39 AM
> To: Ian Eiloart
> Cc: [email-masked]
> Subject: Re: [ietf-dkim] Why mailing lists should strip DKIM
signatures
> reputation of a list's mail belongs to the list, not the contributors.

John raises an interesting question. It has been asserted that signing
for a message is making an assertion of responsibility for it. 

In the example John provides, the DKIM signature survived intact (or did
Yahoo send the report through the FBL based on a broken signature?).

If John is making some assertion of responsibility for his message by
signing, what is the limit of his responsibility as the message flows
through the ecosystem? Where is the RFC that says his signature should
be stripped? If the list stripped his signature and someone modified
what he wrote is this a failure of DKIM or is it something else? What
are we collectively (and individually) trying to achieve if we are
signing the body and not just the headers? 

When the person hit the "this is SPAM" button were they referring to
John's message or were they referring to mail from the list? How do we
know?

If there were more than one valid signature on the message where would
Yahoo send the report? Where should Yahoo send the report? What if none
of the signatures are "first party"? It has been asserted multiple times
that multiple signatures are possible and perhaps even desirable.

Just a few thoughts and questions on a Friday morning.

Mike

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 23 Apr 2010 07:45:30 -0700

On 4/23/2010 6:50 AM, MH Michael Hammer (5304) wrote:
> signing, what is the limit of his responsibility as the message flows through
> the ecosystem? Where is the RFC that says his signature should be stripped?

Most importantly, where is the specification that says a DKIM signature 
overrides The MailFrom address?

> If the list stripped his signature and someone modified what he wrote is this
> a failure of DKIM or is it something else? What are we collectively (and
> individually) trying to achieve if we are signing the body and not just the
> headers?

If a list already knows it should strip DKIM signatures, isn't also likely that 
the list will be able to sign?

We have no empirical data that the presence of a list signature AND an author 
signature will produce the wrong results (for some definition of wrong.)

> When the person hit the "this is SPAM" button were they referring to John's
> message or were they referring to mail from the list? How do we know?

good questions.

> If there were more than one valid signature on the message where would Yahoo
> send the report?

We should ask Yahoo.

> Where should Yahoo send the report?

Yup.

d/
-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Fri, 23 Apr 2010 08:11:51 -0700

[grr, my ntpd keeps blowing off... sorry if this is a repost]

> are asserting a new, general rule about DKIM handling?

That is exactly my reaction: the way to deal with broken software is to
fixate and blame the pointer to the broken software? Madness lies that way.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Sun, 18 Apr 2010 11:30:04 -0700

That is exactly my reaction: the way to deal with broken software is to 
fixate and blame the
pointer to the broken software? Madness lies that way.

Mike

---

From: Jason Long <[email-masked]>
Date: Fri, 23 Apr 2010 11:00:37 -0400

> >> since I don't run the list.

Not completely useless, right? The message did come from you. If it really
was spam, sent from your account, you'd be glad Yahoo reported it to you.

> reputation of a list's mail belongs to the list, not the contributors.

I disagree. I say the reputation is partly the contributor's, partly the
list's.

--
Jason Long
http://dkimproxy.sourceforge.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: John Levine <[email-masked]>
Date: 23 Apr 2010 16:41:04 -0000

>If I understand correctly, you established a private arrangement with
>Yahoo.  Yahoo chooses to create a unique interpretation for the
>presence of a DKIM signature, which treats it as an override to the
>MailFrom.

No, of course not.  This isn't a bounce, and the user didn't press
reply.  He pressed junk.  You appear to be saying that ARF reports
about spam should be sent to the bounce address in the spam.  That
seems unlikely to be effective.

> And from this, you are asserting a new, general rule about DKIM
> handling?

Well, no.  Yahoo is doing exactly with DKIM what we've been saying
that they should do, and it's producing a useless result.

>The problem here is that Yahoo has added some deep semantics to a
>DKIM signature and probably has not even documented or discussed it
>properly.  Is there some reason not to first discuss this with Yahoo?

There's no new semantics, deep or othterwise.  Yahoo is treating the
signature as an assertion of responsibility -- it has my signature,
the recipient complained about it, they have reason to think I'm not
evil, so they sent me the complaint.  All that is fine, but the
problem is that for list mail, I'm not the one who can do anything
about it.

Mike asked how one could tell whether this was a complaint about all
mail from the list, or just mail from me.  I have my suspicions, but
I have no way to tell.  The only party who can is the human or
mechanical list manager who can look the pattern of complaints and
figure out the person is complaining about all the mail from the list,
in which case they should unsub him, or he's just comnplaining about
mail from me, in which case they might want to kick me off the list
if they agree with the complaints.

If a list adds its own signature and leaves the contributor's, now
it's up to heuristics by the recipient to guess what to do.  For list
mail, the correct guess is to treat the list as responsible.  Wouldn't
it be a better idea to avoid the guessing?

R's,
John

---

From: John Levine <[email-masked]>
Date: 23 Apr 2010 16:56:47 -0000

>John, can you simply clarify the rules/logic of your FBL with Yahoo!?
>That will clarify this scenario considerably.

It's just like the IP based FBLs that other mail systems have, only
keyed on DK or DKIM d= signing domains rather than IP addresses.  I
tell them what my d= domains are, they send reports when recipients
complain.  I expect Paypal has the same arrangement with them.  If you
don't, you should.

The terms of service are pretty typical, I can't redistribute the FBL
reports since they're unredacted, and I can use them for " (a)
reducing the incidences of your legitimate email being filtered by
Yahoo!'s spam filtering system or being marked as "spam" by Yahoo!
Mail users and (b) enforcing your spam policies."

You can see the TOS here:

http://feedbackloop.yahoo.net/tos.php

R's,
John

---

From: "McDowell, Brett" <[email-masked]>
Date: Fri, 23 Apr 2010 10:24:10 -0600

I've read through all the responses on the list but I'm responding to John's original message because so much of the responses have made critical assumptions about the nature of the FBL with Yahoo!.

John, can you simply clarify the rules/logic of your FBL with Yahoo!?  That will clarify this scenario considerably. 

________________________________________________

Brett McDowell
Technology Evangelist, Information Risk Management, PayPal

---

From: Michael Thomas <[email-masked]>
Date: Fri, 23 Apr 2010 10:09:06 -0700

> complain.  I expect Paypal has the same arrangement with them.  If you

So you're asking for feedback on mail you actually sent, but you're 
upset that
you're getting feedback on mail you actually sent. This doesn't sound 
like it has
anything to do with DKIM at all.

Mike

---

From: "John R. Levine" <[email-masked]>
Date: 23 Apr 2010 13:25:25 -0400

> was spam, sent from your account, you'd be glad Yahoo reported it to you.

Reports of mail sent through freebsd lists are completely useless, since 
there's nothing I can do with them.

Reports of mail that haven't passed through other people's list managers 
are fine, and my scripts deal with them just dandy.

> I disagree. I say the reputation is partly the contributor's, partly the

Could you produce an actual (as opposed to hypothetical) example of a 
situation where it is useful to filter list mail based on contributor 
signatures that may or may not be present?  I know that every filtering 
rule I've ever made for list mail looked for characteristics of the list.

I do the occasional bozofilter but they look at the From: line.  For 
reasons that should be obvious, once you know the mail is from the list, 
it's be much more reliable to do the bozo filtering on From: rather than 
looking for a second signature.

R's,
John

---

From: Steve Atkins <[email-masked]>
Date: Fri, 23 Apr 2010 10:06:55 -0700

> problem is that for list mail, I'm not the one who can do anything

In this particular case, for you, that's true. It's not true in general.

> it's up to heuristics by the recipient to guess what to do.  

The recipient can use heuristics, if that works for them, but
it's not the only option.

> For list
> mail, the correct guess is to treat the list as responsible.

Often. Maybe even usually. But not in all cases.

As one theoretical example, if I compromise a webmail
provider and use accounts there to sign up for yahoo groups
mailing lists, then send spam to them, then the webmail
provider is going to want to know about it.

Or if I get a b-tard infestation trolling mailing lists I'll want
to know about it.

>  Wouldn't

Yes, by notifying all the responsible parties who have set up a
DKIM based FBL and who have valid DKIM signatures on the
message.

Part of the overhead of handling an FBL is to decide which
reports to pay attention and which aren't. In your case you'd
(probably) want to ignore any reports about mail sent from
your legitimate users via mailing lists, via some heuristic that
works for you.

But you're the only one who can make that decision, so you
can't push that decision off on to Yahoo or mailing list providers
in general. I don't want them to make the decision to not
send reports to responsible parties who do want the reports
and can handle them.

It's not too hard for anyone handling inbound FBL streams
to categorize them mechanically, and automate their policies
to ignore reports they believe are irrelevant, so the overhead
for this sort of FBL report is low. If the mailing list manager strips
signatures, they lose a source of data and don't get to make
that decision.

(As for reputation - a big part of reputation is the content that
is sent. If a particular list subscriber consistently sends mail
that other list subscribers complain about then it's not
unreasonable that that may damage the reputation of that
particular list subscriber as well as that of the list.)

Cheers,
  Steve

---

From: Al Iverson <[email-masked]>
Date: Fri, 23 Apr 2010 13:06:48 -0500

> overrides The MailFrom address?

Not everything is codified in RFC or elsewhere. If John sends email to
my mailing list, and I emit that mail to the world, and it garners
complaints, it strikes me based on custom and history that I am the
responsible party. John would not be. Not directly, anyway.

> the list will be able to sign?

No, because stripping the signature is currently easier than
generating a new one. Stripping the signature is just removing text.
Adding a new signature requires functionality not inherent to all MTAs
and MLMs.

> signature will produce the wrong results (for some definition of wrong.)

Yeah, but clearly the author signature alone can cause what somebody
here thinks to be an imperfect result.

I tend to agree with him. I've been stripping DKIM signatures on my
own hosted mailing lists for that reason, and also so I can modify
content on the fly without the original signature failing.

Regards,
Al Iverson

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Fri, 23 Apr 2010 14:22:17 -0400

> [email-masked]] On Behalf Of Al Iverson
> Sent: Friday, April 23, 2010 2:07 PM
> To: [email-masked]
signatures
> through

But John made a private arrangement with Yahoo that if there was a
complaint about a mail and he DKIM signed it then Yahoo should send the
complaint to him as part of it's FBL offering. They did exactly what he
asked them to do.

> >> If the list stripped his signature and someone modified what he
wrote
> is this
> >> individually) trying to achieve if we are signing the body and not
just
> the

The fact that it is easier does not make it correct - doesn't
necessarily make it incorrect either - that's in part what the
discussion is about. So if the list strips the signature and doesn't
sign itself then John's responsibility (which he asserted) is abrogated
with no acceptance of responsibility by the list owner. Is this really a
general behavior that we want to promote? I ask this in all seriousness.

> > We have no empirical data that the presence of a list signature AND
an
> author

But are you (people we can have a reasonable expectation that we can
somewhat trust to act responsibly) the rule or are you the exception? 

I think I tend to agree with Steve. Notify all parties that assert
responsibility. That would include the author domain signer as well as
the list if they wish to accept responsibility for mail they emit.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Fri, 23 Apr 2010 11:40:39 -0700

> the list if they wish to accept responsibility for mail they emit.
I suspect that's the right answer too. What is the downside anyway? Some 
more
spurious ARF reports that you need to filter? It's not like you get out 
of *that* work
under any circumstance.

That and telling lists what they MUST do as John has pointed out over 
and over
and over is an exercise in futility. Even if he got his way here, 
nothing would change
operationally.

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 23 Apr 2010 12:20:26 -0700

> From: Murray S. Kucherawy
> Sent: Friday, April 23, 2010 12:13 PM
> To: 'MH Michael Hammer (5304)'; Al Iverson; [email-masked]
> Subject: RE: [ietf-dkim] Why mailing lists should strip DKIM signatures
> 
> Even without thinking of the FBL issues, I would want a reputation
> systems to be fully informed about a candidate system rather than only
> partially informed.

(Make that "candidate message".)

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 23 Apr 2010 12:13:02 -0700

> [email-masked]] On Behalf Of MH Michael Hammer (5304)
> Sent: Friday, April 23, 2010 11:22 AM
> To: Al Iverson; [email-masked]
> Subject: Re: [ietf-dkim] Why mailing lists should strip DKIM signatures
> 
> with no acceptance of responsibility by the list owner. Is this really
> a general behavior that we want to promote? I ask this in all
> seriousness.
> 
> [...]
> 

If I'm running a mailing list and I get a piece of signed mail, I'm certainly not removing its signature.  The signer's reputation should suffer if people complain, or benefit in the absence of a complaint.

My lists are (theoretically) generally clean, so I trust that over the long term my domain maintains a good reputation.  A receiver can therefore run both signatures, detect that one is bad (or unknown) but the other has a history of good content, and then make an appropriate conclusion.  I wouldn't want to remove that information from a receiver.

Even without thinking of the FBL issues, I would want a reputation systems to be fully informed about a candidate system rather than only partially informed.

I spoke to a couple of people about this in Anaheim: A way of using DKIM and Auth-Results to establish a definite chain of custody of a message would be highly useful.

---

From: John Levine <[email-masked]>
Date: 23 Apr 2010 20:58:29 -0000

>complaint to him as part of it's FBL offering. They did exactly what he

Indeed, and if you review my previous mail I believe you will find
that's exactly what I said.

The problem isn't that Yahoo is doing anything wrong.  The problem
is that leaving signatures on list mail leads to bogus results.

R's,
John

---

From: Al Iverson <[email-masked]>
Date: Fri, 23 Apr 2010 16:28:49 -0500

> is that leaving signatures on list mail leads to bogus results.

And complaints you can't really take action on. It's not your mailing
list, so you cannot prevent further mail to the recipient.

---

From: John Levine <[email-masked]>
Date: 23 Apr 2010 21:33:38 -0000

>If I'm running a mailing list and I get a piece of signed mail, I'm
>certainly not removing its signature.  The signer's reputation should
>suffer if people complain, or benefit in the absence of a complaint.

Well, gee, in that case since I don't control or even know the way you
manage your lists, I don't dare sign anything I send you.  If you (the
generic you, not Murray) start to do a lousy job of managing your
lists, why is that your subscribers' problem?

>systems to be fully informed about a candidate system rather than
>only partially informed.

Me too.  Mail from the list is the responsibility of the list.  QED and
all that.

>I spoke to a couple of people about this in Anaheim: A way of using
>DKIM and Auth-Results to establish a definite chain of custody of a
>message would be highly useful.

Hmmn. Was this in the context of mailing lists, or in general?  When
I've asked for examples of how this would be useful for list
subscribers, all I've heard is an implausible example of a list that
is so poorly managed that it's full of spam, and the list owner isn't
willing to do anything about it, but for some reason people want to
subscribe to it anyway.

I could see how a chain of custody would be useful for something like
a courtesy forward that downcoded MIME from 8bit to base64, or one
that added a tag or advertisement to mail as it went through.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Fri, 23 Apr 2010 15:03:40 -0700

> list, so you cannot prevent further mail to the recipient.

Sure you can. If one of your users is spamming, this would be interesting
too. The problem here is that John apparently doesn't like the service that
Y! provides, and instead of taking that up with Y! he's decided to blame it
on DKIM.

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 23 Apr 2010 15:28:43 -0700

> From: John Levine [mailto:[email-masked]]
> Sent: Friday, April 23, 2010 2:34 PM
> Cc: Murray S. Kucherawy

If you begin to get complaints because you are on some list whose owner isn't bothering to conduct list hygiene, I would imagine you'd ultimately unsubscribe from the list and find or create another one that's properly managed.  And I imagine a lot of other members of that list would follow, even if only because you all also find the overall list's content to be irritating.

In terms of reputation systems that might rely on DKIM, I doubt a single incident would or should be enough to clobber your reputation entirely.  And in fact I'd want my good content to hit some lists signed so that more receivers get a chance to collect data that I'm a good guy.

I don't think it's a big stretch to think as reputation rolls out, people will be more discerning about how and where they send mail.

> Me too.  Mail from the list is the responsibility of the list.  QED and

But if you redact the original signature, you're only providing some of the information that could be provided to the receiver.

> Hmmn. Was this in the context of mailing lists, or in general?

Lists, specifically, in that instance.  Something like: X sends to a list at Y that then relays to Z; Z trusts Y to implement DKIM and Authentication-Results and all that properly, so Z believes Y when it says "X had a signature on here that verified" even if X's signature on arrival at Z is either invalid or absent.

---

From: "John R. Levine" <[email-masked]>
Date: 23 Apr 2010 19:04:03 -0400

> If you begin to get complaints because you are on some list whose owner 
> isn't bothering to conduct list hygiene, I would imagine you'd 
> ultimately unsubscribe from the list and find or create another one 
> that's properly managed.

I am about 99% certain that the FBL reports that started this discussion 
were either a guy who wanted to unsub from the list, or he reported his 
whole inbox.  Nearly all of the FBL reports I get are one or the other, 
but this was the first time I got them for someone else's list.  As I 
believe I said, it didn't break anything here, but it was a useless 
transaction, and for a small site like mine that has users who belong to a 
lot of lists, it could easily dominate FBL traffic.

Or to put it another way, it scales poorly since the amount of traffic 
depends on the number of other subscribers, not on anything under your own 
control.  For something like Dave Farber's IP list, with hundreds of 
thousands of subscribers, the number of bogus reports per message sent 
could become large.

On the third hand, in practice, this is unlikely to be a big deal, since 
it is my impression that in the world at large, the number of lists (as 
opposed to courtesy forwards) that don't break the signature is 
insignificant.  But I think it is of interest to try and figure out where 
the responsibility belongs for list mail, other than "everywhere", and 
what to recommend to people to make that easy to implement.

> But if you redact the original signature, you're only providing some of 
> the information that could be provided to the receiver.

Well, yes, leaving out irrelevant info avoids misleading them.  More info 
is not necessarily better, particularly in a situation like this where a 
recipient doesn't know the order or relationship of multiple signatures 
unless it has separate knowledge about the parties involved.

> Lists, specifically, in that instance.  Something like: X sends to a 
> list at Y that then relays to Z; Z trusts Y to implement DKIM and 
> Authentication-Results and all that properly, so Z believes Y when it 
> says "X had a signature on here that verified" even if X's signature on 
> arrival at Z is either invalid or absent.

This returns us to the original question.  Other than the implausible 
scenario of a system that is managed well enough to maintain the chain of 
signature headers, but that makes no attempt to keep spam out of its 
lists, in what scenario would this be of practical use in managing Z's 
mail?  If Z trusts Y, why wouldn't it be sending reports about Y's lists 
to Y?

People have been saying since the dawn of DKIM that they want to see the 
incoming signatures on list mail, but I have yet to hear a plausible story 
about what to do with them.  As far as I can tell, it's just an unexamined 
assumption that more signatures must be better, or that they as the 
original signer will then somehow be able to tell recipients what to do.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 23 Apr 2010 16:26:58 -0700

> From: John R. Levine [mailto:[email-masked]]
> Sent: Friday, April 23, 2010 4:04 PM
> To: Murray S. Kucherawy

Unfortunately I expect there to be a level of noise to which we'll just have to become accustomed.  This is probably already true in the FBL world anyway.  There might be ways to reduce or filter it but any design work I do will expect some.

> unless it has separate knowledge about the parties involved.

Although you seem to have concluded so already, I don't agree that it's irrelevant data.  Some verifiers might want to see both as a matter of local policy, and maybe there's an algorithm out there that would work in the majority of cases which requires access to all of the signatures.  Absent a proof one way or another, I'll opt for making more information available.

> mail?  If Z trusts Y, why wouldn't it be sending reports about Y's

The question I was discussing wasn't about where to send abuse reports, it was about whether or not to believe what was claimed by the authentication data Y sent to Z.  If Y says it saw a signature from X that validated, should Z believe that claim or not?

> original signer will then somehow be able to tell recipients what to

I think you nailed it: It's an unexamined assumption.  But so, to me at least, is the assertion that an author signature to a list is a bad idea for senders and will only serve to confuse verifiers.  I'd like to see some data collected from such systems before I'm willing to agree or disagree with either perspective.  And until then, I don't want to exclude anything.

A favourite example of mine: A DKIM signature with an "l=" passes the DKIM module, but the verifier makes use of hooks into the module that allow it to discover the message quadrupled in size after signing.  As a result, it quarantines the message, as required by local policy.  That's more information than RFC4871 requires the DKIM module to provide, but it served a useful purpose.

Another: A DKIM signature arrived and validated, but failed to cover the Subject: header field.  The receiver discovers this and disallows the message (or filters it differently) due to local policy that's concerned with a change to what would appear in an inbox summary.  Again, it's more information than is required, but it's useful.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 23 Apr 2010 17:44:06 -0700

> thousands of subscribers, the number of bogus reports per message sent
IMHO, John is right, but this runs counter to desires of many providers 
who want someone else to blame for their failure to act.   This would be 
analogous to moving accountability for a traffic accident to a vehicle 
in front, which would be just as wrong.  In the case of a mailing list, 
John is not deciding where a message is sent beyond the mailing list, 
just as John can not apply the brakes of a following vehicle.  Being 
required to stop irrespective of the actions of a vehicle in front 
represents a workable method for accountability.  The same is true with 
email, as distribution represents the overriding aspect of email 
accountability, respective of any auth-header-chain.  Unfortunately, 
poorly considered desires of passing blame up, caused the neglect of 
capturing the IP address of the last provider which would help identify 
those at fault for failing to stop.

-Doug

---

From: John Levine <[email-masked]>
Date: 24 Apr 2010 02:19:09 -0000

>I think you nailed it: It's an unexamined assumption.  But so, to me
>at least, is the assertion that an author signature to a list is a
>bad idea for senders and will only serve to confuse verifiers.  I'd
>like to see some data collected from such systems before I'm willing
>to agree or disagree with either perspective.  And until then, I
>don't want to exclude anything.

I have to agree that more data could be helpful.  You have mine, where
the retained signature isn't.

>A favourite example of mine: A DKIM signature with an "l=" ...

>Another: A DKIM signature arrived and validated, but failed to cover
>the Subject: header field. ...

The DKIM spec certainly provides ample opportunity for signers to do
silly things.  If we're doing a BCP, it might be useful to suggest
situations where a technically valid DKIM signature probably isn't
useful, with these two examples, l= that doesn't cover the whole
message and unsigned subject, being good examples.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 24 Apr 2010 16:14:26 +0200

> The question I was discussing wasn't about where to send abuse reports, it was about whether or not to believe what was claimed by the authentication data Y sent to Z.  If Y says it saw a signature…

Z should not. Consider: Y verifies X's signature, writes an A-R line, 
and signs it. Later on, Z verifies Y's signature. However, Z's A-R 
will not repeat all of Y's resinfos: Although Z has verified that Y's 
A-R is pristine, it doesn't take the responsibility of reasserting 
those claims, even at the cost of significantly increasing the 
complexity of consuming Y's A-R downstream.

Likewise, unless a Z's user has specifically mentioned "Y" in her 
trust settings --which is unlikely-- any software acting on her behalf 
cannot automatically derive the confidence to assert that the message 
has a valid author signature.

>>  People have been saying since the dawn of DKIM that they want to see the incoming signatures on list mail, but I have yet to hear a plausible story about what to do with them.
>
> I think you nailed it: It's an unexamined assumption.  But so, to me at least, is the assertion that an author signature to a list is a bad idea for senders and will only serve to confuse verifiers.

Author signatures are special because the content of the "From" field 
is displayed to recipients. Even if many lists claim copy rights et 
cetera, the moral responsibility of a message rests with its author. I 
think that's why rfc4871 gives the "From" field foremost importance.

The /visibility/ of a mailing list consists of tagging the "Subject", 
and possibly being delivered to a specific folder. Perhaps, list 
signatures should be liken to author signatures in this respect. (Is 
the relationship between "List-ID" and the tag standardized?)

> A DKIM signature with an "l=" passes the DKIM module, but [...]

Some servers rewrite MIME boundaries or prologue. I'm planning to set 
"l=0" for all but text/plain messages.

> A DKIM signature arrived and validated, but failed to cover the Subject: header field.

I don't sign the subject, so as to let mailing lists tag it as required.

In facts, in-transit tampering is not something I've seen very often. 
Comparing their frequency with that of abused domain names in the 
"From" field, they are negligible.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Al Iverson <[email-masked]>
Date: Sat, 24 Apr 2010 16:07:01 -0500

> Y! provides, and instead of taking that up with Y! he's decided to blame it

If you subscribe to a mailing list and post to it, that's a far cry
from a bulk distribution of unwanted mail. I'm not sure that any sort
of report like that would ever establish that a user is spamming. If
the user is posting objectionable content to a list, the immediate
resolution is for the list manager to remove that subscriber. So,
we're back to, it should go to the list manager, not the originating
ISP. I would find it useless for it to go back to the original
person's ISP by way of an FBL because I would not be able to find it
actionable. Why? Because there was distribution of the email in
question outside of the control of the original sender. I guess that's
what it boils down to for me. If a message is being re-distributed
outside of my control, ala how discussion lists work, I don't think I
am any longer the responsible party as far as a spam report goes.

I'm not grok'ing a scenario where that report would help you find
somebody who is spamming. I'm open to listening, though. What's an
example scenario where you would find that useful?

Regards,
Al Iverson

---

From: John Levine <[email-masked]>
Date: 25 Apr 2010 00:03:31 -0000

>> The problem here is that John apparently doesn't like the service
>> that Y! provides, and instead of taking that up with Y!  he's
>> decided to blame it on DKIM.

Well, no.  Please review my previous messages on this topic, and try
and read all the words.

R's,
John

---

From: Tony Hansen <[email-masked]>
Date: Sun, 25 Apr 2010 19:12:48 -0400

I found this part of Allessandro's message somewhat scary. I thought we 
got past the point where l=0 was considered a viable option for anyone 
to use?

     Tony Hansen

On 4/24/2010 10:14 AM, Alessandro Vesely wrote:
> ...

---

From: Steve Atkins <[email-masked]>
Date: Sun, 25 Apr 2010 17:26:31 -0700

> got past the point where l=0 was considered a viable option for anyone 

Unless receivers treat any DKIM signature with an l= field as an
unsigned message (or as a sign of email that should be rejected
altogether) then l=0 is a viable option for senders to use.

Cheers,
  Steve

---

From: John Levine <[email-masked]>
Date: 26 Apr 2010 01:14:02 -0000

>altogether) then l=0 is a viable option for senders to use.

I'm willing to accept a signature with l= so long as it covers the
entire message.  I agree that partial coverage is not practically
distinguished from no coverage.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 26 Apr 2010 10:16:52 +0200

On 26/Apr/10 03:14, John Levine wrote:
> I'm willing to accept a signature with l= so long as it covers the entire message.  I agree that partial coverage is not practically distinguished from no coverage.

I note you refer to /current/ --rather than possible or commendable-- 
practice: l=0 certifies "From:" across multiple hops, while attempts 
to also certify MIME prologues may result in broken signatures. IMHO, 
it is broken signatures that are not _practically_ distinguishable 
from no coverage.

---

From: John Levine <[email-masked]>
Date: 26 Apr 2010 13:59:45 -0000

>practice

Sorry, I don't understand what you're trying to say.

Partial body coverage allows all sorts of sneaky tricks that make the
body presented to the user completely different from that the sender
signed.  l=0 screams "phish me", attach a fake body to a genuine
signed set of headers.

We hashed all this out in excruciating detail on this list a year or
two ago, so please review the archives.

R's,
John

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 26 Apr 2010 10:05:01 -0400

I think we are having the wrong discussion. The real question is:

"What are appropriate practices for mailing lists in handling DKIM
signed mail?"

By focusing on John and his single example we are looking at a tree and
not the forest. This may not be the best way to extrapolate recommended
best practices.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 26 Apr 2010 07:13:48 -0700

> not the forest. This may not be the best way to extrapolate recommended

I agree except for one thing: mailing list traffic doesn't even make it
to .02% for the 20-80 rule. The proper thing is to ignore pleas for outlier
turd polishing.

Mike

---

From: "McDowell, Brett" <[email-masked]>
Date: Mon, 26 Apr 2010 11:19:48 -0600

> "What are appropriate practices for mailing lists in handling DKIM

Agreed.

>From my perspective, I'd like to enable (not mandate or expect universal compliance with) the deployment scenario where the sender's DKIM signature is either maintained without adulteration or "proxied" by the list so the transient trust can be carried through the mailing list intermediary to the destination (per Murray's note which I'm also going to respond to).  That's my use case.  By sharing this use case I'm not trying to deprecate or undermine John Levine's original use case.  But there is a diversity of valid/appropriate behavior by mailing lists vis-a-vis DKIM that we need to consider (which is why I'm so pleased to see Mike H. take our discussion in this direction).

-- Brett

---

From: "McDowell, Brett" <[email-masked]>
Date: Mon, 26 Apr 2010 11:26:25 -0600

> complain.  I expect Paypal has the same arrangement with them.  If you

First off, thank you for clarifying this John.

As for PayPal, we have a different relationship with Yahoo! that better addresses our needs:

https://www.thepaypalblog.com/2007/10/yahoo-paypal-an/

Our motivation is consumer protection.  

> http://feedbackloop.yahoo.net/tos.php

Granted, this is a nice service for monitoring recipient behavior vis-a-vis the spam button, thus helping you enforce your spam policies.  I'm sure we do something similar, but that's not my department nor where I think DKIM really flexes it's muscle.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 26 Apr 2010 11:01:38 -0700

> From: McDowell, Brett [mailto:[email-masked]]
> Sent: Monday, April 26, 2010 10:37 AM
> To: Murray S. Kucherawy
> Cc: John Levine; [email-masked]
> Subject: Re: [ietf-dkim] Wrong Discussion - was Why mailing lists
> should strip DKIM signatures
> 
> Murray, is this what you discussed supporting in IETF #77?  If yes,
> what's the status?

Yes, that's what I was discussing at IETF 77, but it wasn't discussed in any formal context.  I was just floating the idea with some possibly interested parties.  I do expect it to gain momentum though as interest in the idea increases.

---

From: "McDowell, Brett" <[email-masked]>
Date: Mon, 26 Apr 2010 11:36:30 -0600

On Apr 23, 2010, at 6:28 PM, Murray S. Kucherawy wrote:

> Something like: X sends to a list at Y that then relays to Z; Z trusts Y to implement DKIM and Authentication-Results and all that properly, so Z believes Y when it says "X had a signature on here that verified" even if X's signature on arrival at Z is either invalid or absent.

That's interesting.  Let's make this concrete... I'll use myself as an example.

X = me/PayPal.com
Y = this list/[email-masked]
Z = Google's Gmail service [1]

It is my assumption that someone subscribed to this list has a gmail.com account (or a Yahoo.com account [2]).  Therefore, my use case is simple.  I would hope that those of you reading this from your Gmail or Yahoo! accounts actually receive this message.  If Z breaks the signature, you won't see this.

So if it simply isn't practical to expect lists to maintain the signature, then offering the option for the list to validate the signature coming from X and send a new signature to Z that Z *can* (but doesn't have to) "trust", is something immediately useful.

Murray, is this what you discussed supporting in IETF #77?  If yes, what's the status?

-- Brett

[1] https://www.thepaypalblog.com/2008/07/google-joins-th/
[2] https://www.thepaypalblog.com/2007/10/yahoo-paypal-an/
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Mon, 26 Apr 2010 11:39:18 -0700

> So if it simply isn't practical to expect lists to maintain the signature, then offering the option for the list to validate the signature coming from X and send a new signature to Z that Z *can* (…
Brett,

Is there interest in a scalable mechanism able to selectively endorse 
any number of mailing-lists known by the d=domain as safely relaying 
headers and body content?

This scheme could use the tpa-label conventions, where domains such as 
PayPal.com could publish a CNAME to a domain containing hash lists of 
mailing-lists vouched for by the domain being pointed to by the CNAME?  
The tpa-label itself could narrow the endorsements for specific types of 
messages of messages as well.

The CNAME at the tpa-label location could point to something like:
safe-mailing-lists.vouching-service.org.

In this way, special arrangements are not needed for those wishing to 
use a restrictive ADSP.  This could then avoid disrupting reputable 
mailing-lists.

If there is any interest, the tpa-label draft could be pursued 
individual submission, so I understand.

-Doug

---

From: "J.D. Falk" <[email-masked]>
Date: Mon, 26 Apr 2010 14:24:56 -0600

> not the forest. This may not be the best way to extrapolate recommended

Agreed.  Absolutely.

Another real question, equally important: who is actually writing this BCP?

--
J.D. Falk <[email-masked]>
Return Path Inc

---

From: John Levine <[email-masked]>
Date: 27 Apr 2010 03:55:38 -0000

"Doctor, it hurts when I do this."

"So don't do that."

>Z = Google's Gmail service [1]

I understand your point, but I think that it would be a better idea to
put Paypal's transactional mail and mail from its staff into different
domains with different reputations and different handling.  If you're
telling recipients to throw away paypal.com mail with missing or
broken signatures, your messaging is going to be vastly more confusing
and harder to follow if you add "oh, except for these special cases
for stuff passed through mailing lists, and be sure only to do the
special cases for real mailing lists."  "No, we don't have a list of
every real mailing list in the world.  Why do you ask?"

Or to look at it another way, if a piece of mail arrives from some
random mailing list like thing with a paypal.com return address, and a
header that purports to say that the message was signed when it
arrived at the list, how likely is it that it's mail from you vs. mail
from a phish kit trying to fake out verifiers?

R's,
John

PS: Not to pick specifically on Paypal, but you are of course the
poster child for phish targets so egregious that it's worth the risk
of losing a little real mail to get rid of the phish.

PPS: [email-masked] would be a much cooler address
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Tony Hansen <[email-masked]>
Date: Tue, 27 Apr 2010 02:20:10 -0400

Is it something that would make sense to add to the Development, 
Deployment and Operations document?

     Tony

---

From: Jeff Macdonald <[email-masked]>
Date: Tue, 27 Apr 2010 11:02:08 -0400

> think that's why rfc4871 gives the "From" field foremost importance.

Are you sure you got the right RFC here?

--
Jeff Macdonald
Ayer, MA

---

From: John Levine <[email-masked]>
Date: 27 Apr 2010 15:06:25 -0000

>Deployment and Operations document?

It would probably be better to keep it separate, since it's likely to
be more contentious than everything else in that document combined.

Oh, and I'll write it, just not this week.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Tue, 27 Apr 2010 08:13:10 -0700

> Oh, and I'll write it, just not this week.

I'd suggest that the author should be outside of the set of contenders.

Mike

---

From: Jeff Macdonald <[email-masked]>
Date: Tue, 27 Apr 2010 11:45:45 -0400

> John, can you simply clarify the rules/logic of your FBL with Yahoo!?  That will clarify this scenario considerably.

I was almost ready to agree with John here, but then I recalled
Brett's message*. I use gmail and the rules/filters features. Had I
not selected the "do not put into spam" option for the rule for this
list, Brett's message would of gone into the spam folder. I wondered
why.

I'm sure Brett can elaborate, but I believe ebay/paypal has an
agreement with some ISPs about unsigned email. I believe this is a
back door agreement and not the major ISPs honouring policy
statements. But I see that Paypal has a DomainKey policy too and that
they sign everything:

$ host -ttxt _domainkey.paypal.com
_domainkey.paypal.com descriptive text "o=-"

I don't know if this list strips signatures or not. The only signature
present was the list's DKIM signature.

Now, John's desire for mailing lists to strip signatures would mean
strict policy statements would fail. So this either highlights:

1) policy statements are futile
2) mailing lists are broken anyway
3) the importance of RFC5322From is overrated

* if you didn't see Brett's message, check your spam folder. I replied
using his message as a base.

-- 
Jeff Macdonald
Ayer, MA

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 27 Apr 2010 11:55:59 -0400

> [email-masked]] On Behalf Of Michael Thomas
> Sent: Tuesday, April 27, 2010 11:13 AM
> To: John Levine
should
> strip DKIM signatures
> >>> Another real question, equally important: who is actually writing
this
> BCP?

I would suggest several authors.

While I appreciate and respect John's perspective, I think there are
other cases besides phishing which he has not considered. 

Misinformation and damage to reputation are two that come to mind. The
fact that a domain (or author within a domain) wishes to protect
themselves by signing what they write should not be discounted. This
should be true even (or particularly) when what they write or emit
passes through a mail list. 

I get the sense that some discount what is communicated to/through a
list compared to what is sent directly. I'm not sure why that is so.

Mike

---

From: John Levine <[email-masked]>
Date: 27 Apr 2010 16:24:10 -0000

>Oh, and I'll write it, just not this week.

PS: I am a lazy guy and would be delighted to split the work with all
the other volunteers.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "John R. Levine" <[email-masked]>
Date: 27 Apr 2010 12:34:56 -0400

> passes through a mail list.

It just doesn't seem realistic to expect to be able to use contributors' 
signatures for list mail for a variety of reasons.

Most lists will break signatures, for a variety of reasons that aren't 
going to change, starting with subject line tags.  If the signature is 
broken, you need something else so the list can assert that a message was 
signed when it arrived.  But such assertions are only credible if the list 
itself is trustworthy.  If you already know you trust the list, how much 
practical benefit is there to the assertion?

How often have you gotten mail from a real list with a faked sender?  (In 
my experience, never other than a few obvious jokes.)  And if that is a 
problem, rather than adding stuff to let list members detect the fake, why 
wouldn't it be better for the list to do it and not accept faked mail in 
the first place?

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 27 Apr 2010 09:52:18 -0700

> [email-masked]] On Behalf Of John Levine
> Sent: Tuesday, April 27, 2010 9:24 AM
> Subject: Re: [ietf-dkim] mailing list doc, was Wrong Discussion - was
> Why mailing lists should strip DKIM signatures
> 

I've already got a skeletal one started.  Chairs, can we make this a WG document?

---

From: Jeff Macdonald <[email-masked]>
Date: Tue, 27 Apr 2010 13:05:03 -0400

damn MUAs for not being consistent for threading - see my other
message in the other thread as it is related to this one:

> It is my assumption that someone subscribed to this list has a gmail.com account (or a Yahoo.com account [2]).  Therefore, my use case is simple.  I would hope that those of you reading this from y…

how about Y breaking the signature? I see your message only because I
told gmail's filtering system to not put messages into the spam folder
for this list. Otherwise it would of gone into the spam folder.
Looking at the source of the message, I only see the list's DKIM
signature.

> So if it simply isn't practical to expect lists to maintain the signature, then offering the option for the list to validate the signature coming from X and send a new signature to Z that Z *can* (…

Should the policy statements be ignored at that point?

-- 
Jeff Macdonald
Ayer, MA

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 27 Apr 2010 10:34:06 -0700

> From: Jeff Macdonald [mailto:[email-masked]]
> Sent: Tuesday, April 27, 2010 10:05 AM
> To: McDowell, Brett
> Cc: Murray S. Kucherawy; [email-masked]
> > It is my assumption that someone subscribed to this list has a
> gmail.com account (or a Yahoo.com account [2]).  Therefore, my use case
> is simple.  I would hope that those of you reading this from your Gmail
> or Yahoo! accounts actually receive this message.  If Z breaks the
> signature, you won't see this.
> 

Y breaking the signature isn't relevant (in this hypothesis).  Y also says when it got the message from X, X's signature was intact.  That Y messed up the signature, making Z unable to verify it directly, is not important; Z trusts Y, so Z trusts Y's Authentication-Results: that says X's signature was fine when it got to Y.

> Should the policy statements be ignored at that point?

In this hypothesis, they could be.  Or, they could be applied.  If X's ADSP says "all" or "discardable", and Z trusts Y, and Y claims X's message had a valid signature, ADSP is satisfied.

---

From: "McDowell, Brett" <[email-masked]>
Date: Tue, 27 Apr 2010 11:40:46 -0600

> In this hypothesis, they could be.  Or, they could be applied.  If X's ADSP says "all" or "discardable", and Z trusts Y, and Y claims X's message had a valid signature, ADSP is satisfied.

That's how I see it.  The key is that Y *validates* the DKIM signature and processes the sender's ADSP when it receives the message before taking it's next action.  If Y didn't actually validate with comparable rigor as Z, then Z would have no basis to trust mail from Y.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 27 Apr 2010 10:50:54 -0700

On 4/27/2010 10:40 AM, McDowell, Brett wrote:
> That's how I see it.  The key is that Y *validates* the DKIM signature and
> processes the sender's ADSP

Where is this going to be supported?  That is, how widespread does anyone 
believe that support for this scenario will be?  Why?

d/
-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 27 Apr 2010 10:53:29 -0700

> is that leaving signatures on list mail leads to bogus results.

It is bogus for a random mailing list manager to retain something it knows 
nothing about?

Yahoo has imposed its own, private rules.  That's fine, but it does not suddenly 
create a conformance burden on actors that were previously performing valid 
actions (and valid INactions).

d/

-- 

   Dave Crocker

---

From: "McDowell, Brett" <[email-masked]>
Date: Tue, 27 Apr 2010 12:08:19 -0600

> believe that support for this scenario will be?  Why?

I'm not sure if you were asking this as a rhetorical question in an attempt to imply that such adoption would be low, or if you actually expected some of us who may have non-public knowledge of such plans to disclose them to this public mail list, or if you were soliciting speculation.  In any event, I can only speculate. 

But since both Yahoo! and Google already validate DKIM and (with certain senders anyway) enforce "discardable", it's no great stretch of the imagination that they might support something like what we've articulated above for their Google Groups/Yahoo! Groups services.  

Why might they do it?  For all the same reasons they do DKIM blocking today... whatever those reasons may be.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 27 Apr 2010 20:27:52 +0200

> Sorry, I don't understand what you're trying to say.

Please excuse my poor English...

> signed.  l=0 screams "phish me", attach a fake body to a genuine

I wish there were ways to know how often does that happen.

At any rate, all what I'm trying to say is that a few certified 
fields, e.g. "From:", "To:", and "Date:", are more useful than a 
broken signature, in most cases.

> two ago, so please review the archives.

Good hint. However, you were already saying so in Aug 2005:

  We definitely had this argument before.  You cannot expect signatures
  to survive mailing lists (as opposed to courtesy forwards) unless you
  loosen the signing algorithm to the point that it will accept
  mutations that people wouldn't consider to be the same message, e.g.,
  adding new MIME parts.
  http://mipassoc.org/pipermail/ietf-dkim/2005q3/000274.html

Criticism toward approaches that are too tight to be practical has 
been raised before. Let me quote Eric Rescorla from Oct 2005:

  A related issue is the focus on forgery as the end-goal. The reason
  that people are interested in stopping forgery is that they
  believe that that can be used to block spam (see Section 2, where
  this is explicitly stated). Indeed, if what you wanted to do
  was stop message forgery as a general case, you would have to
  consider the issue of forgery by other authorized users in
  the same administrative domain, which generally leads to an
  S/MIME style solution.
  http://mipassoc.org/pipermail/ietf-dkim/2005q4/001090.html

That was also considered "very late in the day", and he replied to 
such comment like so:

  Huh? I raised these issues at the first MASS BOF and again at the
  DKIM BOF in Paris. It's hardly my fault that they've never been
  addressed adequately. That said, I don't see what fair has to
  do with it. Either DKIM will do something useful or it won't,
  and that's independent of the time when the question of its
  usefulness was raised.
  http://mipassoc.org/pipermail/ietf-dkim/2005q4/001124.html

Further answers were concerned about chartering issues, grand 
opinions, reputation systems, World Hunger, and similar nuisances...

I haven't been able to track when has it been decided that DKIM is not 
MIME-conformant. I'd agree that it's a bit late to introduce, say, 
separate signatures for each entity. It doesn't seem too late to add a 
mellowed out canonicalization, though. It could loosely take into 
account MIME, considering that some servers add or drop some 
attachments, and possible conversions. Very inappropriate for bank 
transactions, but unbreakable. Would that be feasible? If not, l=0 is 
the only practical setting for multipart messages, IMHO.

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 27 Apr 2010 20:31:56 +0200

On 27/Apr/10 17:02, Jeff Macdonald wrote:
> On Sat, Apr 24, 2010 at 10:14 AM, Alessandro Vesely<[email-masked]>  wrote:

Yup:

  The From header field MUST be signed (that is, included in the "h="
  tag of the resulting DKIM-Signature header field).
  http://tools.ietf.org/html/rfc4871#section-5.4

(see also http://tools.ietf.org/html/rfc4686#section-4.1.15)
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 27 Apr 2010 11:32:03 -0700

On 4/27/2010 11:08 AM, McDowell, Brett wrote:
>>> That's how I see it.  The key is that Y *validates* the DKIM signature
>>> and processes the sender's ADSP
>>
> I'm not sure if you were asking this as a rhetorical question in an attempt
> to imply that such adoption would be low, or if you actually expected some of
> us who may have non-public knowledge of such plans to disclose them to this
> public mail list, or if you were soliciting speculation.  In any event, I can
> only speculate.

I meant the question quite seriously.

When trying to specify anything, it's important to be clear about who is the 
target for adopting it and how motivated they will be and how feasible adoption 
will be within a useful timeframe.

If the specification is only intended for Yahoo and Google and there are good 
signs they will adopt it, then fine.

If the goal is broader adoption, then Yahoo and Google can actually be 
misleading examples, since they are not representative of the wider mailing list 
management software or operations community.

d/
-- 

   Dave Crocker

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 27 Apr 2010 20:43:47 +0200

On 27/Apr/10 18:34, John R. Levine wrote:
> going to change, starting with subject line tags.

Couldn't that be standardized, or taken into account using the List-* 
headers?

>   If the signature is
> itself is trustworthy.

You mean DKIM-enabled?

> If you already know you trust the list, how much practical benefit is there to the assertion?

None. But lists who don't require DKIM to accept posts may happen to 
publish occasional forgeries.

BTW, are there lists that require DKIM "pass" to accept posts?
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "McDowell, Brett" <[email-masked]>
Date: Tue, 27 Apr 2010 12:48:24 -0600

Who do you feel we need to hear from at this stage to gauge interest?  

-- Brett

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 27 Apr 2010 11:57:33 -0700

> Who do you feel we need to hear from at this stage to gauge interest?

For any specification, it helps to hear from the folks who will write the 
software and from the folks who will deploy and use it.

"If we specify it, they will come" is a very risky approach to standards making. 
  c.f, <http://trac.tools.ietf.org/misc/outcomes/>.

d/

-- 

   Dave Crocker

---

From: "McDowell, Brett" <[email-masked]>
Date: Tue, 27 Apr 2010 13:04:36 -0600

> software and from the folks who will deploy and use it.

But I interpreted your earlier comment as indicating that Google and Yahoo were irrelevant and/or non-representative for the sake of this exercise.  But they write code and deploy mail systems that touch hundreds of millions of people.  So I'm trying to understand who you would consider relevant and representative for the sake of gauging interest in this use case.  

I'd be happy to talk to them about it, once I know who they are.

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 27 Apr 2010 12:11:02 -0700

On 4/27/2010 12:04 PM, McDowell, Brett wrote:
> But I interpreted your earlier comment as indicating that Google and Yahoo
> were irrelevant and/or non-representative for the sake of this exercise.

I think the confusion is the difference between hearing individual examples, 
versus extrapolating them to the larger community.  Yahoo and Google are 
important and useful.  But they are not representative.

> So I'm trying to understand who you would consider relevant and
> representative for the sake of gauging interest in this use case.

There is a large world of people who develop MLM software and a much larger 
world of people who operate MLM services.  If we are specifying rules for them, 
it would help to hear from them, that they are interested in implementing what 
we direct them to implement.

Since I haven't been the one espousing change for MLMs, I'm hesitant to be the 
one to try to specify who folks want to have implement this.

d/
-- 

   Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Tue, 27 Apr 2010 12:18:27 -0700

On 4/27/10 10:34 AM, Murray S. Kucherawy wrote:
>>> That's interesting.  Let's make this concrete... I'll use myself as
>>>        
>> an example.
>>      
>>> X = me/PayPal.com
While messages with intact DKIM signatures of financial institutions 
offers reasonable protection, acceptance of broken signatures validated 
by some third-party's authentication-results header would impose 
significant risk.    Any mailing list that does remove 
authentication-results headers would provide easy exploits of X.
> In this hypothesis, they could be.  Or, they could be applied.  If X's ADSP says "all" or "discardable", and Z trusts Y, and Y claims X's message had a valid signature, ADSP is satisfied.
Acceptance of DKIM messages signed by Y is likely to be less strict than 
those by X, and likely to overlook broken signatures or lack of 
authentication-results headers.  However, an authorization scheme able 
to scale to any number of such lists using a single DNS transaction 
ensures X remains in control of the acceptance of their messages, 
without needing special private arrangements for making specific exceptions.

Since X has the most at stake, an authorization scheme would allow X to 
indicate which ADSP acceptance exceptions are desired.  The indication 
could be made on behalf of X through some designated vouching service, 
or directly by X when they they have audited the domains being used by 
them.  The ADSP record could include a flag to alert recipients of the 
existence of an added third-party authorization mechanism.

-Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 27 Apr 2010 12:24:13 -0700

> [email-masked]] On Behalf Of Douglas Otis
> Sent: Tuesday, April 27, 2010 12:18 PM

True, if you ignore the main point that got this started: Z trusts Y to do authentication properly and make correct assertions via Authentication-Results.  The "trust" here has been established out-of-band.  In essence, then, Z treats what Y is saying as always true because of some audit that was done on the work done at Y.

I didn't suggest this should be generally true.

---

From: "McDowell, Brett" <[email-masked]>
Date: Tue, 27 Apr 2010 13:29:25 -0600

So Murray... you mentioned you started talking to folks about this use case at IETF 77.  Were any of them MLM vendors or service providers?  

Are there MLM vendors or service providers on this list who feel they know enough about this use case at this point to have a firm position either for or against standardizing this functionality?

Speaking for myself (as neither a MLM vendor or service provider), I found Murray's use case interesting and could see how such functionality might plug a current hole in the DKIM fabric.  I also see immediate applicability for our PayPal customers.  But I don't know enough about the use case or the potential solution to make a firm commitment one way or the other right now.  All I'm saying is that it seems worth exploring further.  

Dave seems to be seeking confirmation of interest from MLM vendors and service providers at this early stage in order to continue to develop the concepts.  

So... is there any other interest in this scenario... form MLM vendors or service providers?

-- Brett

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 27 Apr 2010 12:34:48 -0700

> [email-masked]] On Behalf Of McDowell, Brett
> Sent: Tuesday, April 27, 2010 12:29 PM
> To: [email-masked]
> So Murray... you mentioned you started talking to folks about this use
> case at IETF 77.  Were any of them MLM vendors or service providers?

I don't think I know any MLM vendors, other than Yahoo and Google who have their respective MLM ("groups") services.

The parties with whom I discussed the idea were general technologists and specification types, just to get some idea of what some first steps might be in the IETF and R&D contexts.

---

From: Jeff Macdonald <[email-masked]>
Date: Tue, 27 Apr 2010 16:38:56 -0400

> (see also http://tools.ietf.org/html/rfc4686#section-4.1.15)

ah, I thought you were implying that the From domain had to match d=
part. I see that you are not.

-- 
Jeff Macdonald
Ayer, MA

---

From: Douglas Otis <[email-masked]>
Date: Tue, 27 Apr 2010 15:32:49 -0700

On 4/27/10 12:24 PM, Murray S. Kucherawy wrote:
> > While messages with intact DKIM signatures of financial
> > institutions offers reasonable protection, acceptance of broken
> > signatures validated by some third-party's authentication-results
> > header would impose significant risk.    Any mailing list that does
> > remove authentication-results headers would provide easy exploits
> > of X.
>
>  True, if you ignore the main point that got this started: Z trusts Y
>  to do authentication properly and make correct assertions via
>  Authentication-Results.

Is it reasonable to expect providers to establish detailed breakdowns of 
mailing list behaviors?

For X to be safe, Z will need to know which mailing lists:

   A) remove confusing authentication-results headers
   B) apply accurate authentication-results headers
   C) annotate messages so the source is not confusing
   D) exclude confusing or unvetted ads

Acceptance of mailing lists are currently based upon the general 
reputation of the outbound server.  None of this includes any A-D 
consideration.  Until exceptions can be guided by the interested 
domains, without complex and unscalable administrative interaction,  
ADSP is unlikely to play a meaningful role.  Rather than all recipients 
making detailed audits of mailing-list behavior, a third-party 
authorization scheme only requires interested domains, such as financial 
institutions, to audit and list the third-party service employed.

>  The "trust" here has been established out-of-band.  In essence, then,
>  Z treats what Y is saying as always true because of some audit that
>  was done on the work done at Y.
>

Z, the email provider, is not as motivated to audit Y, the mailing-list, 
as X, the financial institution with customers that might be defrauded.  
In addition, X also knows exactly which mailing-lists to audit.  Z, on 
the other hand, would need to audit all mailing-list.  If you want 
something done...

-Doug

---

From: John Levine <[email-masked]>
Date: 27 Apr 2010 23:57:07 -0000

>it would help to hear from them, that they are interested in
>implementing what we direct them to implement.

Hi.  I'm one of the guys who maintains majordomo2.  (Pay no attention
to anyone else who might have a similar name.)

I've adjusted it to sign outgoing mail with a d= that matches the
domain of the list, if possible.  There are so many options for
managing incoming mail that although I'm planning to add an option to
check incoming signatures, I can't say what a typical list would do
with them.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 28 Apr 2010 09:09:41 +0200

> part. I see that you are not.

It does not /have to/. However, if it does, recipients get the best 
assurance dkim can deliver. Otherwise, unless they have configured 
their trust assessments engines appropriately, the relevant signature 
cannot be used by the recipients.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: SM <[email-masked]>
Date: Wed, 28 Apr 2010 03:58:14 -0700

>broken signature, in most cases.

Yes, they are.  RFC 4871 describes what is being covered by the DKIM 
Signature.  For the sake of the discussion, I'll overlook that.  It 
would be good to have these fields certified by limiting the DKIM 
signature to cover them only.  There are cases where we will still 
end up with a broken signature though.  In a one to one exchange, 
let's presume that the message won't be reinjected.  It's different 
for an open mailing list as you any of the subscribers can reuse what 
has been certified and add their own content.  In simple terms, you 
are providing a blind certificate by only (DKIM) signing those fields.

We could use this blind certification for one to one exchanges.  If 
the recipient's account or any of the hops through which the message 
transits is compromised, there will be abuse.  That's already 
happening by the way.  I would caution anyone against using such a 
certification for mailing lists as they will be providing a means for 
anyone to affix their DKIM signature to new content.  I am not 
recommending "l=0".

Regards,
-sm

---

From: Ian Eiloart <[email-masked]>
Date: Wed, 28 Apr 2010 12:54:27 +0100

--On 27 April 2010 12:34:56 -0400 "John R. Levine" <[email-masked]> wrote:

> signed when it arrived.  But such assertions are only credible if the
> list  itself is trustworthy.  If you already know you trust the list, how
> much  practical benefit is there to the assertion?

Not much. It seems to me that the best application of DKIM here would be to 
ensure that posters to closed lists are (likely to be) who they say they 
are.

For example, a user could assert that all their posts will be signed, or a 
list manager could assert that only signed emails will be accepted from 
certain domains.

I manage a list server that is frequently spammed. Not much of the spam 
gets through, but occasionally a spammer gets lucky and picks a sender 
address that gets through.

---

From: Ian Eiloart <[email-masked]>
Date: Wed, 28 Apr 2010 12:56:31 +0100

> BTW, are there lists that require DKIM "pass" to accept posts?

If so, their memberships must be quite restricted - unless they're 
announcement-only lists rather than discussion lists.

---

From: "John R. Levine" <[email-masked]>
Date: 28 Apr 2010 09:02:56 -0400

> ensure that posters to closed lists are (likely to be) who they say they are.

Oh, sure.  For inbound mail, lists can use DKIM the same way that anyone 
else does to recognize mail from senders whose mail they want. 
Subscribers might manually note that all their mail is signed, a la 
Paypal, or this might be a narrow scenario where ADSP could do less harm 
than good.

R's,
John

---

From: Ian Eiloart <[email-masked]>
Date: Wed, 28 Apr 2010 10:18:38 +0100

--On 27 April 2010 13:29:25 -0600 "McDowell, Brett" <[email-masked]> 
wrote:

>
> Are there MLM vendors or service providers on this list who feel they
> know enough about this use case at this point to have a firm position
> either for or against standardizing this functionality?

I'm neither, but I know that Mailman has the option (per list) to remove 
DKIM headers. IIRC, that's because some sites were incorrectly rejecting 
list messages because of the broken headers. That was causing list members 
to become unsubscribed.

Mailman doesn't check DKIM signatures, or add them. Quite properly, in my 
opinion, this is regarded as the business of the local MTA, not the MLM 
software.

I guess that one enhancement would be the ability to require (per site, per 
list or per user) that senders are authenticated by a DKIM signature, was 
well as authorised, before they can send mail to the list. That would 
require tighter integration than Mailman 2 offers, but it might be feasible 
with Mailman 3.

For example, Mailman 3 will accept mail over LMTP and will reject 
unauthorised emails at RCPT TO. That will allow Exim to call forward to 
test authorisation at SMTP time. Doing something clever with 2xx return 
codes might allow Mailman 3 to say "only if authenticated", otherwise such 
policy could be expressed in a common directory service like LDAP.

---

From: Ian Eiloart <[email-masked]>
Date: Wed, 28 Apr 2010 09:55:22 +0100

--On 27 April 2010 12:11:02 -0700 Dave CROCKER <[email-masked]> wrote:

>
> I think the confusion is the difference between hearing individual
> examples,  versus extrapolating them to the larger community.  Yahoo and
> Google are  important and useful.  But they are not representative.
>

Right, but the Internet is diverse. No single software author is 
representative.

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 28 Apr 2010 11:02:53 -0400

A few thoughts to fuel the discussion:

1) It may be that the BCP document would appropriately have a section
for end users of mail lists. One possible recommendation is that for
domains which have strong security concerns, they may want to have a
policy against posting to lists using the domain in question. (I'm
throwing this out as a straw man).

2) One possible recommendation to list managers is that if a message to
the list is DKIM signed AND has an ADSP discardable policy AND the
signature cannot be maintained intact then the list should bounce the
message.

3) Is there a way for us (perhaps in a future version) to provide for
some sort of "encapsulation" that will allow the original
signature/message to be maintained even as the list does certain (as yet
unspecified) actions which might currently break the signature? Just
blue skying here.

4) I recognize the chorus which says "mail lists have always done things
a certain way and who are you to tell us how or what we have to do".
Having given that recognition, in creating an authentication model it
seems self defeating not to provide mechanisms for the authentication to
survive things like maillists (for those maillists/software providers
willing to adopt whatever we come up with). Those lists which have
always done thigns a certain way and wish to continue could do so - no
harm no foul.

Mike

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 28 Apr 2010 08:23:52 -0700

> throwing this out as a straw man).

Are you suggesting a bit of draft text that recipient sites might include in the 
email practices documentation they supply to the (human) users?

> signature cannot be maintained intact then the list should bounce the

What is the particular benefit of doing this, rather than letting the receiving 
site do the bouncing?  This is extra mechanism for the MLM, and most MLMs won't 
be supporting it.  I'm trying to get a clear sense of the value proposition for 
this.

> unspecified) actions which might currently break the signature? Just

I think you are raising the (much) larger question of constraining the nature of 
changes made by MLMs.  Since the are actually posting an entirely new message, 
they have the legitimate freedom to do what they want to it.  However, some can 
choose to participate in that much more constrained role, looking more like a 
relaying MTA than a modifying intermediary.

> Having given that recognition, in creating an authentication model it

Strictly speaking, DKIM does not "authenticate" any part of the message, othe 
than the d= parameter.

I realize that this is an irritating observation, but it is semantically precise 
and accurate.  Absent the presence of ADSP usage, assuming that anything else is 
"authenticated" goes beyond the DKIM specification.

d/
-- 

   Dave Crocker

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 28 Apr 2010 11:31:52 -0400

> From: Dave CROCKER [mailto:[email-masked]]
> Sent: Wednesday, April 28, 2010 11:24 AM
> To: MH Michael Hammer (5304)
should
> Are you suggesting a bit of draft text that recipient sites might
include
> in the

The first question is whether the statement makes sense. The second
question is where it might be communicated.

> site do the bouncing?  This is extra mechanism for the MLM, and most
MLMs
> won't

Is your assertion of what most MLMs will do "a priori" knowledge and is
your timeframe forever? John has advocated that the MLM should strip the
signature so how exactly would the receiving site know to check ADSP?

> relaying MTA than a modifying intermediary.

DKIM and ADSP impose constraints for those who choose to participate.
This is no different. I intentionally avoided suggesting the relaying
model with the goal of leaving the potential approaches open to
discussion.

> Strictly speaking, DKIM does not "authenticate" any part of the
message,
> othe
> than the d= parameter.
> 
> I realize that this is an irritating observation, but it is
semantically
> precise
> and accurate.  Absent the presence of ADSP usage, assuming that
anything
> else is

If DKIM doesn't authenticate any part of the message, what exactly is
the body length hash?

Mike

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 28 Apr 2010 08:55:51 -0700

On 4/28/2010 8:31 AM, MH Michael Hammer (5304) wrote:
>> What is the particular benefit of doing this, rather than letting the
>> receiving site do the bouncing?  This is extra mechanism for the MLM, and
>> most MLMs won't be supporting it.  I'm trying to get a clear sense of the
>> value proposition for this.
>
> Is your assertion of what most MLMs will do "a priori" knowledge and is your
> timeframe forever? John has advocated that the MLM should strip the signature
> so how exactly would the receiving site know to check ADSP?

The mailing list technical community has been particularly challenging with 
respect to the development and adoption of standards.  The List-* specifications 
were hardfought and the current deployment of the feature(s) is still extremely 
spotty.

So anything discussion here about mailing lists needs to take that reality into 
consideration.

>> I think you are raising the (much) larger question of constraining the
>> nature of changes made by MLMs.  Since the are actually posting an
>> entirely new message, they have the legitimate freedom to do what they want
>> to it. However, some can choose to participate in that much more
>> constrained role, looking more like a relaying MTA than a modifying
>> intermediary.
>>
>
> DKIM and ADSP impose constraints for those who choose to participate. This
> is no different. I intentionally avoided suggesting the relaying model with
> the goal of leaving the potential approaches open to discussion.

My point is that you are talking about recruiting mailing lists into this. 
Adding active components into a system is expensive, especially when those 
components have a very poor track record of adoption.  So the value proposition 
needs to compelling.  For them and for the actors attempting to impose this 
burden on the mailing lists.

> If DKIM doesn't authenticate any part of the message, what exactly is the
> body length hash?

DKIM hashing at most provides data integrity validation, from signing to 
verifying.

DKIM makes no assertion of validity of the data being hashed.

In terms of security semantics, this is not a small point.

d/
-- 

   Dave Crocker

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 28 Apr 2010 18:58:21 +0200

On 28/Apr/10 12:58, SM wrote:
> Signature.  For the sake of the discussion, I'll overlook that.

The term "integrity" only appears in the abstract.

> It would be good to have these fields certified by limiting the DKIM
> end up with a broken signature though.

Do you have specific examples? Could a "mellowed" canonicalization 
cope with them?

> In a one to one exchange, let's presume that the message won't be reinjected.

(but snooping is possible)

> It's different

Yes, I am, but with added constraints with respect to what they can do 
using no signature at all. The "Date" constraint may result in badly 
positioning those replayed messages. Wrong "To" fields make a message 
suspect. In addition, spammers don't seem to be seeking the increased 
likelihood of being opened that messages could get if their "From" 
values were familiar to the recipients.

> happening by the way.

Replay attacks? Spam is also happening. As an email user, I'm not 
overly worried about spoofed signatures: They are not legally binding, 
and I trust human recipients are able to distinguish fake messages in 
case they occur. I'm not easing spammers' job by signing mail, even 
though I'd use weaker signatures for increased resiliency. In facts, 
the backscatter I get is not signed.

>  I would caution anyone against using such a

The reason I'm also reluctant to recommend it is because restrictive 
acceptance policies may discard such messages, as John mentioned. The 
same concern also applies to possible weaker canonicalizations: would 
receivers be tempted to rule them out? I think receivers should trust 
the signing policies that senders devise for the messages they send.

It is true that by the 80%-20% criterion DKIM may work without l=0. 
However, it breaks mailing list traffic and MIME-conformant forwarding 
(compare that to SPF.) Do we aim at 100%?
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 28 Apr 2010 19:14:52 +0200

On 28/Apr/10 17:23, Dave CROCKER wrote:
>>  1) [...]  policy against posting to lists using the domain in question.
>>
> site do the bouncing?

Force posters to obey #1

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 28 Apr 2010 10:35:06 -0700

> Sent: Wednesday, April 28, 2010 6:03 AM
> To: Ian Eiloart
> Cc: DKIM List
> Subject: Re: [ietf-dkim] list vs contributor signatures, was Wrong
> Discussion
> 

In the context of authentication to an MLM, are we dancing around in the area of tying "d=" to "From:" again?  Or would you store in the subscriber's meta-data which "d=" value(s) must appear on that subscriber's postings in order for them to be considered authentic?

---

From: Jeff Macdonald <[email-masked]>
Date: Wed, 28 Apr 2010 13:36:10 -0400

> cannot be used by the recipients.

I think this has been covered before. And maybe I misunderstood you
again, but just to be sure:

From: <[email-masked]>
DKIM-Signature: ... d=phisher-i-dont.com;

Say the signature validates. I'm pretty sure DKIM does not have any
assurances about the validity of the message contents, and that would
include the From header. It just validates that it came from the
signer.

-- 
Jeff Macdonald
Ayer, MA

---

From: Jeff Macdonald <[email-masked]>
Date: Wed, 28 Apr 2010 13:41:13 -0400

On Wed, Apr 28, 2010 at 9:02 AM, John R. Levine <[email-masked]> wrote:

> or this might be a narrow scenario where ADSP could do less harm
> than good.

could you elaborate. I'm rusty on ADSP. Was a MLM option introduced?
Your proposal that MLM remove Signatures would cause restrictive
policies to fail. Seems like ADSP would make things worse in this
case.

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 28 Apr 2010 10:56:15 -0700

On 4/28/2010 10:36 AM, Jeff Macdonald wrote:
> From:<[email-masked]>

The mere fact of signature validation must never, ever, ever, EVER be the basis 
for making a decision, except whether to pass the validation information on to a 
decision-making engine the employs ADDITIONAL information, such as reputation or 
independent registration (eg, an FBL.)

d/
-- 

   Dave Crocker

---

From: "John R. Levine" <[email-masked]>
Date: 28 Apr 2010 14:08:41 -0400

> In the context of authentication to an MLM, are we dancing around in the 
> area of tying "d=" to "From:" again?  Or would you store in the 
> subscriber's meta-data which "d=" value(s) must appear on that 
> subscriber's postings in order for them to be considered authentic?

The latter.  I haven't done it yet, but I'd expect to add a mail command 
that says "all my mail is signed like this message is."

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "John R. Levine" <[email-masked]>
Date: 28 Apr 2010 14:11:05 -0400

> could you elaborate. I'm rusty on ADSP. Was a MLM option introduced?

No, ADSP can say "throw away mail that purports to be from me if it's not 
signed", and the MLM could apply it to incoming mail.

> policies to fail. Seems like ADSP would make things worse in this

Indeed.  I'm assuming that any list that paid attention to ADSP would sign 
its outgoing mail and would expect its recipients to trust it enough to 
whitelist the list's mail.  Or equally (more?) likely, ADSP doesn't really 
work, and users who sign everything can tell the list manually.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Wed, 28 Apr 2010 12:19:38 -0700

On 4/28/10 11:11 AM, John R. Levine wrote:
>  No, ADSP can say "throw away mail that purports to be from me if it's
>  not signed", and the MLM could apply it to incoming mail.

ADSP policy would be in respect to the From email address domain, 
independent of a DKIM signature or evidence of having emerged from a 
mailing list.

White-listing a mailing-list to override the application of ADSP could 
expose these lists to relaying misleading messages when needed handling 
has not been applied.  Allow domains interested in being protected, 
audit for the needed handling and then make explicit authorizations of 
the third-party services.  After all, third-party authorization scheme 
scales, and will only require a single transaction to solve issues 
created by ADSP records using the same transactional overhead.

>  Indeed.  I'm assuming that any list that paid attention to ADSP would
>  sign its outgoing mail and would expect its recipients to trust it
>  enough to whitelist the list's mail.  Or equally (more?) likely, ADSP
>  doesn't really work, and users who sign everything can tell the list
>  manually.

There are many considerations what should go into a mailing-lists being 
white-listed against the application of ADSP policies.  Why not allow 
domains seeking protection with ADSP to make the needed audits and 
convey their approval by way of a domain authorization?  Perhaps some 
have no interest in seeing their messages replayed and distributed by 
some mailing lists.   There is no limit on the number of domains 
authorized using a hashed label approach.

-Doug

---

From: SM <[email-masked]>
Date: Wed, 28 Apr 2010 16:12:18 -0700

>Do you have specific examples? Could a "mellowed" canonicalization

There is a MTA that was doing changes to the message headers after a 
message has been signed.  The implementation made allowances for 
changes after signing such as the addition of extra spaces.  There's 
also the case where the user name part can get quoted. Or you can see 
a change due to the Content-Transfer-Encoding.  Some of these changes 
can be addressed with "relaxed" canonicalization.  Some of them may 
require a configuration change at the verifier's end.  The diversity 
of the email environment is such that you cannot come up with a 
"mellowed" canonicalization to cope with every possible change.

>the backscatter I get is not signed.

I would be concerned if my DKIM signatures are re-purposed.  Once 
that gets done, my DKIM signature is of no value except for you to 
direct my messages to the bit bucket.

>the signing policies that senders devise for the messages they send.

Receivers seem to be happy with "relaxed".  If DKIM becomes common 
and there is abuse in that area, receivers might rule it out or adapt 
their filters accordingly.

A well-known company had a broken signing policy a few days before 
Christmas.  That caused messages from that company to be 
rejected.  The receiver wanted to accept the message as it was a 
notice to confirm an order.  The receiver decided not to trust the 
signing policy and allow the message through.

>(compare that to SPF.) Do we aim at 100%?

I don't expect 100%.

Regards,
-sm

---

From: "McDowell, Brett" <[email-masked]>
Date: Thu, 29 Apr 2010 10:58:44 -0600

On Apr 28, 2010, at 2:11 PM, John R. Levine wrote:

>> policies to fail.

Which is why I oppose this proposal.

> whitelist the list's mail.  

That's quite an assumption.  I would not make that same assumption as we chart out new/better mechanisms for MLM's to handle DKIM-signed mail.  It will be true in some cases, and false in others.  All for valid reasons we should seek to account for.

---

From: Al Iverson <[email-masked]>
Date: Thu, 29 Apr 2010 12:23:24 -0500

> Which is why I oppose this proposal.

As John Levine mentioned previously, your own posts to this list fail
authentication and end up in many of our spam folders because of
Paypal's SPF policy. I'm not against strong authentication policies --
but I'm wondering how you personally expect to be able to post to
mailing lists without acceptance of this proposal? The status quo
interferes with your ability currently, and broader adoption of
authentication on the receiving side will only make it worse.

Apologies if this is off-topic, not germane to the broader discussion.
But this question has been nagging at me strongly these past few days.

Regards,
Al Iverson

---

From: Michael Thomas <[email-masked]>
Date: Thu, 29 Apr 2010 10:34:08 -0700

On 04/29/2010 10:23 AM, Al Iverson wrote:
> On Thu, Apr 29, 2010 at 11:58 AM, McDowell, Brett<[email-masked]>  wrote:

The solution to a misconfigured SPF/ADSP record is for every receiver to
patch it up post-hoc? That makes absolutely no sense.

Mike

---

From: "Powers, Jot" <[email-masked]>
Date: Thu, 29 Apr 2010 10:42:51 -0700

> patch it up post-hoc? That makes absolutely no sense.

I must have missed it.  What exactly does PayPal have misconfigured?

Off-list is fine.

-Jot
-- 
Jot Powers   [email-masked]

---

From: Al Iverson <[email-masked]>
Date: Thu, 29 Apr 2010 12:47:37 -0500

On Thu, Apr 29, 2010 at 12:34 PM, Michael Thomas <[email-masked]> wrote:
> patch it up post-hoc?

I did not say that.

> That makes absolutely no sense.

Your apparent anger makes it hard to have a reasonable discussion.

Regards,
Al Iverson

---

From: Michael Thomas <[email-masked]>
Date: Thu, 29 Apr 2010 11:03:57 -0700

On 04/29/2010 10:47 AM, Al Iverson wrote:
> On Thu, Apr 29, 2010 at 12:34 PM, Michael Thomas<[email-masked]>  wrote:

Then what did you say? If somebody's SPF/ADSP record is set up such that it
fails through lists and they want their users to be able to use lists, they
should change their SPF/ADSP record to reflect their actual sending practices.
Putting the burden on mailing lists and everybody else to try to figure out
what they *really* meant makes absolutely no sense.

> Your apparent anger makes it hard to have a reasonable discussion.

Your amateur psychology pronouncements are not appropriate for this list.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Thu, 29 Apr 2010 11:12:44 -0700

On 04/29/2010 10:42 AM, Powers, Jot wrote:
> On 4/29/10 10:34 AM, "Michael Thomas"<[email-masked]>  scribbled:

I'm not sure that paypal.com actually has anything wrong -- i'm not
a spf expert, but it seems that you're set to ~all which isn't a very
restrictive policy iirc. I'm only responding to Al's assertion that your
SPF record is causing mail to be filtered as spam. If I had to guess,
I'd say it's the spam filter's problem, not yours.

With respect to DKIM, anybody who filters based on broken signatures without
any (or little) other input pretty much deserves the false positive rate they're
complaining about.

Mike

---

From: "Powers, Jot" <[email-masked]>
Date: Thu, 29 Apr 2010 11:17:03 -0700

On 4/29/10 11:12 AM, "Michael Thomas" <[email-masked]> scribbled:

> any (or little) other input pretty much deserves the false positive rate
> they're complaining about.

Ok. I think we (PayPal) are on the same page.  We recognized that
DomainKeys with "o=-" and DKIM without "t=y" and ADSP with
"dkim=discardable" is likely to have some collateral damage.  We
work to minimize it but believe the value in preventing phish
is worth that cost.

Not like email has ever been guaranteed delivery.  ;)

-Jot

---

From: Michael Thomas <[email-masked]>
Date: Thu, 29 Apr 2010 11:32:01 -0700

On 04/29/2010 11:17 AM, Powers, Jot wrote:
> On 4/29/10 11:12 AM, "Michael Thomas"<[email-masked]>  scribbled:
>

Ok, I just looked at you ADSP record which I have a lot more familiarity.
I'd say that yes, your ADSP record is misconfigured if you expect your
messages to survive through mailing lists. discardable is a very
restrictive policy which is appropriate for transactional mail, etc,
that you really don't care if it gets thrown away if somebody (like
a mailing list) breaks the signature.

What I'd advise is something like put all of your transactional mail
in a subdomain and set it to "discardable", but don't do that to all
your corpro users. There are other ways to go about this, but I'd say
that you're playing with fire lumping all your stuff together as it
appears that you're doing now.

Or you can just do what a lot of people do which is to tell users of
external lists not to post from their corpro accounts :)

Mike

---

From: "Powers, Jot" <[email-masked]>
Date: Thu, 29 Apr 2010 11:39:52 -0700

> a mailing list) breaks the signature.

Understood. 
 
> appears that you're doing now.

For non-obvious reasons it would be easier to do it the other way.
Make corp come from a subdomain and change the policy there and
keep transactional as paypal.com.

The politics of that are something I'll leave to Brett.

> external lists not to post from their corpro accounts :)

Head-in the sand is always appealing.  :)

-Jot
-- 
Jot Powers   [email-masked]
480-221-1157   skype:jotebay

---

From: "McDowell, Brett" <[email-masked]>
Date: Thu, 29 Apr 2010 12:45:14 -0600

Gentlemen...

There has *not* been a report of any misconfiguration on paypal.com.  The report, which I've taken off-list and am actively chasing down, actually *may* indicate that gmail is not consistently blocking broken DKIM signatures from paypal.com (which our ADSP asks and they have voluntarily chosen to honor/implement), but that has not been substantiated yet and I actually don't expect it will be once all the facts are in.  But again, that's an off-list issue.

There *is* an on-list issue that John raised and I will respond to his message next.  

-- Brett

---

From: Michael Thomas <[email-masked]>
Date: Thu, 29 Apr 2010 11:52:20 -0700

> keep transactional as paypal.com.

Heh, I figured the way I described would be the easier route :)

> Head-in the sand is always appealing.  :)

I'm not so sure this really isn't a viable strategy, honestly. I notice on
NANOG in particular that most people don't post from their corpro account,
seemingly to keep a bit of distance between the geek line and corpro line.
It's not like it's hard to get email accounts these days unlike the dawn of
time when most of us cut our teeth. I can't think of any other pathological
cases like mailing lists that would defeat that as a policy/strategy.

Mike

---

From: "McDowell, Brett" <[email-masked]>
Date: Thu, 29 Apr 2010 13:02:23 -0600

(oops, sorry, it was an issue Al raised, not John... in any event here's my answer)

> authentication on the receiving side will only make it worse.

It's a question of priority and timing.

Priority: it's more important to us that cyber criminals not be systemically enabled to leverage MLM systems to bypass email authentication flows and consumer protection policies designed to block their attacks... the attacks that, if not for the MLM intermediary, would have been blocked thanks to DKIM+ADSP and the voluntary compliance to ADSP policies by certain ISP's/Mailbox Providers.

Timing: therefore, until the standards community enables MLM systems to maintain (if they wish) the integrity of DKIM/ADSP-enabled message authentication flows that exist today (and are on the rise) and would successfully deliver authenticated mail if not for the intervention of the MLM system, our consumer protection policy has this apparent consequence on PayPal employees that participate in certain public mail lists -- the ones that break or strip DKIM signatures -- that would lead us to have to perform workarounds as the issues are discovered.

It's not ideal for me personally, but more importantly it's not ideal for any sender trying to leverage these technologies to improve consumer protection.  That's why I'm here trying to advocate for a *solution* which Murray's proposal just might be the basis for, but I humbly assert John's is not. 

I'd characterize the X-Y-Z proposal from Murray as having some hope of solving the problem without dismissing the current consumer protection values of DKIM+ADSP, and John's proposal as something akin to giving up on ever seeing authenticated mail survive MLM intermediaries.

-- Brett

---

From: SM <[email-masked]>
Date: Thu, 29 Apr 2010 13:12:02 -0700

>any (or little) other input pretty much deserves the false positive 

This mailing list removes the DKIM signature of the poster.  An ADSP 
policy of "all" means that all mail from the domain is signed with an 
Author Domain Signature (d= tag).  As there isn't a valid DKIM 
signature, the message can get rejected.

If the ADSP policy is "discardable" and there isn't an Author Domain 
Signature, the mail can be discarded, i.e. you don't even want a rejection.

If this mailing list did not remove the DKIM signature, the receivers 
would still get an invalid signature as the mailing list modifies the 
subject line and adds a footer.  The ADSP policy will be interpreted as above.

Regards,
-sm

---

From: Graham Murray <[email-masked]>
Date: Thu, 29 Apr 2010 20:47:41 +0100

"McDowell, Brett" <[email-masked]> writes:

> Priority: it's more important to us that cyber criminals not be
> systemically enabled to leverage MLM systems to bypass email
> authentication flows and consumer protection policies designed to
> block their attacks... the attacks that, if not for the MLM
> intermediary, would have been blocked thanks to DKIM+ADSP and the
> voluntary compliance to ADSP policies by certain ISP's/Mailbox
> Providers.

Though is the fact that a mail arrives via an MLM not also a very strong
contra-indication of the validity of nearly all mail which would
constitute such an attack? Irrespective of any other factors, the mere
fact that it arrives via an MLM is an almost certain indication that any
mail which purports to tell you that you have won a lottery, been given
a bequest, have a problem with your account, need to contact a company
about some purchase or other problem etc, is almost 100% certain to be
either a phishing attack, a forgery or a scam. In almost all cases,
genuine mail sent via an MLM is not of the nature which requires such
authentication or falls within consumer protection polices. 

To take your postings here as an example. Mail from PayPal about
people's accounts, policy changes etc needs to be protected and pass
authentication. However, whether or not your postings here authenticate
as genuinely coming from PayPal is not really important and in no way
affects the validity of the points you make in your posts.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Thu, 29 Apr 2010 13:24:52 -0700

> subject line and adds a footer.  The ADSP policy will be interpreted as above.

Note that I didn't say anything about ADSP in what I wrote. ADSP discardable
is a *lot* of "other input", IMO.

Mike

---

From: "McDowell, Brett" <[email-masked]>
Date: Thu, 29 Apr 2010 14:51:04 -0600

> authentication or falls within consumer protection polices. 

That's a very reasonable position to take and it makes good common sense.  But I've been surprised by frighteningly common consumer behavior that flies in the face of good common sense.  But still, I think you have a point and we'd have to turn to the experts on whether the data shows fraud caused by phishing attacks that were delivered by mail lists.  I don't know the answer to that right now.

> affects the validity of the points you make in your posts.

But here is where I must differ.  For example, let's say we created a subdomain that we used for all transactional mail and that was the only domain we asserted "discardable" for.  Well, we just handed the Phishers all of our other domains and they would be more than happy to use those.  The consumer doesn't and really never will consistently discriminate between the mail we tell them to trust vs. the mail we tell them not to trust... it's sad and frustrating, but it's reality.  

Even if you flipped the use case and asserted ADSP discardable for all domains except one that you use for employees... like maybe corp.paypal.com.  Well, you just handed the Phishers corp.paypal.com.

We still have the cousin domain problem, as you all know.  But we are trying to reduce the threat surface as much as we can.  I think a DKIM-for-MLM's spec just might help reduce that threat surface a bit more.

BTW, I didn't join this list to become the center of attention :-)  Aren't there other heavily-phished senders on this list who can speak to these issues and use cases?

-- Brett

---

From: Jeff Macdonald <[email-masked]>
Date: Thu, 29 Apr 2010 17:04:16 -0400

On Wed, Apr 28, 2010 at 11:23 AM, Dave CROCKER <[email-masked]> wrote:
> changes made by MLMs.  Since they [sic] are actually posting an entirely new message,

and forging the From address

> they have the legitimate freedom to do what they want to it.

is it really legitimate in today's world?

>  However, some can

DKIM should be able to survive that.

ps - yes, I know this hash been hashed out many times before.
Eventually we'll all be dust and something else will prevail. :)

-- 
Jeff Macdonald
Ayer, MA

---

From: Douglas Otis <[email-masked]>
Date: Thu, 29 Apr 2010 15:49:39 -0700

> I'd characterize the X-Y-Z proposal from Murray as having some hope of solving the problem without dismissing the current consumer protection values of DKIM+ADSP, and John's proposal as something a…
Reliance upon A-R chains combined with DKIM assumes proper handling of 
prior A-R headers with inclusion of valid A-R headers.  There may also 
be concerns related to injection of misleading content, such as ads by 
other vendors, which could confuse recipients.  In addition, any 
open-ended allowance for broken signatures create more exposure to 
exploitation when mailing-lists fail to make obvious annotations to the 
subject line.  After all, any ADSP "tolerated" message could be replayed 
in spam campaigns.

Until mailing lists only relay messages, which IMHO few want, it is 
unreasonable to expect ISPs or recipients are able to decide when it is 
safe to trust A-R chains to override ADSP assertions.  In addition, many 
large corporations list outbound servers in SPF records without knowing 
who else shares the service.  Neither SPF nor A-R chains alone permit 
safe acceptance.

Safety can be improved when a corporation knows which third-party 
providers are employed, and they audit how messages are handled.  This 
effort only offers protection when they are also able to specifically 
authorize these services.  When authorization is published as a hash, it 
will not directly reveal who is being used.   The proposed third-party 
authorization scheme allows corporations a means to make extremely 
strict acceptance requirements, and to specifically enable ADSP 
exceptions for third-party providers, such as mailing-lists, whenever 
needed.

The adoption of Internet Name-Bundles is to give users the latitude to 
enter names using synonymic ideograms.  Such allowance will make alias 
or shadow domains appear as a third-party domain.  Once again, the 
third-party authorization scheme ensures the acceptance of valid email 
without danger of inviting abuse.

The TPA specification is at:
http://tools.ietf.org/html/draft-otis-dkim-tpa-label-03

-Doug

---

From: John Levine <[email-masked]>
Date: 30 Apr 2010 00:56:26 -0000

>is it really legitimate in today's world?

Could you explain what you mean by "forge" and "legitimate"?  You
appear to be saying that mailing lists are doing something sleazy and
illegitimate by doing what they've done for the past 40 years, which
seems implausible.

R's,
John

---

From: John Levine <[email-masked]>
Date: 30 Apr 2010 01:06:15 -0000

>keep transactional as paypal.com.

Sure, so long as the domains are different, although I would suggest
that for branding reasons it probably would not be a good idea to tell
people that unsigned mail from subdomains of paypal.com is OK.  Use
x.com or one of the hundred of other domains paypal has.

I just don't see how you can simultaneously say "throw away unsigned
mail" and "don't throw away unsigned mail if a list says it used to be
signed" unless you have some way to identify trustworthy lists.  But
once you know that a list is trustworthy, why wouldn't you just accept
all its mail?  I just don't see a plausible scenario where you you
know you trust the list but still want to accept or reject mail based
on assertions the list itself makes.

R's,
John

---

From: "Powers, Jot" <[email-masked]>
Date: Thu, 29 Apr 2010 18:32:04 -0700

> x.com or one of the hundred of other domains paypal has.

Almost thousands, but yes, I can see that.  The practice of changing
it would be almost impossible.  But that's ebay's problem, not the
internets.

> on assertions the list itself makes.

I don't think I've ever asserted anything about mailing list behavior.
I think Brett may have, but I have not.

I think that if we say we want our email thrown away if it isn't signed
(or broken signatures which I think we all agree is the same) and
mail goes through a mailing list and breaks it, then throwing
that away is a reasonable action and I wouldn't complain.  VPs have,
but again, when our policies impact our deliverability I'm not sure
how that is the internet's problem.  Plus John, haven't you always
said that once the mail gets to you, you get to make the choices
not us?  :)

-Jot

---

From: Jeff Macdonald <[email-masked]>
Date: Thu, 29 Apr 2010 23:08:30 -0400

> illegitimate by doing what they've done for the past 40 years, which

That is exactly what I'm saying.

http://en.wikipedia.org/wiki/Asbestos

-- 
Jeff Macdonald
Ayer, MA

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 30 Apr 2010 07:55:01 +0200

On 29/Apr/10 01:12, SM wrote:
> The diversity

Yet, it would seem that by, say, hashing just invariants of binary 
representations of the first entity, e.g. discarding its white space 
and punctuation, one may reach very high percentages of unbroken 
retransmission.

> direct my messages to the bit bucket.

That would be a rather broken reputation system, if re-purposing 
signatures can stagger it. Such game can be played with strongly 
signed messages as well: Messages on this list could be used to wreck 
mipassoc's reputation by massively resending them to general public, 
many of whom would report them as spam.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 29 Apr 2010 23:50:10 -0700

> [email-masked]] On Behalf Of Alessandro Vesely
> Sent: Thursday, April 29, 2010 10:55 PM
> Subject: Re: [ietf-dkim] Broken signatures, was Why mailing lists
> should strip them
> 

This sounds like what DomainKeys (RFC4870) called "nofws" canonicalization, which was discarded in favour of what is now "relaxed" in DKIM.  I don't specifically recall the reasons now but I'm sure they're in the archives if someone else cares to dig that far back.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 30 Apr 2010 00:25:31 -0700

On 4/29/10 6:06 PM, John Levine wrote:

>  mail" and "don't throw away unsigned mail if a list says it used to
>  be signed" unless you have some way to identify trustworthy lists.

Agreed.  People might trust authentications of a From domain based upon 
valid Author Signatures, but they should not trust From domains based 
upon A-R header indications of previous Author Signatures without 
knowing how the A-R headers were processed.  Any assumption of proper 
processing would permit simple exploits and invite abuse.  Those most 
interested in determining proper A-R header processing by third-parties 
would be those with an interest in protecting their recipients, such as 
financial institutions.

>  But once you know that a list is trustworthy, why wouldn't you just
>  accept all its mail?  I just don't see a plausible scenario where you
>  you know you trust the list but still want to accept or reject mail
>  based on assertions the list itself makes.

Not all mailing-lists will remove A-R headers. One misleading A-R header 
from a normally acceptable mailing-list promoting inappropreate trust 
could be replayed in a spam campaign.  Such messages would be difficult 
to reject and might lead to inappropriate annotations.  Who should be 
expected to retain audits of A-R header handling?

-Doug

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 30 Apr 2010 10:30:13 +0100

--On 29 April 2010 10:58:44 -0600 "McDowell, Brett" <[email-masked]> 
wrote:

>> enough to  whitelist the list's mail.
>
> That's quite an assumption.  I would not make that same assumption as we
> chart out new/better mechanisms for MLM's to handle DKIM-signed mail.  It
> will be true in some cases, and false in others.  All for valid reasons
> we should seek to account for.
>

An MLM in receipt of a properly signed message "from" a domain with ADSP 
policy "discard" has a few options:

1. Forward the message to the distribution list unaltered, such that the 
signature remains intact. This might surprise some recipients, and may be 
an exception to normal list policy. On the other hand, it might be feasible 
if the list normally doesn't alter the subject or body.

2. Break the signature, and forward the message in the knowledge that 
recipients may discard it.

3. Break the signature, then discard the message.

4. Bounce the message, on the grounds that it may not be deliverable once 
the signature is broken. The DKIM signature should mean that it's safe to 
bounce the message back without risking collateral spamming, at least when 
the return path is in the same domain as the "From:" header.

5. Reject the message at SMTP time, with an appropriate 5xx error code. 
Similar to above. Safer when the return path domain doesn't match the 
"from" address domain.

I don't think I like (2) and (3).

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 30 Apr 2010 10:36:12 +0100

--On 29 April 2010 11:39:52 -0700 "Powers, Jot" <[email-masked]> wrote:

...
> keep transactional as paypal.com.

I can think of a few reasons, to do with mail volumes, numbers of 
recipients, the value of transactional messages to the business, and the 
fact that everything's currently set up right for transactional messages. 
Why risk breaking them!

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 30 Apr 2010 10:38:42 +0100

> on assertions the list itself makes.

How about you trust the list, and it says the inbound message wasn't 
signed? The list has left the value judgement to the recipient.

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 30 Apr 2010 11:13:45 +0100

> throwing this out as a straw man).

Yep, I'd suggest sections for MLM site owners, MLM list managers (who may 
not have access to MTA configuration), list mail posters, and list mail 
recipients.

> signature cannot be maintained intact then the list should bounce the

+1

> unspecified) actions which might currently break the signature? Just

I guess you could attach the entire original message to the message that 
you're generating.

In fact, the list could just send a message saying "This was posted to the 
list", preserving the subject line, I guess. I don't know how that would 
look in various mail clients....

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 30 Apr 2010 11:16:20 +0100

--On 28 April 2010 08:23:52 -0700 Dave CROCKER <[email-masked]> wrote:

> Are you suggesting a bit of draft text that recipient sites might include
> in the  email practices documentation they supply to the (human) users?
>
>
> receiving  site do the bouncing?  This is extra mechanism for the MLM,
> and most MLMs won't  be supporting it.  I'm trying to get a clear sense
> of the value proposition for  this.

The receiving site would bounce to the list. The message ought to be 
bounced to the original sender, who (with adsp=discard) probably doesn't 
want messages redistributed, and should be informed of the problem.

Certainly *my* MTA/MLM setup (Exim/Mailman) can be configured to do this. 
In fact, Exim could be configured to do this with any MLM behind it.

> entirely new message,  they have the legitimate freedom to do what they
> want to it.  However, some can  choose to participate in that much more
> Strictly speaking, DKIM does not "authenticate" any part of the message,
> othe  than the d= parameter.
>
> I realize that this is an irritating observation, but it is semantically
> precise  and accurate.  Absent the presence of ADSP usage, assuming that
> anything else is  "authenticated" goes beyond the DKIM specification.
>
> d/

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 30 Apr 2010 11:22:00 +0100

On Thu, 29 Apr 2010 21:12:02 +0100, SM <[email-masked]> wrote:

> This mailing list removes the DKIM signature of the poster. ...

and that is precisely the cause of the problem. Nobody should EVER remove  
a signaturre (unless it was one they wrote themselves).

The correct procedure is to add an Authentication-Results to say that the  
signature was good on arrival (assuming it was).

Ideally, it should then be resigned (with the A-R included in the  
signature).

Then the recipient has some evidence to assist in his evaluation. In fact,  
the changes made by this list are easily reversible, if someone wants to  
try to reverse them and check the original signature. But he cannot do  
that with a signature that has been removed.

-- 
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: "John R. Levine" <[email-masked]>
Date: 30 Apr 2010 07:48:10 -0400

> http://en.wikipedia.org/wiki/Asbestos

So, if I understand you correctly, when the AARP e-pends an address for me 
and sends me spam, it's "legitimate" because they're spamming from their 
own domain, but when you get mail from the DKIM list you've signed up for 
it's not.  Wow.

Regards,

---

From: "John R. Levine" <[email-masked]>
Date: 30 Apr 2010 08:02:44 -0400

>> I just don't see a plausible scenario where you you know you trust the 
>> list but still want to accept or reject mail based on assertions the 
>> list itself makes.

> signed? The list has left the value judgement to the recipient.

I've been using mailing lists for 35 years, and I cannot recall any where 
the list manager threw up his hands and didn't manage the list's contents. 
The conceptual model of mailing lists has been consistent for decades: the 
list picks mail to pass along using whatever manual or automated process 
it uses, and subscribers accept the mail the list sends.  I don't see the 
point in trying to retroactively redefine the ways that lists work to try 
to shoehorn them into the limits of poorly desiged security add-on.

See "forgery" for another example of the same newthink, in which the SPF 
crowd tried to persuade the world that SPF's failure to handle long 
established forwarding models was the fordwarders' fault.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 30 Apr 2010 14:03:47 +0200

On 30/Apr/10 08:50, Murray S. Kucherawy wrote:
>>  [email-masked]] On Behalf Of Alessandro Vesely Sent: Thursday, April 29, 2010 10:55 PM
>>
>>  Yet, it would seem that by, say, hashing just invariants of binary representations of the first entity, e.g. discarding its white space and punctuation, one may reach very high percentages of unbroken retransmission.
>
> This sounds like what DomainKeys (RFC4870) called "nofws" canonicalization, which was discarded in favour of what is now "relaxed" in DKIM.

Not exactly, removing punctuation would also take lines beginning with 
">from". For the body, we could peek any suitable baseline 
tokenization and hash its results.

> I don't specifically recall the reasons now but I'm sure they're in the archives if someone else cares to dig that far back.

The reason is meticulous security, which makes mailing lists' contents 
sleazy and illegitimate.

One is http://mipassoc.org/pipermail/ietf-dkim/2005q3/000002.html
(the previous part of the discussion is in some other archive or lost, 
but much text can be read in the quoted part of the message.) It 
exemplifies

   "Amoeba yeast" to Amo ebay east

Another good summary of the driving thoughts is given in
http://mipassoc.org/pipermail/ietf-dkim/2006q3/004416.html
(while discussing whether to keep body- "relaxed".) It exemplifies

   --boundary
   Content-Type: image/jpeg
   Content-Transfer-Encoding: base64

to

   --boundary
   Content-Type: image/jpegContent-Transfer-Encoding: base64
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: John Levine <[email-masked]>
Date: 30 Apr 2010 12:33:00 -0000

>and punctuation, one may reach very high percentages of unbroken 

It sounds like you want to experiment with different canon schemes for DKIM,
rather than the two that exist now.  Wouldn't that be more appropriate
for ASRG?

R's,
John

---

From: John Levine <[email-masked]>
Date: 30 Apr 2010 12:37:22 -0000

>that with a signature that has been removed.

Huh?  If we could write down the changes that lists make to the mail
they send, we would have done so.  My list managers have been known to
remove or reorder MIME parts and flatten HTML into text.  I even run
some quaint lists where the editor hand-edits the messages.  No, those
aren't "illegitimate", they're standard practice and have been for
decades.

R's,
John

---

From: Jeff Macdonald <[email-masked]>
Date: Fri, 30 Apr 2010 08:45:37 -0400

On Fri, Apr 30, 2010 at 7:48 AM, John R. Levine <[email-masked]> wrote:
> and sends me spam, it's "legitimate" because they're spamming from their own
> domain,

putting aside why they are sending you an email or how they got the
email address, in this case the message comes from AARP unmodified. It
is FROM AARP.

> but when you get mail from the DKIM list you've signed up for it's
> not.  Wow.

mail _from_ a mailing list is not the original message anymore.

I know this isn't a popular opinion. Just because something has been
done someway for 40 years doesn't make it right. Thus my link to
asbestos.

-- 
Jeff Macdonald
Ayer, MA

---

From: Jeff Macdonald <[email-masked]>
Date: Fri, 30 Apr 2010 08:50:04 -0400

> signed? The list has left the value judgement to the recipient.

How does one do that if using an email web service provider that puts
the message into the spam folder without giving the recipient a
choice?

-- 
Jeff Macdonald
Ayer, MA

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 30 Apr 2010 05:56:30 -0700

On 4/29/2010 2:04 PM, Jeff Macdonald wrote:
> On Wed, Apr 28, 2010 at 11:23 AM, Dave CROCKER<[email-masked]>  wrote:

It's not forged:

    "to imitate fraudulently"

    <http://dictionary.reference.com/browse/forge>

The use of that word, for this situation, is simply incorrect.

And the retention of the original posting's From: string is quite simply valid. 
  The fact that it is causing a problem for some add-on technologies does not, 
post hoc, render the string invalid.

> is it really legitimate in today's world?

Yes.  Until the community develops, adopts and uses some alternative model, 
retention of the original posting's From: string has specific meaning that 
remains essential for mailing list semantics.

> DKIM should be able to survive that.

And there should be world peace.  Our sharing such a wish does not, post hoc, 
render the string invalid.

d/

ps.  DKIM /can/ survive that.  Merely use l=0 and hash only the From: field or 
perhaps From: and Date: or perhaps...  The fact that the community considers 
that alternative inadequate is understandable, but again, this add-on technology 
(DKIM) does not have the right to come in and declare well-established existing 
practice invalid.

-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 30 Apr 2010 06:00:50 -0700

On 4/30/2010 3:16 AM, Ian Eiloart wrote:
 > The receiving site would bounce to the list.

As John has reminded us, this is not about a bounce message.  Rather, it 
concerns an independent report, sent to an independently-registered address.

 > In fact, Exim could be configured to do this with any MLM behind it.

What are the procedures for having this configuration cause FBL reports go to an 
address that is different from the one registered in the FBL?

d/

-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 30 Apr 2010 06:04:58 -0700

This isn't really a reply.

It's a comment that Steve's note was sent a week ago and I'm frankly impressed 
that it has received no replies, since it contains the most salient observations 
about the current "problem" being discussed I've seen.

I've included all of its body in this posting, in the hope that folks will read 
it again more carefully.

d/

-- 

   Dave Crocker

---

From: "McDowell, Brett" <[email-masked]>
Date: Fri, 30 Apr 2010 08:05:15 -0600

On Apr 29, 2010, at 9:06 PM, John Levine wrote:

> signed" unless you have some way to identify trustworthy lists.  

Precisely!  The key phrase being "unless you have some way to identity trustworthy lists"

> But
> all its mail?

We need to be precise about what we mean by "trustworthy".  Even if I have "some way to identify trustworthy lists" as you put it above, I have to be very clear about what I'm actually trusting that list to do.  

Let's go back to the use case I drafted in response to Murray's report that introduced the MLM re-signing option.

>> So if it simply isn't practical to expect lists to maintain the signature, then offering the option for the list to validate the signature coming from X and send a new signature to Z that Z *can*…

In that scenario, if the MLM re-signing solution has been deployed by Y, and DKIM+ADSP has been deployed by X & Z, and Z has chosen to take action on X's ADSP policies... the only thing Z is trusting Y to do is validate incoming DKIM signatures, re-sign the messages with its own DKIM signature, and pass it along with the A-R results that convey what was done.  Z is not trusting everything and anything that might ever come through Y.

I think that's a reasonable level of trust to expect mailbox providers to have in mail lists who assert that they do this.  Rogue mail lists will stop being trusted but only after they have "lost" the trust that was granted to them via their standards-based assertion (we would probably need to spec out how a MLM advertises that they indeed conduct flows in this manner) that they perform these functions on incoming mail.

Again, I'm not saying this is the best or most elegant way of handling the problem of properly authenticated mail not being able to traverse mail lists, but it seems worthy of further discussion as an option.

>  I just don't see a plausible scenario where you you

Does the use case I've articulated above make sense?

-- Brett

---

From: "McDowell, Brett" <[email-masked]>
Date: Fri, 30 Apr 2010 08:21:57 -0600

> I don't think I like (2) and (3).

I think this helps frame the discussion.  It's highly related to Steve's post that Dave so rightly re-posted for re-consideration.  People on this list are advocating various options, but oddly enough I think this is the first post on the thread that tried to summarize all options.  

FWIW, I don't like #2 or #3 either.  

There's been some debate on this list regarding option #1 and it seems to be a non-starter for MLM operators.  Actually, I've recently been joining a lot of new mail lists and some are configured like option #1 and I cannot stand them as a user.  So I'd say option #1 might be an elegant/simple solution but I personally wouldn't want to see mail lists behave this way.

Options #4 and #5 seem closely related to what Steve was advocating when he brought up the value and role of FBL's could play in the original use case which John L. provided (before I threw in my use case in reaction to Murray's report on MLM re-signing discussions at IETF 77).  I think they are all related because they all seem to fall into the category of "I, the MLM, am not going to deliver the mail, but I'm going to provide some failure information to the appropriate parties in the most useful form I can".  

>From Steve's message:

<snip>
> particular list subscriber as well as that of the list.)
</snip>

I think the role of DKIM FBL's needs to be discussed more on the list.  Not only does it directly impact the first use case John L. introduced, but it could add a dimension to the second use case (X-Y-Z) that's been overlooked thus far.

Option #6:
I don't think this summary captures the MLM re-signing option Murray and I have been somewhat advocating for.  So I want to get that on the table in this summary.

-- Brett

---

From: Michael Thomas <[email-masked]>
Date: Fri, 30 Apr 2010 07:23:54 -0700

On 04/30/2010 07:05 AM, McDowell, Brett wrote:
>
> In that scenario, if the MLM re-signing solution has been deployed by Y, and DKIM+ADSP has been deployed by X&  Z, and Z has chosen to take action on X's ADSP policies... the only thing Z is trusting Y to do is validate incoming DKIM signatures, re-sign the messages with its own DKIM signature, and pass it along with the A-R results that convey what was done.  Z is not trusting everything and anything that might ever come through Y.
>

Yeahbut... there are zillions of mailing lists out there. How do you know the good ones
from the bad ones? Keep in mind, of course, that bad guys can resign too, and they can
easily make themselves look like a mailing list if that's something that gives them
advantage.

If the solution is some sort of (third party) reputation/whitelist, then there's really
not much for us to do, right? Even with your discardable adsp setting, it becomes a
matter of the order of checks at the receiver's gate (eg, whitelist first, then adsp...)

Mike

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 30 Apr 2010 15:01:15 +0100

> concerns an independent report, sent to an independently-registered

I was responding to the question quoted. I guess it's tangential to the 
original question that started the thread.

> What are the procedures for having this configuration cause FBL reports
> go to an address that is different from the one registered in the FBL?

---

From: "McDowell, Brett" <[email-masked]>
Date: Fri, 30 Apr 2010 08:38:50 -0600

> easily make themselves look like a mailing list if that's something that gives them

Indeed.  But mailbox providers all have their own secret sauce for figuring out reputation of senders that I believe they could apply to this new flavor of sender -- meaning MLM's who adopt the MLM-DKIM spec we seem to be debating the virtues of developing -- without too much overhead.

> not much for us to do, right?

I think we still need this spec I'm starting to refer to as MLM-DKIM to specify both the proper way of conducting this re-signing & reporting practice and how the MLM advertises that they follow it.

> Even with your discardable adsp setting, it becomes a

But since mailbox providers already manage reputation at scale, how much of a burden is adding this bit to the mix?  Remember this only affects mailbox providers who have decided to do DKIM blocking based on ADSP discardable policies (for some, if not all senders).
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 30 Apr 2010 14:58:27 +0100

> the list manager threw up his hands and didn't manage the list's

I don't think that's what I'm saying. Currently lists don't do much to 
authenticate senders. I don't think it's implausible that a recipient might 
have stricter rules than a list manager. It might be unusual, I suppose.

> The conceptual model of mailing lists has been consistent for
> decades: the list picks mail to pass along using whatever manual or
> automated process it uses, and subscribers accept the mail the list
> sends.  I don't see the point in trying to retroactively redefine the
> ways that lists work to try to shoehorn them into the limits of poorly
> desiged security add-on.
>

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 30 Apr 2010 15:05:01 +0100

--On 30 April 2010 12:37:22 +0000 John Levine <[email-masked]> wrote:

>> Then the recipient has some evidence to assist in his evaluation. In
>> fact,   the changes made by this list are easily reversible, if someone
>> wants to   try to reverse them and check the original signature. But he
>> cannot do   that with a signature that has been removed.
>

Perhaps they are, but there could be some value in trying to define a set 
of reversible list modifications which would permit DKIM signatures to 
still be useful. That's not to mandate those modifications, or to forbid 
others, but as guidance. It could be a way forward.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 30 Apr 2010 08:05:25 -0700

On 04/30/2010 07:38 AM, McDowell, Brett wrote:
> I think we still need this spec I'm starting to refer to as MLM-DKIM to specify both the proper way of conducting this re-signing&  reporting practice and how the MLM advertises that they follow it.
>

Let's put aside whether there's something new here for the moment (i've not had my
coffee yet...). By all rights, we should not be having this conversation right now
at all because you have set adsp discardable. So even if we adopted some bcp-like
advise for mlm and receivers, it would be years if not forever before we could have
a reliable conversation on this and other lists again. Maybe at paypal that's an
acceptable tradeoff (?), but at my previous employer, all standards work, for one,
would cease and there would be lots of engineers with pitchforks and torches.

So what I'm getting at here is that I'm having a hard time understanding how the
bootstrap doesn't fail for most sending/receiving entities. As I'm sure you know,
false positives drive mail admins to complete distraction... which is the situation
it looks to me that you're willing setting up.

That said, you (paypal) are far braver than I am, but if you can make this to work
somehow as a large enterprise that would be a pretty amazing accomplishment.

Mike

---

From: John Levine <[email-masked]>
Date: Fri, 30 Apr 2010 11:07:59 -0400 (EDT)

> Perhaps they are, but there could be some value in trying to define a set of 
> reversible list modifications which would permit DKIM signatures to still be 
> useful. That's not to mandate those modifications, or to forbid others, but 
> as guidance. It could be a way forward.

Sounds like another job for ASRG.  First you'd need to see if you could 
characterize a meaningful set of lists, not just the ones you and I happen 
to be subscribed to.

R's,
John

---

From: Jeff Macdonald <[email-masked]>
Date: Fri, 30 Apr 2010 11:32:09 -0400

On Fri, Apr 30, 2010 at 8:56 AM, Dave CROCKER <[email-masked]> wrote:
>> I wrote:
> And the retention of the original posting's From: string is quite simply
> valid.  The fact that it is causing a problem for some add-on technologies
> does not, post hoc, render the string invalid.

Perhaps poorly chosen words. But I think most understood the intent.
I'm willing to go from a world where any system can use my From to one
where only the systems I say can. And that means changes.

-- 
Jeff Macdonald
Ayer, MA

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 30 Apr 2010 08:48:44 -0700

> [email-masked]] On Behalf Of Jeff Macdonald
> Sent: Friday, April 30, 2010 8:32 AM
> To: [email-masked]

It has been pointed out that MLM implementers have even more inertia than your average MTA implementer.  Although many header fields have been invented specifically for the purpose of aiding list management (your List-Id: and List-Unsubscribe:, not to mention Sender:), their adoption has not exactly been universal.

So you might be gung ho for big changes that will make things better, but we need to accept the fact that a substantial portion of the installed base won't change, at least not soon, and we can't ignore them.  Any BCP we produce will have to take that into account.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 30 Apr 2010 08:48:52 -0700

> where only the systems I say can. And that means changes.

Really? The sender has to opt in? That sounds like a lot of operational
burden on the sender admins. To me that says that I'd need to get blessing
from my mail admins to start posting to a new list/domain. Which is a pretty
big change from the way things are now. And to my mind a little bit scary.

Mike

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 30 Apr 2010 09:15:25 -0700

On 4/30/2010 8:32 AM, Jeff Macdonald wrote:
> On Fri, Apr 30, 2010 at 8:56 AM, Dave CROCKER<[email-masked]>  wrote:
>>> I wrote:
...
...
> Perhaps poorly chosen words. But I think most understood the intent.

Actually, most seem not to.  They really believe the string is "invalid" or at 
least that its presence in that form is "wrong".

If we are doing serious technical work, we need to be serious in our use of 
terminology.  Among the various terms that I regularly rant about, the 
long-standing mischaracterization of the From: string as "forged" is 
particularly egregious.  And my rant is not at you.  It's at the community, for 
having established the practise of using the term.

> where only the systems I say can. And that means changes.

That's an example of the problem in using the term:  Much discussion about DKIM 
presume far more end-to-end control by authors or senders than they will ever have.

d/

-- 

   Dave Crocker

---

From: Jeff Macdonald <[email-masked]>
Date: Fri, 30 Apr 2010 12:28:16 -0400

On Fri, Apr 30, 2010 at 12:15 PM, Dave CROCKER <[email-masked]> wrote:
> Actually, most seem not to.  They really believe the string is "invalid" or
> at least that its presence in that form is "wrong".
>
> particularly egregious.  And my rant is not at you.  It's at the community,
> for having established the practise of using the term.
>

don't ever stop banging that drum.

> That's an example of the problem in using the term:  Much discussion about
> DKIM presume far more end-to-end control by authors or senders than they
> will ever have.

Murray, John, Dave and Mike:

I apologize for going off on a tangent. I just keep asking myself "what if". :)

I like John's suggestion of taking Brett's ideas to ASRG.

-- 
Jeff Macdonald
Ayer, MA

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Fri, 30 Apr 2010 12:44:43 -0400

> [email-masked]] On Behalf Of Dave CROCKER
> Sent: Friday, April 30, 2010 12:15 PM
> To: Jeff Macdonald
> Cc: [email-masked]; [email-masked]
should
> Actually, most seem not to.  They really believe the string is
"invalid"
> or at
> If we are doing serious technical work, we need to be serious in our
use
> of

I seem to remember this discussion in the distant past and there overall
people seemed to have less difficulty with the use of the term "spoof"
or "spoofing" instead of "forge" or forging". If not this term then it
would be appropriate to come to a consensus on a term that represents
this practice.

Mike

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 30 Apr 2010 10:33:43 -0700

> would be appropriate to come to a consensus on a term that represents

I applaud the effort in looking for a better term.

Spoof probably isn't it, however:

    1.  a mocking imitation of someone or something, usually light and 
good-humored; lampoon or parody: The show was a spoof of college life.

    2.  a hoax; prank.

    <http://dictionary.reference.com/browse/spoof>

If I had a strong choice to offer, I'd make it.

Perhaps the place to start is to ask that we try to agree on a basic semantics 
statement that doesn't use the term, but could be taken as its definition.

That is, what meaning are people trying to convey about this use or aspect of 
the From: field.

d/
-- 

   Dave Crocker

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 30 Apr 2010 19:38:12 +0200

>>  signature cannot be maintained intact then the list should bounce the

+1, an additional reason is that the author might have a clever DKIM 
configuration, but just forgot to add "[ietf-dkim]" in front of the 
subject of a new message. A bounce easily prompts for such correction.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Fri, 30 Apr 2010 11:12:58 -0700

> big change from the way things are now. And to my mind a little bit scary.
Why not, when a sender authorization scheme can be unilaterally enacted 
in milliseconds with a simple request, either in the form of an email or 
a web-page. This would be a request to grant specific exceptions in the 
domain's "discard-able" or "all" policy by publishing a hash label.

In the case of financial institutions, before taking such step, any 
authorized third-party should be audited.  This would be easier to do 
with DKIM than with SPF because a server's range of permitted sources is 
not determined with a simple message probe.   With DKIM, testing the 
handling of submissions from different accounts would offer reasonably 
assurance an authorization does not permit exploitations.

By implementing a third-party authorization scheme with DKIM, tighter 
restrictions become possible with fewer messages lost.  A DKIM 
authorization scheme would also put the burden of knowing who can be 
trusted to properly handle A-R headers and message bodies on to the 
senders seeking protections afforded by  "all" or "discard-able" ADSP 
policy.

-Doug

---

From: John Levine <[email-masked]>
Date: 30 Apr 2010 18:22:55 -0000

>done someway for 40 years doesn't make it right. Thus my link to

Asbestos was always toxic to humans, but for whatever reason it took a
long time to identify the problem.

Is there some long-standing toxic effect of mailing lists other than
that they don't fit the simple identity models used by recently
devised authentication schemes?

R's,
John

---

From: John Levine <[email-masked]>
Date: 30 Apr 2010 18:24:43 -0000

>We need to be precise about what we mean by "trustworthy".  Even if I
>have "some way to identify trustworthy lists" as you put it above, I
>have to be very clear about what I'm actually trusting that list to do. 

When I sign up for a list, I trust it to send me mail that I am
willing to receive.  Is there any other understanding of mailing
lists that people have?

R's,
John

---

From: John Levine <[email-masked]>
Date: 30 Apr 2010 18:31:09 -0000

>But since mailbox providers already manage reputation at scale, how much
>of a burden is adding this bit to the mix?  Remember this only affects
>mailbox providers who have decided to do DKIM blocking based on ADSP
>discardable policies (for some, if not all senders).

You appear to be asking recipients to distinguish among legit directly
sent paypal transaction mail, legit paypal mail that comes through
known-to-be-real mailing lists, and any other paypal mail that is
presumably illegitimate.  This is a huge burden, since you're asking
every mail system in the world to distinguish between legit list mail
and legit other mail, something they don't have to do if they just
deliver mail which has a good reputation.

Since you're describing two mailstreams, directly sent paypal transaction
mail and list relayed individual mail, why wouldn't it be a better idea and
less work (for everyone other than paypal at least), to separate those two
streams so the recipients don't have to guess which messages belong to
which ones?

Free bonus: if you move the individual mail out of the transaction
stream, if you are able to recognize list mail, you instantly know
that any paypal.com mail arriving from a list has a problem.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Fri, 30 Apr 2010 13:52:32 -0700

> willing to receive.  Is there any other understanding of mailing
Perhaps this concern should be viewed in how different email might be 
perceived.  When people are mislead into believing you recommended some 
clever script, they might be tempted to give it a try.   Just following 
a link could expose recipients to possible zero day exploits.  This type 
of social engineering is ongoing, where theft of financial information 
has risen dramatically in the last two years.

Exploits are regularly found in browser extensions like Adobe Flash, 
Acrobat, Java, and Active-X, where many are patched and reported in 
comparatively long periods after initial discoveries.  Malware taking 
advantage of these exploits often becomes modified in less than six 
hours.  Once a patch is published, it event is often followed by a flood 
of more malware, since it educates other writers.

While you may not be concerned, think of financial institutions seeing 
people's accounts ransacked. Whether they use their transactional 
domain, or some lesser known one, the need for security does not really 
change.

-Doug

---

From: "McDowell, Brett" <[email-masked]>
Date: Fri, 30 Apr 2010 15:06:27 -0600

> willing to receive.  Is there any other understanding of mailing
Did you read the rest of my message?

---

From: "McDowell, Brett" <[email-masked]>
Date: Fri, 30 Apr 2010 15:09:56 -0600

On Apr 30, 2010, at 2:31 PM, John Levine wrote:

> presumably illegitimate.  

Nope.  I'm suggesting a means for enabling DKIM authenticated mail to survive transit through a mail list and arrive with the intent/purpose/value of the original authentication might be for MLM's to validate incoming mail and DKIM sign their own outbound mail along with the appropriate A-R data.  That's all.

---

From: "McDowell, Brett" <[email-masked]>
Date: Fri, 30 Apr 2010 15:13:14 -0600

> subject of a new message. A bounce easily prompts for such correction.

So that's another "vote" for option #4 (per the previous post trying to summarize the various options).

BTW, where is this mail list publicly archived?  (Next time I'm referring to a previous message I'll just include the URL to the post.)

---

From: "McDowell, Brett" <[email-masked]>
Date: Fri, 30 Apr 2010 15:14:56 -0600

> I like John's suggestion of taking Brett's ideas to ASRG.

Those weren't my ideas.  I haven't yet commented on the canonicalization topic.  I lost track of who introduced that one.

---

From: "McDowell, Brett" <[email-masked]>
Date: Fri, 30 Apr 2010 15:33:51 -0600

> somehow as a large enterprise that would be a pretty amazing accomplishment.

Talking about the status quo is to talk about how every ISP/MBP (btw, is it common practice to refer to a "mailbox provider" as a MBP?) has decided to deal with "discardable" ADSP policies given they ALL KNOW that some common Internet practices break DKIM.  I'm not sure why that's a useful discussion to have in this forum.  I thought we wanted to talk about how to change the status quo so DKIM signatures aren't made irrelevant by common Internet mail practices like MLM's.

Just so everyone knows, even some of the ISP/MBP's working with us who are equally committed to curbing paypal.com phishing attacks by means of DKIM and ADSP, are sorting out how they want to handle the gray areas when they see evidence that the message was 'probably validate-able' when it started but something that is 'probably not criminal' happened along the way so I can no longer validate... so let me... make it up as I go and iterate until the standards evolve to remove/reduce this problem.

That in fact is why my emails *are* being delivered to at least one gmail.com user on this list.

So the status quo is ugly at best.  

Is there any will in this group (aside from my own) to evolve the standards to improve the status quo?

<soapbox>
Are the rest of you as concerned about the damage fraud messaging can have to a user's computer, identity, and all systems on the Internet accessible from that computer?  I know I don't have to say this, but... this isn't just about stopping annoying ads for viagra.  And it isn't just about financial institutions' monetary losses due to account takeover attacks enabled by phishing.  It's about the trustworthiness of the Internet and addressing the A#1 channel criminals use today to undermine the integrity of this amazing infrastructure all of us have enjoyed and many of *you* have created.
</soapbox>

-- Brett

---

From: Steve Atkins <[email-masked]>
Date: Fri, 30 Apr 2010 11:10:34 -1000

> signature cannot be maintained intact then the list should bounce the

Given that ADSP discardable is used to mark domains which send only  
email that the sender considers should never risk being modifed in any  
way - they only want it sent from their smarthost to the MX of the  
original reciient, with no forwarding or store and forward or  
rewriting, effectively - perhaps something more aggressive by mailing  
list managers is needed.

If a mailing list were to simply reject all submissions from senders  
who are publishing ADSP discardable that would ensure that their  
wishes were not violated. And it seems to comply with the spirit of  
ADSP discardable more than the riskier suggestions.

Cheers,
   Steve

---

From: "John R. Levine" <[email-masked]>
Date: 30 Apr 2010 21:45:08 -0400

> have stricter rules than a list manager. It might be unusual, I suppose.

I agree it's hypothetically possible, but have you ever seen an actual 
need for this in practice, a list where the recipients filter out messages 
that a more competently managed list would have rejected?

R's,
John

---

From: John Levine <[email-masked]>
Date: 1 May 2010 02:05:44 -0000

>Did you read the rest of my message?

Yes.  I didn't say anything about doing extra work to try to deal with
mail from senders that mix transactional and individual mail in the
same mailstream, since lists have never done that.

R's,
John

R's,
John

---

From: John Levine <[email-masked]>
Date: 1 May 2010 02:09:38 -0000

>Nope.  I'm suggesting a means for enabling DKIM authenticated mail to
>survive transit through a mail list and arrive with the
>intent/purpose/value of the original authentication might be for MLM's
>to validate incoming mail and DKIM sign their own outbound mail along
>with the appropriate A-R data.  That's all.

But you haven't offered any plausible benefit from doing so, other
than to let you mix your two mailstreams.  As I've said about a
bajillion times, we have 40 years of list management history, and this
isn't a problem that anyone has ever needed to solve.  So I'll leave
it there.

R's,
John