Subject: Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review

From: John Levine <[email-masked]>
Date: 1 Sep 2010 09:18:02 -0000

>> ANNEX A - MUA Considerations
>
>Is a draft about mailing lists the right place to make recommendations
>to MUA developers?  Seems like those should probably be in a separate
>document.

No, but the entire document is riddled with advice that has no basis
in experience and is unlikely ever to be implemented.

We have a serious problem that people in this group have deeply
incompatible ideas of what DKIM does.  A lot of the arguments seem to
be from people who believe that a DKIM signature can or should
identify the individual author of a message, and that subscribers to
mailing lists need assurances about the identity of list authors
beyond the minimal level that has been adequate for the past twenty
years.  I have trouble understanding how anyone who is familiar with
DKIM or with the operation of mailing lists could hold these
positions, but it is quite obvious that some do.

At this point, unless we can cut back the MLM document to stick to
items that we have consensus about, e.g., that it is typical for
signatures applied to incoming mail not to verify after a message
passes through an MLM, and that it would be nice if a list or its MTA
signed its outgoing mail, I don't think we will produce anything that
is useful to anyone.

R's,
John

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

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 1 Sep 2010 07:55:34 -0400

> signed its outgoing mail, I don't think we will produce anything that

If that's all we can say, I'd say don't bother.  I don't see much value in the 
DKIM working group saying it thinks mail should be signed by DKIM.

Scott K

---

From: John Levine <[email-masked]>
Date: 1 Sep 2010 12:23:19 -0000

>DKIM working group saying it thinks mail should be signed by DKIM.

"e.g." means "such as" or "for example."

I expect there's a fair amount we agree on.  Maybe it's enough to be
worth documenting, maybe not, but I think it would be more productive
to see what we agree on rather than trying to force our pet projects
into the document.

I'll cheerfully give up references to S/MIME, if other people will
give up on telling software developers how to rewrite MLMs to do
things they've never done before.

Don't forget that an experimental RFC is the accepted way to document
a paper design to see if it gets any traction, as the EAI group did
with various ways to represent non-ASCII e-mail addresses.

R's,
John

---

From: Wietse Venema <[email-masked]>
Date: Wed, 1 Sep 2010 08:57:26 -0400 (EDT)

Scott Kitterman:
> If that's all we can say, I'd say don't bother.  I don't see much
> value in the DKIM working group saying it thinks mail should be
> signed by DKIM.

If we want to increase adoption of DKIM today, then I think there
is value in a document that explains in plain words what DKIM
actually does, in terms of what mailing lists actually do, and in
terms of how MUAs actually work, common traps and pitfalls included.

If we want to increase adoption of DKIM in some distant future,
then we would need to speculate about what that future would look
like, and that is not useful.

	Wietse

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 1 Sep 2010 10:06:15 -0400

On Wednesday, September 01, 2010 08:23:19 am John Levine wrote:
> >If that's all we can say, I'd say don't bother.  I don't see much value in
> >the DKIM working group saying it thinks mail should be signed by DKIM.
> 

Since things to do to get signatures to survive on mailing lists doesn't seem 
to be on your list of stuff we agree on, what else is?  I know you said e.g., 
but given what I understand you to not agree on, I'm not sure what else is 
left.

Scott K

---

From: Michael Thomas <[email-masked]>
Date: Wed, 01 Sep 2010 07:24:52 -0700

> things they've never done before.

Frankly, the best possible advice we can give is to tell people to
sign all their mail, set ADSP to discardable and let mailing list
mail get to sent to the trash can. If that doesn't get the hidebound
traditionist over-entitled mailing list developers and operators
attention, they pretty much deserve dying along with their 1970's
view of what the internet is.

Mike

---

From: <[email-masked]>
Date: Wed, 1 Sep 2010 07:57:27 -0400

+1

---

From: Steve Atkins <[email-masked]>
Date: Wed, 1 Sep 2010 13:47:28 -0700

> view of what the internet is.

ADSP is badly flawed, but those flaws don't have much impact in the case of junk mail sent directly from senders to the MXes of consumer ISPs. Junk mail sent to consumers is also the main place where the theoretical benefit of ADSP is likely to be of value (assuming that's still anti-phishing).

If your goal is to have MLM developers rewrite their perfectly working code to work around the fundamental flaws in ADSP - a protocol nobody other than bulk mailers is interested in, and which in any even marginally sane deployment would never interact with mailing lists at all - I think you're going to be disappointed.

If you don't want to be disappointed you'd be better saying something like this ...

  1. Don't publish ADSP for domains that are used for sending any mail other than junk mail

  2. If you pay attention to ADSP use it to discard mail, not reject it

  3. If you run a mailing list, consider refusing submissions from any domain publishing an ADSP record

  4. If you run a mailing list, consider DKIM signing the mail you send

... rather than hoping MLM software developers will remove all the features they offer that might break a DKIM signature.

Cheers,
  Steve

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 1 Sep 2010 14:43:10 -0700

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Scott Kitterman
> Sent: Wednesday, September 01, 2010 4:56 AM
> To: [email-masked]
> Subject: Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
> 

I also submit that a two-paragraph document saying "Lists should sign mail" and "Lists should reject traffic from ADSP discardable domains" is not worth the effort to push through to publication as an RFC.  If that's the kind of clear-cutting we agree on, let's just make them new paragraphs or sections in a revision to the deployment document whenever we get around to it, and declare this document dead.

Personally I do see use in the document's current form.  Although I realize MLMs haven't done the work to preserve signatures in the past, I get the feeling there's desire out there for that to start to happen; receivers want it, for whatever reason, and I don't hear a lot of people coming out against the idea.  Are we really on solid ground telling them "You don't need/don't want/can't have it?"

I find the "Nobody's ever wanted this, why should it change now?" argument about MLM behavior antithetical to the whole DKIM premise.  The same logic there would sound like "Nobody's ever had a reliable identifier on a message before, what makes you think it's needed now?"

Maybe if people say they want preserved author signatures, and we encourage MLMs in the direction of preserving author signatures, and they're willing to give it a go, then it is indeed worth making a more meaty statement about it.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 1 Sep 2010 14:49:01 -0700

> [email-masked]] On Behalf Of Steve Atkins
> Sent: Wednesday, September 01, 2010 1:47 PM
> To: DKIM List
> If your goal is to have MLM developers rewrite their perfectly working
> code to work around the fundamental flaws in ADSP - a protocol nobody
> other than bulk mailers is interested in, and which in any even
> marginally sane deployment would never interact with mailing lists at
> all - I think you're going to be disappointed.

Setting aside ADSP for a second, I think there are still some people that would like to see MLMs preserve author signatures for the purposes of reputation evaluation.

> ... rather than hoping MLM software developers will remove all the
> features they offer that might break a DKIM signature.

Maybe we should let the MLM developers, some of whom are here (or were, maybe they've been scared off) comment?

---

From: Steve Atkins <[email-masked]>
Date: Wed, 1 Sep 2010 15:15:15 -0700

> Setting aside ADSP for a second, I think there are still some people that would like to see MLMs preserve author signatures for the purposes of reputation evaluation.

I'm sure there are people who'd think that'd be nice (if there were no cost to doing so, I'd be one of them) - but I'm also fairly sure that they'd find other approaches which do not cripple MLMs an acceptable alternative.

> Maybe we should let the MLM developers, some of whom are here (or were, maybe they've been scared off) comment?

OK.

I develop code that receives email to one address and forwards it on to another address. It's not intended for use as an MLM, but it does have a number of optional features in common - modifying the subject line to add a tag, rewriting from / reply-to, modifying the body content, adding or removing MIME elements.

It will break DKIM signatures (any that sign the subject line, at the very least) much of the time. I've no intention of removing those features in order to make it not break DKIM signature as, well, they're features that were added because users wanted them.

DKIM signing the mail sent by the MLM is something I support doing. Checking DKIM signature on the inbound is something I don't do now, as there's not been much call for it, but it's something I'd like to add eventually. Recording that inbound authentication data in a header of the forwarded email is something I see as not terribly useful, nor particularly desired by the users I've talked to, but pretty much harmless. 

Lets say we set aside ADSP, as you suggest, and just consider reputation evaluation. Do you believe there are any people who'd not find that that level of authentication tunneling entirely adequate for their needs?

Cheers,
  Steve

---

From: Hector Santos <[email-masked]>
Date: Wed, 01 Sep 2010 18:16:12 -0400

> Maybe we should let the MLM developers, some of whom are here 
> (or were, maybe they've been scared off) comment?

Already did. We a FULL TIME commercial vendor with Mailing List 
Components since 1996.  The engineering I proposed came in th DSAP I-D 
stating the same issues.  Many also agreed here and to talk about it 
other discussion areas.

There is NOTHING new here.  It is about unrestricted 3rd party signers 
and allowing them to exist without issues and the only reason there is 
a revival of the issue it is now YOU with the MLM considerations  - 
anyone else would have been ignored like all these years.

But the issue is too fundamental to common sense engineering - it can 
not go away on its own and not just by some saying "DON'T SUPPORT IT!"

At the end of the day, it is about the piece of C/C++ or whatever 
language code that is going either blinding resign (something new) all 
new era dkim messages (something new) or be restricted using domain 
POLICY.

While POLICY is still on the table as a draft standard, no engineer 
worth their salt should be IGNORING it.  If he does, he has a BUG in 
his software and whether he agrees or not, someone will throw it in 
this face - you are violating RFC 5016..

Your MLM has it right Murray.  It has all the information a MLM author 
needs to go with to do this right.

You guys needs to make your minds regarding policy.

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

---

From: Michael Thomas <[email-masked]>
Date: Wed, 01 Sep 2010 15:26:25 -0700

>> all - I think you're going to be disappointed.

"No Mr. Bond, I want you to die".

> Setting aside ADSP for a second, I think there are still some people that would like to see MLMs preserve author signatures for the purposes of reputation evaluation.

The implicit argument being made amongst the more vocal set here is that
since mailing lists coexisted with cavemen and dinosaurs, that their very
antiquity puts them beyond the scope of evolution. That if it wasn't
intelligently designed in o those 5000 years ago, that they have no
responsibility for the current internet's trials and tribulations.

The fact of the matter is that mailing lists survival or extinction
is utterly irrelevant to the internet at large; if we did harm to them,
nobody using the internet at large would care. Hence all of this hand
wringing about whether mailing list developers or operators will
petulantly stamp their feet and take their marbles home presumes they
have power they do not actually hold.

This draft shouldn't be starting from the perspective of what reactionary
old fogies will or won't do. It should be starting from the perspective
of what's right for email as it's actually used today. If what's right
is that unsigned mail should become a pariah -- which I suspect is the
right thing -- then all of the howls of indignation should just be ignored.
And as is always the case, the whiners will figure something out if the,
uh, laser is positioned correctly.

Mike

---

From: Hector Santos <[email-masked]>
Date: Wed, 01 Sep 2010 18:27:54 -0400

> Lets say we set aside ADSP, as you suggest, and just consider 
> reputation evaluation. Do you believe there are any people
> who'd not find that that level of authentication tunneling 
> entirely adequate for their needs?

But ADSP is in scope of the charter work, and Reputation work is out 
of scope.  Unfortunately, we allowed this type of external reputation 
working mindset to alter, twist and turn the DKIM WG drafts creating 
confusion and consensus chaos making it hard to completing the 
chartered goals.

Accept POLICY as a WG work item and maybe we can come to complete this 
work and maybe many more systems can begin to get more DKIM/ADSP adoption.

---

From: Hector Santos <[email-masked]>
Date: Wed, 01 Sep 2010 18:40:14 -0400

Maybe way to reduce the rhetoric is to hmmmmm, huh, maybe following 
the engineering molded into the WG RFC draft standards and to correct 
the non-WG created DKIM Deployment RFC by not allowing it to suggest 
implementators can break the WG RFC draft standards?

That might help.

---

From: Hector Santos <[email-masked]>
Date: Wed, 01 Sep 2010 19:15:39 -0400

Michael,

I take some level resentment to the "old frog" statements.

List based operations is still a viable part of our market place. As a 
commercial vendor of a integrated mail system that includes a MLS 
component, it is clearly something that is used as an everything thing 
for many use cases.  While some old frogs are mostly list operators 
and use LIST systems predominantly one way, the old frog software 
people have to create it with features for a wide range of 
implementations usages.

This old frog is saying is that we are asked to do something new 
(DKIM) for our MLS software, then it has to be engineered right to 
support ADSP as well.  It can't be ignored.

But I can see other old FROG operators are stuck with a plug and play 
situation where they can only sign mail blindly.  We can't do anything 
about legacy operations and you are correct that we should not allow 
the legacy Old Frog list operator dictate what can't be done or done 
as a standard for all list usages.

We can do something with new technology being incorporated by active 
systems.  We can create consistent protocol engineered drafting among 
the standard and informational RFC and I-Ds.

That is really all this old frog is looking for.  No "Rippet" mas!

---

From: Steve Atkins <[email-masked]>
Date: Wed, 1 Sep 2010 15:52:59 -0700

> uh, laser is positioned correctly.

You want to optimize email for sending bulk mail. That's one of the main things DKIM is good for, and it's pretty much the sole domain of ADSP.

You're not the only one who wants to do that, not by a long way. And the vast majority of email, by messages sent, is bulk email so doing some work to make that work better (such as DKIM, say) isn't a bad idea.

But when you go on to try and optimize the email system for junk B2C email at the expense of communication between individuals and groups then I think that's harmful to the ecosystem.

The 95% of emails that are B2C bulk mail are not more important than the 5% that are communication between individuals.

Cheers,
  Steve

---

From: Douglas Otis <[email-masked]>
Date: Wed, 01 Sep 2010 16:44:38 -0700

On 9/1/10 2:49 PM, Murray S. Kucherawy wrote:
> > On Wednesday, September 01, 2010 1:47 PM, Steve Atkins wrote:
> >
> > If your goal is to have MLM developers rewrite their perfectly
> > working code to work around the fundamental flaws in ADSP - a
> > protocol nobody other than bulk mailers is interested in, and which
> > in any even marginally sane deployment would never interact with
> > mailing lists at all - I think you're going to be disappointed.
>
>  Setting aside ADSP for a second, I think there are still some people
>  that would like to see MLMs preserve author signatures for the
>  purposes of reputation evaluation.

Because DKIM does not affirm either the destination or return path of a 
message, it would offer an extremely vulnerable basis for establishing 
reputations based upon receipt of unsolicited messages.   It would be 
far better to develop cryptographic methods to authenticate SMTP clients 
instead.  This would then mean MLM developers do not need to change any 
of their code.  The need for a cryptographic SMTP client authentication 
mechanism will quickly become more apparent as more email is exchanged 
over IPv6 networks.

>  Maybe we should let the MLM developers, some of whom are here (or
>  were, maybe they've been scared off) comment?

Such a change would be a move in the wrong direction.  It would make 
messages distributed by mailing lists visually identical to those from 
individuals, where they become more dangerous from a phishing 
perspective.  Avoiding false positive phishing detection was a reason 
for DKIM, and anti-phishing was the reason for ADSP, after all.  Few see 
the DKIM signature, know what portion of the message body was signed, or 
whether the From domain is accurate.  The from header is normally not 
assured when distributed through a mailing list.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Wed, 01 Sep 2010 22:27:46 -0400

Murray S. Kucherawy wrote:

>> Steve Atkins

> Setting aside ADSP for a second, I think there are still some 
> people that would like to see MLMs preserve author signatures 
> for the purposes of reputation evaluation.

Yes.

But two things:

    1) What is forgotten is what the author domain wants and,

    2) The unknown world of reputations services or
       non-standard assessment engines being used.

 From the perspective of an developer, if the technology is available 
with the 100% goal to address these type of issues, it should not be 
excluded as part of MLM+DKIM+ADSP offerings.

For example Murray.  Lets say I want to be flexible here and I provide 
the list options:

    [X] DKIM sign list mail
        [X] Check for ADSP domains

Then this list operator will help in short circuiting DKIM related 
issues regarding restrictive policy domains.

     Problem: We are being asked to not offer the
              [X] Check For ADSP domains option. We
              are being asked to ignore RFC 4686, 5016
              and 5617.

But I can see where someone doesn't want to enable the option, so the 
other options to consider:

    [X] DKIM sign list mail
        [_] Check for ADSP domains
        [?] Strip broken signatures

There are two design motivations for having the strip enabled or not.

1) Enabled: [X] Strip broken signatures

This makes it consistent with RFC 4871 when DKIM verifiers follow the 
mandate in 4871 to ignore broken signatures as no signature. 
Reputation engines that do no follow this are violating the 
specification because they should not be using the broken signature 
for any scoring or weighting.

2) Disabled: [_] Strip broken signatures

This only time this is valid is when the assessors are using a broken 
signature fault condition as a "data point" for their assessment.  The 
assumption is these assessors will be ignoring RFC 4871 Invalid To No 
Signature and are also ignoring RFC 4686, 5016 and 5617 regarding the 
POLICY security related standards because if they did support them, 
then they will be immediately filtered.

So #1 is more protocol consistent from a DKIM VERIFIER standpoint, and 
#2 is not which could only exist when 4871 Broken to No Signature is 
ignored and ADSP is not part of the framework.

The above options are possible, but only one is DKIM protocol correct 
as the draft standards are written.

I think your MLM covered both sides with its statements and teaches 
MLM developers what they need to do.

If by change the POLICY related drafts and also the threat/security 
provisions were removed, then I have no problem just having:

    [X] DKIM sign list mail
        [_] Strip broken signatures

as defaults because know we really need to have ASSESSORS out there 
that ignore the 4871 Broken to No signature status.

For list operators that enable the stripping, well, who knows what 
will happen, but I can only imagine it will create a climate that the 
3rd party signer trust is the only that counts and nothing else and 
all members have whitelisted the list or has signed up to some common 
reputation service - hmmm a POLICY for LIST domains!

---

From: "John R. Levine" <[email-masked]>
Date: 2 Sep 2010 11:33:55 +0200

> Maybe we should let the MLM developers, some of whom are here (or were, maybe they've been scared off) comment?

Hi.  That would include me, one of the people who do occasional 
development on majordomo2.

I have added code to mj2 to pass the list domain to the shim I use for 
outbound signing, so my outbound list mail has a signature from the list 
domain, along with the MTA signature that all the mail has.  mj2 has an 
unusually complex set of options for handling incoming mail, and I haven't 
yet decided what, if anything, to do with incoming signatures.  I might 
remember the signature on a user's signup and confirmation mail, and add a 
variable that people can test to see if an incoming message has the same 
signature as the remembered one, so they can use it to bypass some of the 
checks, e.g., large messages or some kinds of MIME parts, although it is 
far from clear whether anyone would use it.

In the decade I've been using mj and mj2, I cannot ever remember anyone 
ever expressing any concern about recipients verifying the identity of 
contributors.  (For that matter, I don't recall anyone asking about MTA 
verification of contributors beyond the usual from: address.)

I haven't decided whether to strip of incoming DKIM signatures, but that'd 
be easy, just add a line to the existing configurable list of headers it 
strips already.

I don't currently do anything about ADSP. Unless a lot more people use it 
than I expect, I probably won't.  If I do, it'll just be to discard mail 
from discardable domains.  mj2 doesn't run at SMTP time so there's no way 
to reject it.

R's,
John

---

From: "John R. Levine" <[email-masked]>
Date: 2 Sep 2010 11:35:56 +0200

> uh, laser is positioned correctly.

So I take it you agree that lists should sign their outgoing mail?

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 02 Sep 2010 19:35:16 +0200

On 01/Sep/10 23:43, Murray S. Kucherawy wrote:
> Personally I do see use in the document's current form.  Although I
> realize MLMs haven't done the work to preserve signatures in the
> past, I get the feeling there's desire out there for that to start
> to happen; receivers want it, for whatever reason, and I don't hear
> a lot of people coming out against the idea.  Are we really on
> solid ground telling them "You don't need/don't want/can't have
> it?"

+1: if DKIM works it should also work for MLMs.

However, the other issue is to break or remove author domain 
signatures.  John has pointed this out since a long time, for FBL 
reasons.  Doug has brought out the same issue for replaying attacks 
aimed at breaking reputation, because replaying is definitely out of 
control in case of publicly distributed messages.

Mutually exclusive as they may seem, those two issues together simply 
beg for the ability to take just the extent of responsibility that a 
signer deems correct, given the recipients for the message at hands.

I repeat the two proposals that have been made, and ask once more 
whether there are further ways to achieve similar results.

Charles' From-%-rewriting.
It seems the WG disagrees with it.  However, it has also been 
mentioned that some MLMs already change the From.  Should it be 
forbidden?  If not, I see no reason not to document it.

Joint Signatures.
I haven't seen many opinions on this proposal of mines.  Anyone?  Here 
are some pointers:
last paragraph in 
http://mipassoc.org/pipermail/ietf-dkim/2010q3/014008.html
http://mipassoc.org/pipermail/ietf-dkim/2010q3/013881.html
http://mipassoc.org/pipermail/ietf-dkim/2010q3/013829.html
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 02 Sep 2010 19:39:31 +0200

On 02/Sep/10 00:15, Steve Atkins wrote:
> I develop code that receives email to one address and forwards it
> on to another address. It's not intended for use as an MLM, but it
> does have a number of optional features in common - modifying the
> subject line to add a tag, rewriting from / reply-to, modifying the
> body content, adding or removing MIME elements.

I think that software is included in the broad definition of 
"resending MLM" given in draft-ietf-dkim-mailinglists.

Are senders aware that the messages they send to that address will be 
forwarded the way you say?  In case they are not, is that a feature or 
would the software let the sender know, e.g. by answering "251  User 
not local; will forward to <forward-path>"?

May I also ask how does the admin specify that forward-path?  Has the 
final recipient's MTA to be aware of the forwarding, e.g. for 
whitelisting?  Have you considered SMTP-AUTH as a whitelisting means?

> It will break DKIM signatures (any that sign the subject line, at
> the very least) much of the time. I've no intention of removing
> those features in order to make it not break DKIM signature as,
> well, they're features that were added because users wanted them.

Fine, IMHO.

> DKIM signing the mail sent by the MLM is something I support doing.
> Checking DKIM signature on the inbound is something I don't do now,
> as there's not been much call for it, but it's something I'd like
> to add eventually. Recording that inbound authentication data in a
> header of the forwarded email is something I see as not terribly
> useful, nor particularly desired by the users I've talked to, but
> pretty much harmless.

It should quite straightforward for the hosting MTA to add an A-R field.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 2 Sep 2010 10:42:16 -0700

> [email-masked]] On Behalf Of Alessandro Vesely
> Sent: Thursday, September 02, 2010 10:35 AM

What's the danger of replaying legitimate mail, other than to cause volume detection alarms to go off?

---

From: Steve Atkins <[email-masked]>
Date: Thu, 2 Sep 2010 11:01:38 -0700

On Sep 2, 2010, at 10:39 AM, Alessandro Vesely wrote:

> I think that software is included in the broad definition of "resending MLM" given in draft-ietf-dkim-mailinglists.

Yes. It's quite a stretch, but "resending MLM" is a fairly broad category.

> Are senders aware that the messages they send to that address will be forwarded the way you say?

No. The inbound mail is a mixture of 1:1 mail sent to role accounts, ARF reports, replies to email and all sorts of other miscellaneous junk including in some cases asynchronous bounces.

>  In case they are not, is that a feature or would the software let the sender know, e.g. by answering "251  User not local; will forward to <forward-path>"?

It's a feature, I guess. The sender won't be notified of the forwarding in any mechanical way - they generally can't be in the way you mention, as typically the inbound mail will be store-and-forward.

> May I also ask how does the admin specify that forward-path?  

A set of forwarding rules, ranging from very specific ("Any email sent To _this_ address, From _this_ address forward to this other address") to quite general ("If any URL in the body of the inbound mail resolved to an IP address in any of these ranges, forward it on to the associated email addresses"). The admin might be able to produce a list of all the possible recipients, but is likely to have no idea where any given inbound email will go in some cases.

> Has the final recipient's MTA to be aware of the forwarding, e.g. for whitelisting?

Not in any mechanical way. It's likely they'll be whitelisting the inbound mail in some cases, but they'll be doing so based on the forwarder, not on the original author. They may be relying on the original sender for further routing in some cases, but they're not going to care about anything more than the From: and To: fields, nor about any cryptographic authentication of them.

>  Have you considered SMTP-AUTH as a whitelisting means?

smtp auth isn't really useful for anything other than submission, I don't think. It's not a good match here, certainly, not least because the outbound email is store and forward.

> It should quite straightforward for the hosting MTA to add an A-R field.

Easy enough to do, should there be any demand for it.

Cheers,
  Steve

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 02 Sep 2010 20:11:42 +0200

On 02/Sep/10 19:42, Murray S. Kucherawy wrote:
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely

If this message were replayed to all mailboxes in the world, the 
number of complaints might be overwhelming; the more successful spam 
reporting, the more scaring this possibility.  And if anyone uses that 
for tracking domain reputation, it might drop below small integer 
ranges.  In such scenario, one may consider it safer to only sign mail 
destined to trusted recipients.

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Thu, 02 Sep 2010 20:23:56 +0200

Hi, Murray,

> What's the danger of replaying legitimate mail, other than to cause volume detection alarms to go off?

I think Doug was not talking about replaying legitimate mail but illegit 
mail. I believe Doug described this scenario in one of his previous 
messages either on domainrep or here on this list (Doug, excuse me if 
this summary lacks the nuances):

Someone sends a spam-type message from a large ESP to a mailbox he owns, 
somewhere on the Internet. The message is DKIM signed by the ESP. The 
spammer then takes the entire message including complete headers, and 
replays it using different envelope To: addresses and (optionally) 
different envelope From addresses. A verifier find the signature to be 
valid and at the end of the day this type of replay will impact the 
reputation of the ESP.

BTW: if the original message was sent from the ESP via an MLM and the 
MLM re-signs the message, the reputation impact will be on the MLM's 
domain and (in most cases) not the ESP's as the original signatures get 
broken by the MLM in most situations.

/rolf

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 02 Sep 2010 20:32:42 +0200

On 02/Sep/10 20:01, Steve Atkins wrote:
> A set of forwarding rules, ranging from very specific ("Any email
> sent To _this_ address, From _this_ address forward to this other
> address") to quite general ("If any URL in the body of the inbound
> mail resolved to an IP address in any of these ranges, forward it
> on to the associated email addresses"). The admin might be able to
> produce a list of all the possible recipients, but is likely to
> have no idea where any given inbound email will go in some cases.

That must be an interesting "recipe" syntax!

> smtp auth isn't really useful for anything other than submission, I
> don't think. It's not a good match here, certainly, not least
> because the outbound email is store and forward.

It would let the sender know it is whitelisted, though.  Anyway, the 
only non-submission use I've seen is the bot in 
http://service.dkim-reputation.org/

Thanks for your answers

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 2 Sep 2010 11:43:46 -0700

> From: Alessandro Vesely [mailto:[email-masked]]
> Sent: Thursday, September 02, 2010 11:12 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]

Isn't reputation specifically out of scope though?

I don't see that this is an issue this WG can address, unless we want to tackle the issue of doing something DKIM-like at the connection level.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 2 Sep 2010 11:45:20 -0700

Hi Rolf,

> From: Rolf E. Sonneveld [mailto:[email-masked]]
> Sent: Thursday, September 02, 2010 11:24 AM
> To: Murray S. Kucherawy
> Cc: IETF DKIM WG

All true, but this isn't anything new.  I remember this came up ages ago, before even RFC4871 was published.

If the concern is reputation impact, there's a different venue where that should be discussed.  Reputation is specifically out of scope here.

---

From: Hector Santos <[email-masked]>
Date: Thu, 02 Sep 2010 14:54:55 -0400

Murray S. Kucherawy wrote:
>> Alessandro Vesely

> What's the danger of replaying legitimate mail, other than 
> to cause volume detection alarms to go off?

I think the issue is that we don't know what the assessors do, if
anything. We won't know how stripping or keeping broken signatures
will *warm* up these heuristic/reputation based assessors with
indeterminate DKIM messages.

BTW, it really has nothing to do with ADSP because it applies to
reputation services as well.

Here is a possible scenario:

A ISP begins to offer a 3rd signing service to its email hosting
domains, The ISP is intent to get its signing domain registered with
every known reputation and domain certification service bureau
existing or startups.

So I sign up (at $5, $10 extra per month or free perhaps) and now all
my mail is signed by the 3rd party ISP domain.

I forget about all that and one day I see this great list I want to
subscribe to.  I do and unbeknowst to me, the list is blindly
resigning the mail.

Unless the LIST domain is part of the same "registration" the ISP did
with all the new reputation and domain certification services out
there,  I  now lost my $5, $10 value of using my ISP's 3rd party
signing service - thru this list stream.

Either way, it all goes back to a centralization concept of some form,
network of reputation services or a self-asserting DNS domain policy.

Until we have a understanding of how the many assessors will work,
separately or in concert, we have no idea how indetermine DKIM mail
will warm up these systems with stripped or kept broken signatures.

In the mean time, the better solution possible today is to allow the
self-asserting domain to declare it expectation and policies for mail
distribution if only for one reason - to maintain a high benefit of
1st party signatures while you guys figure out how LIST systems ought
to work.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 02 Sep 2010 16:09:27 -0700

On 9/2/10 11:23 AM, Rolf E. Sonneveld wrote:
>>> On Thursday, September 02, 2010 10:35 AM Alessandro Vesely wrote:
>>>
Rolf,

You're close.  Bad-actors can't use different From header fields, 
because this field MUST be signed.   Also, they'll likely have a 
collection of messages to send en masse within a short period before 
exploiting different accounts.  To defend against this problem, ESP 
could utilize one of their subdomains to sign their messages, and assert 
ADSP dkim=tpa-path for their domains used to exchange email.

For those that implement ADSP, they would see less spam, and the 
TPA-Label would also allow providers a means to stipulate which sources 
they authorize to replay their message.  In addition, the TPA-Label also 
stipulates how SMTP clients are to be authenticated prior to acceptance, 
to make this easier for recipients.  This should also offer ESPs a level 
of protection from lax reputation services that fail to authenticate the 
domains being assessed.

-Doug

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 2 Sep 2010 16:26:45 -0700

On Sep 2, 2010, at 11:54 AM, Hector Santos wrote:

> I think the issue is that we don't know what the assessors do

Some of us have a pretty good idea.  The people who design reputation systems don't do so in a vacuum; they're constantly reacting to spammers' latest tricks.  If massive unauthorized replaying of unmodified DKIM-signed messages ever becomes a real issue, they'll adjust accordingly.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 02 Sep 2010 16:37:19 -0700

> Some of us have a pretty good idea.  The people who design reputation systems don't do so in a vacuum; they're constantly reacting to spammers' latest tricks.  If massive unauthorized replaying of…
Were DKIM domains to become a primary basis for message acceptance, then 
replayed messages will become a real issue.  The question is "Then what 
strategy is needed next without expecting the world to change how 
applications handle email."  One answer might be TPA-Labels applied at 
the transport level during message exchange. :^)

-Doug

---

From: Hector Santos <[email-masked]>
Date: Thu, 02 Sep 2010 20:01:22 -0400

J.D. Falk wrote:
> Some of us have a pretty good idea.  The people who design reputation 
> systems don't do so in a vacuum; they're constantly reacting 
> to spammers' latest tricks.  If massive unauthorized 
> replaying of unmodified DKIM-signed messages ever becomes a real 
> issue, they'll adjust accordingly.

Of course.  But what do you (I guess one system speaking for the 
myriad of assessors) want DKIM mail breaking resigners to do?

    A) Strip Signature
    B) Keep Invalid Signatures

How do MLM developers help you guys do a better job?  How do we warm 
you up with reduced false positives?  Give us a purpose, a reason to 
do this stuff, and do so correctly?

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 03 Sep 2010 11:51:26 +0200

> Isn't reputation specifically out of scope though?

No, that's true for the /development/ of reputation systems.

> I don't see that this is an issue this WG can address, unless we want to tackle the issue of doing something DKIM-like at the connection level.

In part, the issue is being addressed in draft-ietf-dkim-mailinglists 
already.  I'm questioning whether we can get away with saying that a 
MLM "is /likely/ to invalidate any or all of" a message's signatures. 
  Reputation considerations suggest that author domains may want MLMs 
to behave consistently in this respect.

Crypto stuff at connection time is a different ongoing task, which may 
be useful in countering replay attacks in general.  Joint signatures 
and From-%-rewriting are two easier and more specific techniques for 
describing how responsibility is transferred when a message transforms 
into another.  I mentioned them in this thread because I deem they are 
worth being considered, each in its niche of suitable use cases.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Fri, 03 Sep 2010 09:57:48 -0400

Douglas Otis wrote:
>> Some of us have a pretty good idea.  The people who design 
>> reputation systems don't do so in a vacuum; they're constantly 
>> reacting to spammers' latest tricks.  If massive unauthorized 

> the transport level during message exchange. :^)

This might be related.

Let me use my bellsouth, now AT&T service provider cell phone accounts 
as an example.

Over the years, they tried to move customers over to electronic 
billing or statements. (Note: My first company, OptiSoft, developed 
and sold turnkey ODSAR (Optical Document Scanning and Retrieval) 
systems, so I know a little about the logistics, cost savings, etc for 
the "paperless" market place.).

Anyway, I continue to refuse to sign up and be associated with any 
online or email based billing/statement for security reasons. But 
eventually, I guess because people were not signing up on their own 
(OPT IN), they began to send the billing statement via email anyway 
with marketing URL hooks to "turn on it on".

I have continued to ignore it but I occasionally check the headers to 
see what they are using.  I was expecting them to be more proactive 
with DKIM (or Domainkeys) but at first I didn't see it. I asked Tony 
Hansen about it. He indicated they will support POLICY once adopted 
but did not say much beyond that.  But I recalled a few times when it 
did become to have DKEY or DKIM, don't recall which.

Now I just got my new statement and there is no DKIM/DKEY but it has 
one of those X-YMailISG header lines.

I know AT&T begun to outsource their U-VERSE and perhaps entire email 
users to YAHOO.

But it always me wonder why did not use at the very least a 1st party 
signature.  That alone would of gave me more "trust" in these 
electronic statements.

Now there is no trust whatsoever as anyone can spoof YAHOO and that 
X-YMailSG header.

It seems to me they are relying on users using the online interface 
where this would be more trust worthy and view Offline copies (via 
POP3 pickups) to be less trust worthy in their eyes, I guess.

It seems to be what they did was promote replay spoofs. So why not use 
a 1st party signature?

If AT&T is my cell provider, and they are sending billing statements 
with URL hooks to join 'Something' and other stuff, they should be 
more concern about what 3rd party clearing house (YAHOO does a long 
time PR problem as a source for spam) they use and understand not all 
users are online.

---

From: Hector Santos <[email-masked]>
Date: Fri, 03 Sep 2010 10:15:37 -0400

> worth being considered, each in its niche of suitable use cases.

I think you need to better appreciate and understand how fundamental 
the "Message" From field for any forms of communications and/or mail 
networks is.  It would be a radical change to open up this door and 
"Pandora box" to make it the norm and mindset that a From: is 
unreliable. Not saying it is not prone to abusive, but fundamentally, 
when people believe in the message, they also make that natural 
trusted tie to the author of the message.  Never mind the gateway 
exchanges and networks using From among the fundamental elements of 
the payload.

That said, I believe what you speaking of is when a mail bot 
completely take over a message from an authorized or intentional 
design basis. i.e. a newsletter, a newspaper article, a read only 
forum, whatever, etc, messaging  usages were the From: is less 
important and more of a "global entity."

Let me ask you this, does this apply to a MLM serving a LIST such as 
this one? IETF-DKIM?   Should it be programmed to change it to?

   From: DKIM POST MASTER <[email-masked]>

or

   From: DKIM POST MASTER ON BEHALF OF XYZ <[email-masked]>

I guess the goal would be to make the resigner a 1st party DKIM 
signature with the From  domain being mipassoc.org.

Even if the MLM was allowed to do this for list of this type, do we 
now also recommend that MIPASSOC.ORG have a ADSP policy?

It sounds like a good idea, but it would a very radical change. I 
don't wish to be part of the group of MTA and MLM that begin to fuss 
around with the 8222.FROM making the mail more unreliable and less 
trustworthy.

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 03 Sep 2010 21:06:09 +0200

On 03/Sep/10 16:15, Hector Santos wrote:
> Alessandro Vesely wrote:
>
>> Crypto stuff at connection time is a different ongoing task, which
>> may be useful in countering replay attacks in general. Joint
>> signatures and From-%-rewriting are two easier and more specific
>> techniques for describing how responsibility is transferred when a
>> message transforms into another. I mentioned them in this thread
>> because I deem they are worth being considered, each in its niche of
>> suitable use cases.
>
> [Importance of From] said, I believe what you speaking of is when a mail bot

Yes, I'm speaking of cases where the From is being rewritten already. 
  Frankly, I don't like that the value of "From" be changed.  However, 
in the regrettable case it is changed, it doesn't hurt if it is 
rewritten in a standardized way.

And how about joint signatures?

> this one? IETF-DKIM? Should it be programmed to change it to?

Please refer to Charles' original proposal for details
http://mipassoc.org/pipermail/ietf-dkim/2010q3/013807.html
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Fri, 03 Sep 2010 12:32:49 -0700

> And how about joint signatures?
Why not use TPA-Labels instead to authorize the third-party signature?
> http://mipassoc.org/pipermail/ietf-dkim/2010q3/013807.html
Such concepts seem to run headlong into IDNA efforts, especially when a 
conversion can not be accommodated.

https://tools.ietf.org/html/draft-ietf-eai-frmwrk-4952bis-07

-Doug

---

From: "John R. Levine" <[email-masked]>
Date: 5 Sep 2010 01:33:14 +0200

> to behave consistently in this respect.

They may want that, but if we're documenting what MLMs do, I don't think 
they can have what they want.  The conditions under which an MLM will 
break a signature are very hard to describe.

As a typical example, many MLMs add a subject line tag, but if the tag is 
already present it leaves the line alone.  So one message might arrive 
with a broken signature, and the next, a response to the first message 
which already has the tag in its subject line, might arrive with a valid 
signature.

So "is likely to invalidate" is as specific as we can reasonably be.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 05 Sep 2010 09:42:22 +0200

On 05/Sep/10 01:33, John R. Levine wrote:
>> I'm questioning whether we can get away with saying that a MLM
>> "is /likely/ to invalidate any or all of" a message's
>> signatures. Reputation considerations suggest that author domains
>> may want MLMs to behave consistently in this respect.
>
> They may want that, but if we're documenting what MLMs do, I don't
> think they can have what they want.  The conditions under which an
> MLM will break a signature are very hard to describe.

Correct.  Still, signatures can be removed, which --by symmetry-- is 
tantamount to breaking them.  Similar effects can also be achieved 
using slightly more sophisticated techniques...

> [...example snipped...]

Yes, under the assumption that we're documenting what MLMs do.  This 
brings us back to the informative vs. normative dilemma.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "John R. Levine" <[email-masked]>
Date: 6 Sep 2010 01:12:25 +0200

> brings us back to the informative vs. normative dilemma.

I don't see how we can say anything normative to MLM or MUA developers. 
That's not the business we're in.

We can certainly document what MLMs do, and describe what we have found to 
be effective, but I really don't think that there's any benefit to 
describing in this document hypothetical paper designs for anything, much 
less for large changes to MLMs for goals for which we have no consensus. 
(An experimental RFC for paper designs would still be fine.)

Re paper vs. implemented designs, I have actually added DKIM signing to my 
MLM software and have been using it in production for many months.  Has 
anyone else?

Mike has done a bunch of work on signing outgoing mail and trying 
heuristics to reconstruct signatures on mail coming back from MLMs, but 
that's different.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 06 Sep 2010 20:35:39 +0200

On 06/Sep/10 01:12, John R. Levine wrote:
>> [about] the informative vs. normative dilemma.
>
> I don't see how we can say anything normative to MLM or MUA
> developers. That's not the business we're in.

Please forgive my ignorance on standardization issues.  But doesn't a 
simple piece of advice, such as <<if rejecting for ADSP reasons, 
please use some

   554 *ADSP*

kind of reply>>, require a normative status?  Of course none of those 
are legally enforced, they are just practices for making the Internet 
interoperable...

> We can certainly document what MLMs do, and describe what we have
> found to be effective

Possibly, the From-%-rewriting belongs there, as someone said some 
lists do that (which ones?)

> but I really don't think that there's any benefit to describing in
> this document hypothetical paper designs for anything, much less
> for large changes to MLMs for goals for which we have no consensus.

That "joint signatures" idea of mines presumably would have required 
an experimental I-D.  However, I don't think I'll write any further 
about it, since there's no apparent interest (why, is it so ugly?)

Thank you for your patience.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Wed, 08 Sep 2010 20:30:34 -0400

John R. Levine wrote:
>> Maybe we should let the MLM developers, some of whom are here (or were, 

> than I expect, I probably won't.  

It has to begin somewhere John.  If you added supports, I feel real 
good that others will follow - especially me. Once begins with catch 
on with software, I feel pretty certain more domains will begin to use it.

Seriously, there is nothing more powerful when the creator of a 
product or idea or method champions his own creation.

So take a chance - add support. Even as an Option (off by default if 
you think that is better for you) but given people the ability to 
explore it.

Say the word - add POLICY support and I can almost guarantee you there 
will be a 2nd MLS product on the market in short order with DKIM and 
POLICY support.

We all know the short term will be mostly overhead - we known that a 
long time. But it has to state somewhere and if the author of ADSP was 
the 1st to support it - wow! I mean WOW that will certainly change 
things. And honestly, I don't think it will affect any of the 
reputation and 3rd party vouching stuff.  In fact, I think it can even 
help that market even more. Maybe all it will take is a LDSP (List 
Domain Signing Practice) protocol to augment ADSP. I see it. Maybe you 
can to.

Please give us a reason to add DKIM support - I really don't like the 
unknown verifiers out there playing a GUESSING games with DKIM signed 
mail.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 10 Sep 2010 19:11:25 +0100

> forbidden?  If not, I see no reason not to document it.

The problem is that too many people on this WG take the view "I believe in  
solution-X (TPA, PGP-MIME, don't use ADSP because it's broke, don't use  
mailing list if you advertise 'discardable') and I will vote down any  
solution other than X".

And all these so-called solutions have some downside or other (yes, mine  
does too).

BUT AFAICS noone has shown any flaw whereby my proposal would not fix the  
problem, and noone has shown that it opens the door to any scam that was  
not possible already.

So if it works, we should document it as ONE OF THE POSSIBLE TOOLS that an  
MLM might use.

Really, it is up to the MLM, who understands the purpose of his list and  
the nature of his subscribers, to decide whether and how to fix the  
problem. And note also that my solution need not be used except on those  
messages that might not survive without it.

As to the argument that "we don't document things that are not already in  
current use", well that is a classic chicken and egg problem. In real life  
you have to start somewhere.

-- 
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: "Charles Lindsey" <[email-masked]>
Date: Fri, 10 Sep 2010 19:27:36 +0100

On Fri, 03 Sep 2010 15:15:37 +0100, Hector Santos <[email-masked]> wrote:

> trusted tie to the author of the message.

Yes, but nobody is trying to change that. We seem to be agreed that what a  
mailing list sends is, from some POV, a "new" message, and so logically a  
new "From:" is not wholly out of order.

>    From: DKIM POST MASTER ON BEHALF OF XYZ <[email-masked]>

Well the 2nd one is better, and it would be better still to encode the  
same stuff within the address (e.g by a %-hack).

Since MUAs usually display the From, but often not much else, then it is  
reasonable for it to contain all useful information about where it came  
from.

So it would be useful to know who was the original author, but it is also  
useful to know that it passed through (and was modified by) the MLM.

> signature with the From  domain being mipassoc.org.

Yes, especially if he has just destroyed some valid signaturethat was  
there previously.
> now also recommend that MIPASSOC.ORG have a ADSP policy?

Whether and how to do such things is at the discretion of the MLM. He does  
whatever will make his list function smoothly. All we need is some  
generally accepted conventions so that we do not get arbitrary  
differences. An informational document is a suitable way to propose such  
conventions. Later on it might be elevated to a BCP if it becomes widely  
adopted.

---

From: Steve Atkins <[email-masked]>
Date: Fri, 10 Sep 2010 12:17:47 -0700

> new "From:" is not wholly out of order.

What's the benefit to this, though, other than obscuring the original
author?

Cheers,
  Steve

---

From: "John R. Levine" <[email-masked]>
Date: 10 Sep 2010 15:34:40 -0400

> mailing list if you advertise 'discardable') and I will vote down any

Call me old-fashioned if you will, but I take the view that a purely 
hypothetical paper design to address a largely hypothetical problem, with 
unknown security problems, unknown user interface problems, and unknown 
interoperation problems have no place in a document about actual e-mail 
practice.

If this is a viable solution to an important problem, why haven't you 
implemented it yet?  There's no shortage of open source MLMs to adapt.

"Running code and rough consensus" requires running code, you know.

R's,
John

---

From: "J.D. Falk" <[email-masked]>
Date: Fri, 10 Sep 2010 14:53:57 -0700

+1

It's the difference between Best Current Practices and Things We Thought Of But Haven't Tried Yet.  Either could be published as an I-D, but we shouldn't try to fit both approaches into the same BCP.

---

From: "J.D. Falk" <[email-masked]>
Date: Fri, 10 Sep 2010 15:04:56 -0700

> It's the difference between Best Current Practices and Things We Thought Of But Haven't Tried Yet.  Either could be published as an I-D, but we shouldn't try to fit both approaches into the same BC…

Forgot to mention: I'd totally support the creation of a separate draft listing Things We Thought Of But Haven't Tried Yet, so long as it's clearly labeled.

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 10 Sep 2010 17:31:56 -0400

On Friday, September 10, 2010 03:17:47 pm Steve Atkins wrote:
> > Yes, but nobody is trying to change that. We seem to be agreed that what
> > a mailing list sends is, from some POV, a "new" message, and so
> > logically a new "From:" is not wholly out of order.
> 

If you agree with John Levine's proposal that mailing list mail is, in 
general, not a problem then there is negative value in mailing lists throwing 
away (discarding) good mail from domains that happen to use ADSP Discardable 
(or any other mechanism for inferring something from the lack of a signature - 
this isn't really ADSP specific, it's just the implementation we have at the 
moment).  If this negative event can be avoided by the simple mechanism of 
using a mailing list specific "Message" From, then that is a benefit.  This is 
not the only potential use of such a feature.  I've spoken to one MLM 
developer who told me the feature has been previously requested for privacy 
reasons nothing to do with DKIM or ADSP.

I think this is quite reasonable as it would inoculate MLM users from ADSP (or 
similar) problems in a way that does not limit their ability to promote 
communication among their subscribers (which is what mailing lists do).

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 10 Sep 2010 18:18:53 -0400

On Friday, September 10, 2010 05:53:57 pm J.D. Falk wrote:
> >> The problem is that too many people on this WG take the view "I believe
> >> in solution-X (TPA, PGP-MIME, don't use ADSP because it's broke, don't
> >> use mailing list if you advertise 'discardable') and I will vote down
> >> any solution other than X".
> > 
> It's the difference between Best Current Practices and Things We Thought Of
> But Haven't Tried Yet.  Either could be published as an I-D, but we
> shouldn't try to fit both approaches into the same BCP.

It's not clear to me that there's consensus that anything qualifies as Best 
Current.  We have some small samples of a few things that some people have 
tried, but I don't sense we're there yet.

Scott K

---

From: Steve Atkins <[email-masked]>
Date: Fri, 10 Sep 2010 15:37:46 -0700

On Sep 10, 2010, at 2:31 PM, Scott Kitterman wrote:

> using a mailing list specific "Message" From, then that is a benefit.

Rather than go into the general reasons why I think this is not
something that ADSP users really want, I'll give a concrete
example.

Lets say this mailing list rewrites the From: address in some
reasonably mechanical manner, and the From: field of
this message were rewritten as (making up syntax on
the fly)...

From: [email-masked]

... such that recipients (or their MUAs) know that this mail
was sent by [email-masked] via a mailing list at
dkim.org.

There's nothing to stop me from sending mail
From: [email-masked], as
the mailing list isn't using ADSP. And there's certainly
nothing to prevent me from sending mail from
[email-masked] that has
a valid first-person signature.

That means that, as far as the end user is concerned,
I can send them email that is "from" [email-masked],
even though paypal.com is using ADSP to ask receivers
to discard mail that claims to be from paypal.com but
is not validly signed by paypal.com.

Given the whole point of ADSP is "Discard if you're not
sure", I don't think that's what an ADSP using domain
would want.

(The effect is softened somewhat if you use random
from addresses with no connection to the real address,
but only somewhat. And that damages the communication
between users quite a bit more. That's what I meant when
I talked about obscuring the author, upthread).

>  This is 

That would be "for obscuring the original author", and
it's certainly possible for MLMs to do that now, though few
do.

> communication among their subscribers (which is what mailing lists do).

I don't think it inoculates them against ADSP problems - rather
it opens them up to violations of the security model that ADSP
would like to impose.

Cheers,
  Steve

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 10 Sep 2010 15:09:55 -0700

> [email-masked]] On Behalf Of J.D. Falk
> Sent: Friday, September 10, 2010 3:05 PM
> To: DKIM List
> Forgot to mention: I'd totally support the creation of a separate draft
> listing Things We Thought Of But Haven't Tried Yet, so long as it's
> clearly labeled.

I think that's one of the things Dave was suggesting, namely that value-add MLM stuff could be split off into a new document, separating it from the MLM-DKIM issues having to do with ADSP, re-signing list mail, stripping signatures, etc.

Maybe to get things moving I should make a list of the major (and maybe even the minor) points the current draft makes, and people can cast opinions along the lines of "leave it where it is", "separate document", "drop completely".  The current cacophony of guidance makes it hard to evolve the document in any direction.

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 10 Sep 2010 18:46:48 -0400

On Friday, September 10, 2010 06:37:46 pm Steve Atkins wrote:
> >>> On Fri, 03 Sep 2010 15:15:37 +0100, Hector Santos <[email-masked]>
> > 
> > wrote:
> >>> Yes, but nobody is trying to change that. We seem to be agreed that
> >>> what a mailing list sends is, from some POV, a "new" message, and so
> > general, not a problem then there is negative value in mailing lists
> > throwing away (discarding) good mail from domains that happen to use
> > ADSP Discardable (or any other mechanism for inferring something from
> > the lack of a signature - this isn't really ADSP specific, it's just the
> > implementation we have at the moment).  If this negative event can be
> > avoided by the simple mechanism of using a mailing list specific
> > "Message" From, then that is a benefit.
> 
> > developer who told me the feature has been previously requested for
> > privacy reasons nothing to do with DKIM or ADSP.
> 
> > I think this is quite reasonable as it would inoculate MLM users from
> > ADSP (or similar) problems in a way that does not limit their ability to
> > promote communication among their subscribers (which is what mailing
> > lists do).
> 
This is only true if John is wrong and mailing lists are a vector that we need 
to worry about.  I happen to generally agree with him on this.

Scott K

---

From: Steve Atkins <[email-masked]>
Date: Fri, 10 Sep 2010 16:01:27 -0700

On Sep 10, 2010, at 3:46 PM, Scott Kitterman wrote:

> to worry about.  

Doing what you suggest would avoid the problems of legitimate
email being discarded due to ADSP/mailing list interactions at
the cost of allowing phishers to send email "from" a sender
violating the ADSP security model simply by pretending to be
a mailing list.

> I happen to generally agree with him on this.

Me too. But you're breaking the ADSP security model for all
email with your suggestion. Note that neither of the examples
I gave involved me sending a phishing email via a mailing
list.

Cheers,
  Steve

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 10 Sep 2010 16:34:36 -0700

> What's the benefit to this, though, other than obscuring the original

If the mailing list system is, really, merely re-posting a message, with only 
minor annotations, so that the core semantic of the mechanism is address 
fan-out, then the message is, really, "from" the original author, and not "from" 
the list.

If the mailing list system is, really, taking the original message and doing 
substantial massaging/creating of content, then the message is, really "from" 
the mailing list system and not the original author.

In the latter case, it makes sense to have a different From: field.  Daily 
digests are an example of this.

Note that the decision is ultimately subjective and it pertains to expectations 
at the human level.  It's not simply a mechanical issue.

d/

-- 

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

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 10 Sep 2010 19:10:32 -0400

>I gave involved me sending a phishing email via a mailing
I don't think it breaks it. It avoids it and I think that's fine.

Whatever limited value ADSP provides, it is only relevant to exact domain phishing.  What we are describing is a putative weakness that's already beyond it's design scope.

Scott K

---

From: John Levine <[email-masked]>
Date: 11 Sep 2010 01:25:01 -0000

>Forgot to mention: I'd totally support the creation of a separate
>draft listing Things We Thought Of But Haven't Tried Yet, so long as
>it's clearly labeled.

Of course.  This is the Experimental I-D and perhaps RFC that I've
been encouraging people with paper designs to write.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Fri, 10 Sep 2010 21:28:59 -0400

Charles,

Lets keep in mind that when a backend has control of a online MUA, it 
has full control of the display rendering and could do practically 
anything to a convey an "intent" for the user:

    From: Original Author
    Note: 1st party signature removed by the MLM agent XYZ
    Note: 3rd party signature is valid

and given the direction of communications where greater centralization 
and small/thin devices, the backend has full control to display 
exactly what it wishes to convey.

But when you don't have control with store and forward technology, you 
have to use standards to provide standard information for the external 
MUA most common display rendering methods to date.

Once you begin to open the door with changing the 5322.from with 
middle ware, I see nothing but trouble, especially in legal areas.

One can even suggest in some "spec"

     - you MAY alter the FROM when its was DKIM signed
       but you need to break the signature

and tomorrow, you will find NON-DKIM reasons or worst no reason for 
changing the From.

How will know when the original author was lost?

---

From: John Levine <[email-masked]>
Date: 11 Sep 2010 02:08:31 -0000

>tried, but I don't sense we're there yet.

I hope that lists signing their outbound mail qualifies.  Large
providers Googlegroups and Yahoogroups do it, small providers
including MAAWG and myself also do.

Beyond that, you're right, we're at best guessing and at worst pulling
stuff out of our whatevers.

R's,
John

---

From: John Levine <[email-masked]>
Date: 11 Sep 2010 02:18:08 -0000

> This is not the only potential use of such a feature.  I've spoken
> to one MLM developer who told me the feature has been previously
> requested for privacy reasons nothing to do with DKIM or ADSP.

That sounds like a somewhat different feature.  What we've been
talking about so far is basically the old percent hack, embedding one
address in another in a way that makes it obvious what the embedded
address is.  A privacy feature would presumably use an opaque token
that only the MLM could relate to the target address.  They deal with
different problems, and I can see a lot more merit in the blinding
than in the percent hack.  There's prior art for both which anyone
planning to implement something should be aware of, e.g. every mailer
in the 1980s and 1990s that had a percent hack or equivalent, and
blinded remailers like anon.penet.fi.

For the zillionth time, anyone who actually thinks this is worth doing
should spend an hour and WRITE IT DOWN as an Experimental I-D.  If it's
not worth documenting, it's certainly not worth implementing.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 10 Sep 2010 22:19:25 -0400

>stuff out of our whatevers.
Which brings us back to the question of the value of the DKIM working group writing an RFC that suggests people should sign mail.  I don't think it has much.

I think an experimental document that amounts to something like "We've thought about this a lot and discussed it and collectively we've got NFC yet what's best yet. Here are some ideas ..." is what's most needed.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Fri, 10 Sep 2010 22:52:38 -0400

> Which brings us back to the question of the value of the DKIM working 
> group writing an RFC that suggests people should sign mail.  I don't think 
> it has much.

There only seems to be SSA (special signing arrangements) and Receiver 
Policies utility i.e. yahoo.

> I think an experimental document that amounts to something like "We've 
> thought about this a lot and discussed it and collectively we've got NFC 
> yet what's best yet. Here are some ideas ..." is what's most needed.

NFC - funny!  Just as good as Murry's Cacophony! :)

Well, one thing for sure with such a cacophony and swamp environment, 
before venturing into such a document, maybe the first rule should be:

   "He who dares to write a document (of any status) better believe in 
it!"

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 13 Sep 2010 11:57:52 +0100

On Fri, 10 Sep 2010 23:37:46 +0100, Steve Atkins <[email-masked]>  
wrote:

>> .....  If this negative event can be avoided by the simple mechanism of

What ADSP users want is irrelevant. This is about what MLMs want (which is  
most likely to ensure that submitted messages reach the whole of their  
list without problems).
> the mailing list isn't using ADSP.

Clearly, mailing lists that do things to the From: SHOULD (even MUST)  
sign, and any RFC documenting my proposal would include that.

But yes, you could currently send a message to this list From: that  
address, but that has nothing to do with whether my suggestion is adopted  
or not. I suspect you would soon find yourself blacklisted by the MLM.

> ... And there's certainly

Indeed, but that is, and has always been, possible, irrespective of  
whether my suggestion is adopted. Phishers have been obfuscating their  
From: headers in such ways since forever.
> sure", I don't think that's what an ADSP using domain

Sure they would, but DKIM as specified does not provide that feature  
except when everything after the '@' is exact.

---

From: "John R. Levine" <[email-masked]>
Date: 13 Sep 2010 10:10:44 -0400

> most likely to ensure that submitted messages reach the whole of their

Right.  The easiest way to do so, assuming you believe that enough people 
will use ADSP to matter, is to discard incoming messages with ADSP 
settings that can cause trouble.  If they say their mail is discardable, 
take them at their word and discard it.

> sign, and any RFC documenting my proposal would include that.

Hmmn.  Since you apparently believe this is a valuable and useful 
proposal, could you remind us why, exactly, you're not writing it?

Writing I-Ds isn't hard.  Lots of us do it all the time.

R's,
John

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 13 Sep 2010 10:19:05 -0400

> [email-masked]] On Behalf Of John R. Levine
> Sent: Monday, September 13, 2010 10:11 AM
> To: Charles Lindsey
> Cc: DKIM
> > What ADSP users want is irrelevant. This is about what MLMs want
(which
> is

I agree that if a signing domain publishes discardable then the MLM
should discard it. Let's apply a little logic here. The types of
mailstreams that have been identified as being suitable candidates for
ADSP discardable have always been ones that would not be appropriate
(bank notifications, etc) for passing through MLMs in the first place.
While an ecard might be sent to all the members of a list, this is
enough of a corner case that if the domain publishes discardable then
that message should be discarded even though it would otherwise be
legitimate.

If a domain publishing ADSP discardable has not gotten control of their
mailstreams then all I can say is "Darwin was right".

> Writing I-Ds isn't hard.  Lots of us do it all the time.

I would have to see the details of the draft before commenting on
whether it makes sense.

Mike

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 13 Sep 2010 11:12:33 -0400

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, September 13, 2010 11:06 AM
> To: MH Michael Hammer (5304); John R. Levine; Charles Lindsey
> Cc: DKIM
> --On 13 September 2010 10:19:05 -0400 "MH Michael Hammer (5304)"
> <[email-masked]> wrote:
> 
> > should discard it.
> If the message is unsigned, right? Otherwise, it should reject it at
SMTP
> time (actually, that might be done by the MTA rather than the MLM). In
> fact
> the MTA should reject (at SMTP time)
> rather than discard such messages, I think.
> 

I have mixed feelings on this. By suggesting reject over discard I think
we possibly open the door up again to Joe jobs.

Mike

---

From: "John R. Levine" <[email-masked]>
Date: 13 Sep 2010 11:38:39 -0400

> If the message is unsigned, right? Otherwise, it should reject it at SMTP 
> time (actually, that might be done by the MTA rather than the MLM). In fact 
> the MTA should reject (at SMTP time) rather than discard such messages, 
> I think.

If it's signed, I agree there's little downside to rejecting it.  But 
since they said it's discardable, there's little advantage to doing so, 
either.

A disadvantage is that it requires the SMTP daemon to do a lot of work, 
do the whole DKIM validation and ADSP lookup before deciding whether to 
reject. You can discard any old time, no need to do it while the TCP 
session is open.

R's,
John

---

From: Ian Eiloart <[email-masked]>
Date: Mon, 13 Sep 2010 16:06:26 +0100

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

---

From: Hector Santos <[email-masked]>
Date: Mon, 13 Sep 2010 12:28:44 -0400

> most likely to ensure that submitted messages reach the whole of their  

And you don't see the conflict here?  Violating at least two standard 
specification, including security document, altering the From, thus 
ensuring a loophole is now viable for further fraud.

You don't want to support ADSP by acknowledging an act of violating it 
by changing the 5322.From?   So you want to change the from because of 
ADSP?   Sounds very odd.

---

From: Ian Eiloart <[email-masked]>
Date: Mon, 13 Sep 2010 16:59:10 +0100

--On 13 September 2010 11:38:39 -0400 "John R. Levine" <[email-masked]> 
wrote:

>> SMTP  time (actually, that might be done by the MTA rather than the
>> MLM). In fact  the MTA should reject (at SMTP time) rather than discard
>> such messages,  I think.
>

No, there really is an advantage. The sender gets to see that they've tried 
to do something that they can't.

> reject. You can discard any old time, no need to do it while the TCP

No need to, but we do *all* our message scanning, including AV and 
spamassassin at SMTP time, because we (a) don't like generating bounce 
messages, (b) don't like blackholing, (c) think that spam mailboxes act 
like blackholes, and (d) don't want to deliver malware anyway. It doesn't 
take a huge resource to do this quite quickly, especially if you reject 
early on RBLs.

Authentication mechanisms like DKIM and SPF might allow us bounce some 
messages, but really it's simpler to do everything while the TCP session is 
open. We have four very old OSX servers doing this, but one could cope with 
the load reasonably well.

---

From: Hector Santos <[email-masked]>
Date: Mon, 13 Sep 2010 12:37:06 -0400

MH Michael Hammer (5304) wrote:
>> Levine wrote:

Too logical Michael. :)

Some would rather not support ADSP yet acknowledge it by changing the 
5322.From (a more drastic earth changing behavior) as a solution to 
THEIR ADSP problem.  HA!

Suddenly I got an urge for roasted peanuts.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 13 Sep 2010 10:46:43 -0700

On 9/13/10 3:57 AM, Charles Lindsey wrote:
>  On Fri, 10 Sep 2010 23:37:46 +0100, Steve Atkins
>  <[email-masked]> wrote:
>
> >> ..... If this negative event can be avoided by the simple
> >> mechanism of using a mailing list specific "Message" From, then
> >> that is a benefit.
> >
>  (which is most likely to ensure that submitted messages reach the
>  whole of their list without problems).

There is the human aspect of recognizing the purported author.  See:

http://tools.ietf.org/html/draft-ietf-eai-mailinglist-07

Where in the introduction there is this comment:
,---
...
Separate from these standardized list-specific header fields, and 
despite a history of interoperability problems from doing so, some lists 
alter or add header fields in an attempt to control where replies are 
sent.  Such lists typically add or replace the "Reply-To" field and some 
add or replace the "Sender" field.  Poorly-behaved lists may alter or 
replace other fields, including "From".
'---
It also seems that both the downgraded and international versions of the 
email-address would need to be recoded.

> > reasonably mechanical manner, and the From: field of this message
> > were rewritten as (making up syntax on the fly)...
> >
> > ... such that recipients (or their MUAs) know that this mail was
> > sent by [email-masked] via a mailing list at dkim.org.
> >
> > There's nothing to stop me from sending mail From:
> > [email-masked], as the mailing list
> > isn't using ADSP.
>
>  address, but that has nothing to do with whether my suggestion is
>  adopted or not. I suspect you would soon find yourself blacklisted by
>  the MLM.

Do you mean the MTA would become blacklisted or the subscriber being 
spoofed?  DKIM does not identify the author.

Defending the MLM might work after all subscribers and the MLM have 
adopted DKIM as a requirement for acceptance.  Otherwise this would 
expect the MLM to check policy on any percent hack email-address without 
there being any defined standard.  For example, VERP uses '=' as a 
replacement symbol for '@' when stacking addresses. BATV and SRS use '=' 
to isolate local-part components.  The '%' symbol is understood by some 
operating systems to indicate a hex conversion is desired.   :^(

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Mon, 13 Sep 2010 10:21:55 -0700

On 09/13/2010 08:59 AM, Ian Eiloart wrote:
>
>
> --On 13 September 2010 11:38:39 -0400 "John R. Levine"<[email-masked]>
> wrote:
>

I really don't know why people who should know better are clinging onto this
nostalgic notion that SMTP-time isn't the right (only) place to do scanning,
but there is a layer violation issue with MLM's. Unless you have a MLM that
is completely purpose-built with SMTP, or has bits and pieces of itself inserted into
milter-like parts of the SMTP stream, your average MTA is going to have
no clue whether it's destined for a MLM or anything else. So any BCP'ish
language which implied that you should SMTP-500 MLM traffic for ADSP
discardable would be... problematic.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 13 Sep 2010 12:13:01 -0700

On 09/13/2010 11:58 AM, Murray S. Kucherawy wrote:
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Thomas
>> Sent: Monday, September 13, 2010 10:22 AM
>> To: Ian Eiloart
>> Cc: DKIM
> Given that I'm currently a strong believer in domain reputation being a big part of the future, I've asked that question internally here, and I'm told in return that people believe the cost incurred by switching to end-of-DATA filtering vs. connect-time filtering is a lot larger than I believe.  And they [claim to] have the data to support that position from large customers, so for now I'm not arguing it.

I assume you're talking about IP address based reputation which can be done once the incoming connect is completed.
I've heard the same thing, but I'm always a little bit dubious about "can't be done" kinds proclamations. They
almost always forget to take into account Moore's Law and clever workarounds. Luckily, IP address base filtering
isn't a zero sum game with DKIM so the argument is largely academic.

>> no clue whether it's destined for a MLM or anything else.
>
> Those points might well encourage future MLMs to be implemented with much tighter MTA integration, but if so, we can be sure there will always be the legacy stuff hanging around as drag.

Yes, that's exactly what I was thinking -- there's a lot of legacy out there that either on auto-pilot, or has
no reason to change. Even though I don't think we should be let the MLM-tail wag the email dog, saying that we
think that layering violations are a Good Thing leaves a bad taste in my mouth.

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 13 Sep 2010 11:58:01 -0700

---

From: "McDowell, Brett" <[email-masked]>
Date: Mon, 13 Sep 2010 14:03:11 -0600

> take them at their word and discard it.

I disagree.  

The ADSP=discardable deployer is not conveying apathy regarding the deliverability of their mail, quite the opposite IMO.  They are saying (to paraphrase) "please attempt to verify the DKIM signature on this message against the key record in our DNS for this domain/subdomain, and if you cannot verify the signature then please discard the message as a means of protecting your subscriber from phishing attacks, otherwise please deliver the message and do so knowing we put this much effort into ensuring the goodness of the mail before we sent it".

-- Brett

---

From: Douglas Otis <[email-masked]>
Date: Mon, 13 Sep 2010 14:30:20 -0700

On 9/13/10 1:03 PM, McDowell, Brett wrote:
> The ADSP=discardable deployer is not conveying apathy regarding the deliverability of their mail, quite the opposite IMO.  They are saying (to paraphrase) "please attempt to verify the DKIM signature on this message against the key record in our DNS for this domain/subdomain, and if you cannot verify the signature then please discard the message as a means of protecting your subscriber from phishing attacks, otherwise please deliver the message and do so knowing we put this much effort into ensuring the goodness of the mail before we sent it"
For MLMs making modifications that invalidate DKIM signatures, posting 
should be blocked for domains making an ADSP dkim=discardable 
assertion.  Such an assertion might cause other subscribers to refuse 
messages from an Author Domain with the discardable assertion and cause 
delivery and message queuing to be problematic.  Otherwise, those 
refusing these messages run a risk of being unsubscribed.

-Doug

---

From: "J.D. Falk" <[email-masked]>
Date: Mon, 13 Sep 2010 15:14:27 -0700

> stuff out of our whatevers.

But if that stuff was signed before entering our whatevers, how can we verify the signature when pulling it out?  This question may entirely invalidate assumptions that nobody ever actually made about somebody else's theoretical wiping policy!

---

From: Hector Santos <[email-masked]>
Date: Mon, 13 Sep 2010 20:02:43 -0400

Murray S. Kucherawy wrote:
> Those points might well encourage future MLMs to be implemented with
> much tighter MTA integration, but if so, we can be sure there 
> will always be the legacy stuff hanging around as drag.

Exactly

The legacy system will be there. So you design around it. Its not 
really hard.  No stats is needed to understand that. All mail vendors 
had to deal with the legacy issue for a long time.

Fwiw, we have one of this "Future MLM" since 1996 designed around an 
integrated RPC client/server framework.  The MLM saves an centralized 
"list address acceptance" list file, including  subscribe/unsubscribe 
list addresses for the SMTP servers to use at the RCPT level.

---

From: "John R. Levine" <[email-masked]>
Date: 13 Sep 2010 20:43:57 -0400

> But if that stuff was signed before entering our whatevers, how can we 
> verify the signature when pulling it out?  This question may entirely 
> invalidate assumptions that nobody ever actually made about somebody 
> else's theoretical wiping policy!

Not to stretch this metaphor too far, but I believe that the assertion 
that people care whether mail inbound to MLMs was signed remains utterly 
unsupported.

Give the IETF's traditions, the usual way to show that you care about 
something is to write the code to do it.  For the lists I run, I've 
modified MJ2 to put a signature on outgoing mail with the list's domain 
and a private field to say which list it was.  I can't say I've seen any 
improvement in delivery which was already close to 100%, but it certainly 
hasn't hurt anything and it's made it easier to process Yahoo FBLs. 
That's one of the reasons I'd want a list BCP to tell lists to sign their 
mail; I've tried it, albeit at small scale, and it works.  We know from 
reports that at least one MTA misimplements ADSP to reject on discardable 
failures, which suggests that a robust MLM should be prepared to deal with 
that, most simply by pre-discarding anything that might cause that 
problem.  I haven't implemented that because, so far at least, none of my 
susbcribers appear to use ADSP so it's pretty low on my list of things to 
worry about.

Based on recent correspondence, it appears that one of the most vehement 
advocates of modifying MLMs to work around ADSP and to pass through info 
to retroactively check contributor signatures hadn't noticed that I put 
S/MIME signatures on my list mail and that even though it adds a footer to 
each message, Mailman passes the signatures through so his MUA can verify 
them.  Care?  Get real.

R's,
John

---

From: "John R. Levine" <[email-masked]>
Date: 13 Sep 2010 21:07:58 -0400

>> If they say their mail is discardable, take them at their word and 
>> discard it.

> I disagree.
>
> The ADSP=discardable deployer is not conveying apathy regarding the 
> deliverability of their mail, quite the opposite IMO.  They are saying 
> (to paraphrase) "please attempt to verify the DKIM signature on this message 
> against the key record in our DNS for this domain/subdomain, and if you 
> cannot verify the signature then please discard the message as a means 
> of protecting your subscriber from phishing attacks, otherwise please 
> deliver the message and do so knowing we put this much effort into 
> ensuring the goodness of the mail before we sent it".

This is a really good example of why ADSP will never be useful.  I believe 
that's what you mean when you set adsp=discardable, and what Paypal means, 
but it's not what I meant when I wrote the section about discardable and I 
don't think it's a fair reading of the RFC.  People want to read way more 
into it than is actually there.

Early drafts of what turned into ADSP used the word "strict" which I 
changed to "discardable" to make it clear that if you set this flag, 
you're saying the mail is unusually unimportant, to the extent that if
there's any doubt about its legitimacy, just throw it away.

---

From: "John R. Levine" <[email-masked]>
Date: 13 Sep 2010 21:18:41 -0400

[ aargh, Alpine has the classic Unix user interface: "if you didn't want
    me to delete all your files or, in this case, send your half written
    message, why did you push that button?" ]

>> If they say their mail is discardable, take them at their word and discard 
>> it.

> deliverability of their mail, quite the opposite IMO.  They are saying (to 
> paraphrase) "please attempt to verify the DKIM signature on this message 
> cannot verify the signature then please discard the message as a means of 
> protecting your subscriber from phishing attacks, otherwise please deliver 
> the message and do so knowing we put this much effort into ensuring the 
> goodness of the mail before we sent it".

This is a really good example of why ADSP isn't useful.  I believe that's 
what you mean when you set adsp=discardable, and what Paypal means, and 
what Paypal has said to networks with whom they've offered private advice 
on handling their mail, but it's not what I meant when I wrote the section 
about discardable and I don't think it's a fair reading of the RFC. 
People want to read way more into it than is actually there.

Early drafts of what turned into ADSP used the word "strict" which I 
changed to "discardable" to make it clear that if you set this flag, 
you're saying the mail is unusually unimportant, to the extent that if 
there's doubt about its legitimacy, just throw it away.

Even the early drafts said

   The entity does not expect to send messages through agents that may
   modify and re-sign messages.

The final version said

   if a message arrives without a valid Author Domain Signature due to
   modification in transit, submission via a path without access to a
   signing key, or any other reason, the domain encourages the recipient(s)
   to discard it.

I think it's a reasonable interpretation to say that if you expect your 
list software might break the signature, you're doing the sender a favor 
by pre-discarding it since that's what the recipients should do anyway.

R's,
John

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 14 Sep 2010 10:00:07 +0100

--On 13 September 2010 10:21:55 -0700 Michael Thomas <[email-masked]> wrote:

>  Unless you have a MLM that

I disagree. I use Mailman 2.x and Exim. Mailman has a rudimentary SMTP 
server, and Exim punts mail to that SMTP server in order to achieve 
delivery. Exim knows exactly which emails are being delivered to Mailman.

In Mailman 3, things will look even better. Exim will be able to make a 
call forward to Mailman to determine (a) whether the list exists, and (b) 
whether the sender is permitted to post messages to the list. Exim will 
know whether the message is signed, and can do simple DNS lookups to find 
ADSP records.

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 14 Sep 2010 10:36:25 +0100

> by pre-discarding it since that's what the recipients should do anyway.

Absolutely not. The condition doesn't apply when you receive the message, 
so the signer is NOT encouraging you to discard it, and the general rules 
apply: you should deliver the message or notify the sender (or the sending 
MTA).

It may be that the message can be bounced, with a non delivery 
notification. For example, if the return path matches the content of a 
signed header, and they're both in the domain of the signer, then you're 
probably not issuing collateral spam. If you are issuing collateral spam in 
this instance, then the fault probably lies with the controller of the 
sender domain (for allowing intra-domain spoofing).

If the MLM owner knowingly breaks a signature, and either discards the 
message or forwards it into a system that is likely to discard it, and do 
not notify the sender, then the forwarder must be responsible for any harm 
done. They really should reject such messages.

A real life exemplar: we're currently migrating a lot of non-modifying list 
exploders into modifying Mailman lists. Most of these lists are internal, 
but not all of them. In an ideal world, I'd check the domains of all 
subscribers to see whether any publish ADSP=discardable before making the 
changes. In practice, I suspect that I'm unlikely to do that. However, I'd 
much prefer that message get bounced back to the sender than discarded as a 
result of the change that I'm making. That way, they have a better chance 
to spot the problem, and a better chance to diagnose it.

There are all sorts of reasons for publishing ADSP=discarable, from "the 
domain isn't used to send email" (analagous to "spf -all"), to "our domain 
is widely spoofed (because of it's sensitive nature), and we absolutely do 
sign all our email". I'd suggest that it's not reasonable to discard the 
latter email when it carries a good signature.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 14 Sep 2010 05:15:12 -0700

On 9/14/10 2:36 AM, Ian Eiloart wrote:
> --On 13 September 2010 21:18:41 -0400 "John R. Levine"<[email-masked]>
> wrote:
>
>> >  The final version said
>> >
Agree.

-Doug

---

From: "John R. Levine" <[email-masked]>
Date: 14 Sep 2010 09:18:23 -0400

> domain isn't used to send email" (analagous to "spf -all")

Quite right, in which case I hope you'll agree that throwing mail away is 
exactly the right thing to do.

> to "our domain is widely spoofed (because of its sensitive nature), and 
> we absolutely do sign all our email".

That would be dkim=all, not dkim=discardable.

As I keep saying over and over, discardable really means discardable: if 
in doubt, throw it away.  It does NOT, repeat NOT, mean high value mail. 
It means low value mail.

R's,
John

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 14 Sep 2010 09:31:31 -0400

> Sent: Tuesday, September 14, 2010 9:18 AM
> To: Ian Eiloart
> Cc: DKIM

-1

It does not mean low value mail and I don't think you will find a
sending mplementing dkim=discardable that would agree with you. In the
case of the domain actually sending mail, what is being said is that the
risk of phishing/badness/abuse is great enough that when in doubt,
discard it if it fails to validate or does not have a signature. This is
significantly different than "it means low value mail".

Mike

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 14 Sep 2010 15:03:52 +0200

> there's doubt about its legitimacy, just throw it away.

At the time, "strict" was meant to be the equivalent of DK's "-", 
wasn't it?  IMHO, "discardable" has been an addition rather than a 
substitution.  Given that, and assuming that "discardable means 
discardable", as you wrote[1], is it correct to _reject_ on _all_?

[1] http://mipassoc.org/pipermail/ietf-dkim/2008q1/009557.html

> I think it's a reasonable interpretation to say that if you expect
> your list software might break the signature, you're doing the sender
> a favor by pre-discarding it since that's what the recipients should
> do anyway.

Hear, hear. Does such criterion also apply to, say, courtesy 
forwarding?  Consider the following test I made:

   Authentication-Results: ns1.qubic.net; dkim=pass (1024-bit key)
   	header.i=@tana.it header.b=CGKfNJdO; dkim-adsp=pass
   ...
   Subject: Test quoted printable
   X-Mime-Autoconverted: from 8bit to quoted-printable by courier 0.64
   Content-Transfer-Encoding: 8bit
   X-MIME-Autoconverted: from quoted-printable to 8bit by
     ns1.qubic.net id o7SAsR9R006644

The message was signed as quoted-printable, hence they 
(dk.elandsys.com) obviously had verified it /before/ converting back 
to 8bit.  Thereafter, they should not forward adsp-encumbered 
messages, unless wrapped inside entirely new messages, with their own 
"From" (as they actually do, for the autoresponder.)  Is that correct?
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Tue, 14 Sep 2010 09:48:48 -0400

> done. They really should reject such messages.

+1 and nothing short of this is just poor mail system integration and
product engineering.

The key word is "knowingly" because it is intentional neglect at that
point if it pursues to add something NEW without all the engineering
considerations extracted from the R&D.

Here is what we are doing:

For List Server:

    - Check ADSP at subscription points
         - notify denial

    - Check ADSP at list submission
         - reject with 1 time notification

    - One time scan script to check for any ADSP domains
         - dotting the i, crossing the t.

    Overall, ADSP domains are restricted and ASDP domains are
    protected from abuse.

For SMTP Server:

    - DATA level DKIM Script

      - Extract 5322.From

      - Check ADSP
        - if DISCARDABLE or ALL and not signed
          - if DISCARDABLE return ACCEPT-DISCARD
          - return REJECT
        - if DISCARDABLE
          - Extract DKIM.D
          - if 5322.From != DKIM.D
            - If Has List-ID, return ACCEPT-DISCARD
            - return REJECT

      - if signed
         - DKIM verify

      - A-R record
      - Return PASS

Overall, it has consideration for legacy list server. It will not
cover those who do not add a LIST-ID.

Check ADSP would also be made an option just in case it becomes
deprecated.

The ACCEPT-DISCARD will probably be made an option with a default of
true, otherwise it would be a REJECT.

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 14 Sep 2010 09:40:32 -0400

> in doubt, throw it away.  It does NOT, repeat NOT, mean high value mail. 

I think your view is to narrow.  It means that the domain owner prefers it be 
discarded if not signed.  This means they view the risks of having legitimate 
mail discarded as lower than the risks associated with having unsigned mail 
delivered.  This is a relative assessment.  Your "low value mail" assertion 
only addresses one part of that equation.

Scott K

---

From: "John R. Levine" <[email-masked]>
Date: 14 Sep 2010 10:31:51 -0400

> At the time, "strict" was meant to be the equivalent of DK's "-", wasn't it? 
> IMHO, "discardable" has been an addition rather than a substitution.

Hey, I wrote it, I know what I did.  I changed strict to discardable to 
better describe what it means, and try to discourage the wrong impression 
that it means mail is important.

> that, and assuming that "discardable means discardable", as you wrote[1], is 
> it correct to _reject_ on _all_?

We don't offer any suggested handling for dkim=all.  "Well, it might be a 
forgery, or it might have a signature broken in transit, or they might be 
mistaken and not really sign all their mail.  Your guess is as good as 
mine."

> Hear, hear. Does such criterion also apply to, say, courtesy forwarding?

If the courtesy forward recodes the message and breaks the signature, as 
your example does, I suppose so.

R's,
John

---

From: "John R. Levine" <[email-masked]>
Date: 14 Sep 2010 10:32:53 -0400

> sending mplementing dkim=discardable that would agree with you.

Then in the RFC we utterly failed to make it clear what dkim=discardable 
means.  Sigh.

Once again, we see that ADSP is so broken that even people who like it 
don't understand what it is for.

R's,
John

---

From: "McDowell, Brett" <[email-masked]>
Date: Tue, 14 Sep 2010 09:05:12 -0600

+1

---

From: "McDowell, Brett" <[email-masked]>
Date: Tue, 14 Sep 2010 09:05:58 -0600

> significantly different than "it means low value mail".

I agree with Mike's assessment.

---

From: "John R. Levine" <[email-masked]>
Date: 14 Sep 2010 11:13:55 -0400

> I agree with Mike's assessment.

I remain unable to reconcile "this is very important" and "throw it away" 
applied to the same message.

R's,
John

---

From: Jesse Thompson <[email-masked]>
Date: Tue, 14 Sep 2010 09:19:54 -0500

On 09/13/2010 07:43 PM, John R. Levine wrote:
> S/MIME signatures on my list mail and that even though it adds a footer
> to each message, Mailman passes the signatures through so his MUA can
> verify them.  Care?  Get real.

fwiw, this list appears to be breaking your signatures (as I expect it 
will do to my signature as well.)

I agree with your assertion that S/MIME is very MLM friendly.  Most of 
the lists I am on do not break my signatures (even lists that add 
footers and modify subjects,) and those that do can be easily configured 
to work nicely.  Kudos to the designers of S/MIME and MIME :-)

In fact, most of my frustration with DKIM is because I naively expect it 
to work like S/MIME.  This isn't the fault of DKIM.  My expectations are 
just unreasonable.

Jesse

---

From: "McDowell, Brett" <[email-masked]>
Date: Tue, 14 Sep 2010 09:19:54 -0600

> don't understand what it is for.

But John, you clearly never wanted ADSP to exist and you've made enough statements publicly about your motivation for becoming a co-author that it should come as no surprise if folks don't interpret your comments regarding ADSP  with the same deference one normally expects in response to comments coming from a co-author.  

I suspect your fellow authors didn't realize you'd use this label change of "discardable" as ammunition after-the-fact to lobby for ADSP's disuse.   Perhaps it's time to issue an update to ADSP which clarifies how the spec should be interpreted, by those who actually use it.

-- Brett

---

From: "McDowell, Brett" <[email-masked]>
Date: Tue, 14 Sep 2010 09:20:47 -0600

> applied to the same message.
Scott nailed it when he said:  This means they view the risks of having legitimate 
mail discarded as lower than the risks associated with having unsigned mail 
delivered.

---

From: "McDowell, Brett" <[email-masked]>
Date: Tue, 14 Sep 2010 09:00:23 -0600

> refusing these messages run a risk of being unsubscribed.

That would be an undesired outcome and therefore a "reject" by the MLM would be more appropriate (until we have a RFC in place and adopted that enables the "transient trust"/"chain of trust" notion I've been advocating for).  And yes, I'm going to write one but perhaps only after I work with more mailbox providers to implement the notion now.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 14 Sep 2010 08:35:52 -0700

> applied to the same message.

The problem here is that you shouldn't be mixing up human values of "importance"
or not, with the mechanical policy that "if something is unsigned, don't
deliver it". ADSP does the later, not the former. And if notions of "importance" were
accidentally brought into the language of the ADSP RFC, they should be removed
because it's neither needed, or enlightening in any way.

Mike

---

From: "McDowell, Brett" <[email-masked]>
Date: Tue, 14 Sep 2010 09:03:45 -0600

> that people care whether mail inbound to MLMs was signed remains utterly 

I support it, in the context of supporting the "transient trust" use case (aka the A-R approach).

> something is to write the code to do it.  

So if you don't write code for senders you aren't allowed to express an opinion about sender policy?  That's just silly.  We are all stakeholders in this ecosystem and we all have a right to our opinion and perspective, regardless of how we engage/influence the Internet Mail ecosystem.

> For the lists I run, I've 

You lost me.

> 
> R's,
> John
> <smime.p7s><ATT00001..txt>

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 14 Sep 2010 11:40:31 -0400

> Sent: Tuesday, September 14, 2010 11:14 AM
> To: McDowell, Brett
> Cc: DKIM

You are unable to reconcile those two because you are leaving out the
third part of the equation. That is:

"there is a high risk of abuse for this domain when a message is not
authenticated".

Mike

---

From: Hector Santos <[email-masked]>
Date: Tue, 14 Sep 2010 11:37:41 -0400

> Then in the RFC we utterly failed to make it clear what dkim=discardable 

You wrote it!

> Once again, we see that ADSP is so broken 

By design

> that even people who like it don't understand what it is for.

We don't like it. We liked SSP.  But SSP was taken from us and we 
ended up with a terrible intentionally design morph to stop policy 
with little to no regard to how it integrates with the rest of the 
world, namely list system.  You could only tell people to ignore it or 
move it to experimental.

No, POLICY isn't the problem - ADSP is!

Hey, you wrote it - FIX IT!

---

From: "McDowell, Brett" <[email-masked]>
Date: Tue, 14 Sep 2010 09:06:51 -0600

> mail discarded as lower than the risks associated with having unsigned mail 

Agreed.

---

From: Hector Santos <[email-masked]>
Date: Tue, 14 Sep 2010 11:54:57 -0400

> because it's neither needed, or enlightening in any way.

+1, well said Mike and its not the first time of course.

The deterministic properties that POLICY offered has been, for lack of 
a better word, "deemphasized" with the focus on allowing unrestricted 
resigners hence we are left with only a guessing game and/or need to 
get receivers to use a common reputation service, with an propensity 
to serve only certain high value domains to have a greater "meaning" 
over the general population of domains.

Low or high value, all domains have to be treated with a fundamental 
equal mechanical, deterministic process first before we can even deal 
with indeterminate conditions.

---

From: Hector Santos <[email-masked]>
Date: Tue, 14 Sep 2010 12:08:28 -0400

MH Michael Hammer (5304) wrote:

>> John R. Levine

>> I remain unable to reconcile "this is very important" and "throw 
>> it away" applied to the same message.

> "there is a high risk of abuse for this domain when a message is not

+1, which is important because for many systems, authenticated 
sessions skips many or all email security checks.  For our SMTP 
system, once authenticated, all SMTP level checks are skipped. It is 
the unsolicited unauthenticated sessions where security checks best 
applies.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 14 Sep 2010 09:52:21 -0700

> Sent: Tuesday, September 14, 2010 8:14 AM
> To: McDowell, Brett
> Cc: DKIM
> I remain unable to reconcile "this is very important" and "throw it
> away" applied to the same message.

I don't think ADSP "discardable" means simply "throw it away" because it leaves out the "ifs" that are supposed to be in front of it.  That simplified interpretation presupposes the message will pretty much always arrive signed but not verifiable, meaning you basically don't believe DKIM can be trusted to work.

How about: "It is important to us that this arrive at your inbox signed by us and unmodified.  You should not keep it if that is not the case."

...which is how I read the RFC.

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 14 Sep 2010 12:17:24 -0700

> ...which is how I read the RFC.

And what the proponents intended when we wrote it.

---

From: "John R. Levine" <[email-masked]>
Date: 14 Sep 2010 15:22:44 -0400

>> How about: "It is important to us that this arrive at your inbox signed by us and unmodified.  You should not keep it if that is not the case."

Well OK.  Now I'm hearing that it's the signature that's important, not 
the message.  No disagreement there.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 14 Sep 2010 12:27:06 -0700

> Sent: Tuesday, September 14, 2010 12:23 PM
> To: J.D. Falk
> Cc: DKIM List
> >> How about: "It is important to us that this arrive at your inbox
> signed by us and unmodified.  You should not keep it if that is not the
> case."
> 

Since the signature's success is predicated on [some part of] the body being immutable in transit, are those distinct?

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 14 Sep 2010 15:41:47 -0400

> [email-masked]] On Behalf Of Murray S. Kucherawy
> Sent: Tuesday, September 14, 2010 3:27 PM
> To: DKIM List
> Since the signature's success is predicated on [some part of] the body
> being immutable in transit, are those distinct?
> 
> 

If someone cares enough to implement DKIM discardable I would be
surprised if they weren't signing the entire message body. The message
(stream overall) is important in the sense that the domain is trying to
fend off abuse. That is a necessary precondition but not sufficient.

The signature is important because that is how the legitimate (in the
sense that it is signed by the domain and validates) is distinguished
from the potentially illegitimate. The corpus of legitimate but failed
to validate could be considered collateral damage if you will. It may be
a high price but it is perceived as less than the damage of letting the
illegitimate stuff through.

---

From: "John R. Levine" <[email-masked]>
Date: 14 Sep 2010 19:04:40 -0400

> So if you don't write code for senders you aren't allowed to express an 
> opinion about sender policy?

Anyone can express an opinion about anything, but there's a reason that 
the IETF has a tradition of favoring rough consensus and running code. 
(See RFC 4677, particularly sections 8 and 9.) The draft we're working on 
is a BCP, where C stands for Current.  A BCP describes what people have 
done and found to work, not paper designs.

If a proposal is a good idea, it really shouldn't be hard to persuade 
someone, somewhere, to implement it and try it out.  (That's the E for 
Engineering in IETF.)  For one thing, the net is complex enough that one 
is usually surprised at unexpected side effects and interactions.  For 
another, it puts at least a small minimum bar for people to demonstrate 
that they find something useful.

For all the claims that checking transitive trust is important, I have yet 
to see anyone who actually does it.  This very list puts a signed A-R 
header on messages, I presume because Dave wrote or borrowed the code to 
do so.  Is anyone checking that signed header and use it to manage their 
mail?  As far as I can tell, the answer is no.  (Doubtless I will hear 
very soon if I've overlooked something.)

Mailing lists have been around for decades, and the possibility of people 
forging submissions has been around just as long.  I've seen a variety of 
hacks in the MLM to help identify contributors and control what mail the 
MLM passes along, but I don't ever, in all those decades, recall anything 
to do it at the subscriber end.  If it were a problem, you'd think that 
someone, somewhere, would have tried to solve it before, however 
imperfectly.  Perhaps this is a hitherto unseen problem that needs 
solving, but Occam's razor says that if we consistently don't see 
something, the reason is because it's not there.

Having said all that, it remains perfectly reasonable to write up any of 
these hypothetical propsals as I-Ds and ask the group to publish them as 
Experimental RFCs, to provide a public spec for anyone interested in 
implementing them, something I'd support.  If it turns out people do 
implement them and find them useful, we can revisit them and consider them 
for standards track, as they're doing in EAI.

So start writing those I-Ds.  It's even kind of fun, writing down your 
ideas and trying to make them so clear that even someone like me won't
misunderstand them.

R's,
John

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 15 Sep 2010 12:13:22 +0100

> mailstreams then all I can say is "Darwin was right".

Darwin was indeed right. But an organism that is not fit to survive may  
struggle on for millions of years before it finally becomes extinct.

Agreed that domains that asserts discardable SHOULD should have separate  
non-discardable mailstreams more suited to MLMs. But what incentive do  
they have to make this change? So far just some "advice" in Murray's  
draft. Yes, eventually they will all do it right, but "eventually" can be  
an awful long time. In the meantime, MLMs will have to cope.

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 15 Sep 2010 12:06:03 +0100

> proposal, could you remind us why, exactly, you're not writing it?

Because Murray indiacted it would be better included in his draft.
> Writing I-Ds isn't hard.  Lots of us do it all the time.

OK, I now have an ID in the pipeline. It will take the form of an addendum
to Murrays draft.

---

From: Hector Santos <[email-masked]>
Date: Wed, 15 Sep 2010 07:45:45 -0400

> an awful long time. In the meantime, MLMs will have to cope.

Darwin's main point is that in chaos there is an infinity towards 
equilibrium through adaptation. Its not just about the fittest but who 
can capacity to adapt to their environment.

The WG dearth is that we have dampers that restricts adaptation to 
occur towards equilibrium.

Things do not have to be negative. We just need to adjust the 
specifications. IMV, problem solving is considering is what is more 
feasible to change vs what to add. I don't think adding is helping.

For example, adding a proposal to 5322.From, in my view is a show 
stopper. It is too drastic and it is only considered because of other 
existing problems.

So look at the existing problems and see how they can be fixed so you 
don't need to change the 5322.From.

Implementation adaptation has already occurred with a major MTA vendor 
DKIM API library:

Adaptation #1: Option to ignore the RFC 4871 5322.From binding
                requirement.

Adaptation #2: interpretation the ADSP=ALL policy as an always
                sign by author domain or (any) 3rd party domain.

These adaptations by the major MTA vendor DKIM API is exactly what we 
are looking for. They learned what needs to be done to better 
implement DKIM and ADSP support. I believe they resolve most of the 
issues we been talking about regarding MLMs.

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 15 Sep 2010 12:24:40 +0100

>    signing key, or any other reason, the domain encourages the  

Indeed. If an unsigned/invalid message arrives at the MLM, he should  
discard it. But the case we are considering is where a perfectly validly  
signed message arrives at the MLM, and then the presumption is that the  
sender (or the owners of his domain) intend that it should be delivered.
> by pre-discarding it since that's what the recipients should do anyway.

No, it appears that the MLM has two choices in this situation:

1. Reject of bounce it, with a message of the form "Sorry! We were unable  
to forward this message to our list for reason XXXX".

2. Use his best endeavours to ensure that it gets delivered.

And one of the tools in his "best endeavours" armoury is to change the  
From: line.

---

From: Hector Santos <[email-masked]>
Date: Wed, 15 Sep 2010 08:24:26 -0400

> And one of the tools in his "best endeavours" armoury is to change the  

But for what purpose? To fix the ADSP problem?  Wouldn't it be better 
to fix the ADSP problem?

One problem I see with your proposal is the reply process may have a 
bad email address for 3rd party signers who are not using an email 
domain for DKIM.d.

For example:

   From: "Charles Lindsey" <[email-masked]>
   DKIM-Signature: d=mach1.signer.com

What you are proposing is that the distribution will be something like 
this:

   From: "Charles Lindsey" <[email-masked]>
   DKIM-Signature: d=mach1.signer.com

Is there a requirement the dkim.d domain must be a valid email address 
domain? Yes for 1st party, but what about the third party?

If this is for the purpose of hiding original ADSP restrictions to 
help push mail to list members, wouldn't this be creating a security 
loophole?

---

From: Ian Eiloart <[email-masked]>
Date: Wed, 15 Sep 2010 15:54:34 +0100

> don't understand what it is for.

So, when would email be so valuable that it needs signing, but of such low 
value that it doesn't need delivering? Answer, when they're two different 
emails (one spoofed).

We're not talking about email with broken signatures, we're talking about 
email with good signatures that are about to become broken.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 15 Sep 2010 09:43:11 -0700

> [email-masked]] On Behalf Of Charles Lindsey
> Sent: Wednesday, September 15, 2010 4:06 AM
> To: DKIM

...if there's WG consensus to put it there.

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 15 Sep 2010 20:47:58 +0200

On 15/Sep/10 01:04, John R. Levine wrote:
> For all the claims that checking transitive trust is important [...]
>
> Having said all that, it remains perfectly reasonable to write up any
> of these hypothetical propsals as I-Ds and ask the group to publish
> them as Experimental RFCs, to provide a public spec for anyone
> interested in implementing them, something I'd support. If it turns
> out people do implement them and find them useful, we can revisit them
> and consider them for standards track, as they're doing in EAI.
>

Ok, done.  Will you then say what you think about it?

Filename:	 draft-vesely-dkim-joint-sigs
Revision:	 00
Title:		 DKIM Joint Signatures
Creation_date:	 2010-09-15
WG ID:		 Independent Submission
Number_of_pages: 5

Abstract:
DKIM Joint Signatures provides a means to limit the responsibility of
a message that implied by signing it, and possibly transfer the
responsibility to a third party.

http://www.ietf.org/id/draft-vesely-dkim-joint-sigs-00.txt
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: SM <[email-masked]>
Date: Wed, 15 Sep 2010 12:54:21 -0700

Hi Murray,
At 09:52 14-09-10, Murray S. Kucherawy wrote:
>signed by us and unmodified.  You should not keep it if that is not the case."
>

 From Section 4.2.1 of RFC 5617:

   "All mail from the domain is signed with an
    Author Domain Signature.  Furthermore, if a
    message arrives without a valid Author Domain
    Signature due to modification in transit,
    submission via a path without access to a
    signing key, or any other reason, the domain
    encourages the recipient(s) to discard it."

As a receiver, I read this as the sender encouraging me to discard 
the message if it is not DKIM verified.  From previous discussions on 
this mailing list, it seems that the arguement was about reducing the 
amount of bounces.

Regards,
-sm

---

From: Hector Santos <[email-masked]>
Date: Wed, 15 Sep 2010 19:31:23 -0400

> http://www.ietf.org/id/draft-vesely-dkim-joint-sigs-00.txt

The I-D lacks examples to better understand this proposal.

I see these generic possibilities:

First party Example:

    From: [email-masked]
    DKIM-Required: example.com
    DKIM-Signature:  d=example.com h="From:DKIM-Required"

Third party Example:

    From: [email-masked]
    DKIM-Required: thirdparty.com
    DKIM-Signature: d=thirdparty.com h="From:DKIM-Required"

Is this proposal a method to expose the thirdparty.com as an 
"authorized" signer?

I am not clear with the rational in the verifier procedure itemized in 
section 3 "The DKIM-Required Field."

---

From: Hector Santos <[email-masked]>
Date: Wed, 15 Sep 2010 20:13:23 -0400

> this mailing list, it seems that the arguement was about reducing the 

Small nit:  "as the AUTHOR DOMAIN encouraging me to discard ....."

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 16 Sep 2010 07:32:28 +0200

>      DKIM-Signature:  d=example.com h="From:DKIM-Required"

Yes, that's possible, but seems useless.  What I've been thinking about is

        From: [email-masked]
        DKIM-Required: list.example
        DKIM-Signature: d=example.com h="From:DKIM-Required"

If it were agreed that a signature may be not valid unless 
countersigned by the recipient, the risk of replay attacks would be 
greatly diminished.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Thu, 16 Sep 2010 03:37:53 -0400

> countersigned by the recipient, the risk of replay attacks would be 

So in the above, the originating message author is telling the world 
that the domain list.example is expected to resign?  so it ends up 
like this?

     From: [email-masked]
     DKIM-Required: list.example
     X-DKIM-Signature: d=example.com h="From:DKIM-Required"
     DKIM-Signature: d=list.example.com h="From:DKIM-Required"

X-DKIM-Signature means that it was stripped and/or nullified in the
in distribution. Illustrated above to show there was a change.

Am I reading your proposal correct here?

---

From: Ian Eiloart <[email-masked]>
Date: Thu, 16 Sep 2010 11:19:34 +0100

> Am I reading your proposal correct here?

I don't think so. The original signature should only sign the DKIM-required 
and From headers, and perhaps enough other headers to reduce utility of 
replay attacks. Importantly, they should only sign parts that are likely to 
be unbroken by the MLM, thus satisfying ADSP requirements. However, the 
recipient knows that a valid signature from the MLM is required, too. Thus, 
the original DKIM signature is only valid for messages going through the 
list - off list replay isn't possible. On-list replay can be limited by 
ALSO including a full DKIM signature, for the list to check before 
redistributing.

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Thu, 16 Sep 2010 07:05:34 -0400

> [email-masked]] On Behalf Of Ian Eiloart
> Sent: Thursday, September 16, 2010 6:20 AM
> To: Hector Santos; [email-masked]
> Subject: Re: [ietf-dkim] draft-vesely-dkim-joint-sigs
> 

<SNIP>

> replay attacks. Importantly, they should only sign parts that are
likely
> to

Ian, this makes no sense to me. If a signing domain is concerned enough
to choose to implement ADSP, why would they reduce what they are signing
to accommodate a small percentage of their mail going to MLMs that they
may or may not be able to identify? I don't remove the locks on my doors
because there is a possibility that someone might break one of my
windows.

I've said it before and I'll say it again. MLMs are the tail, not the
dog. Don't wag the dog.

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 16 Sep 2010 09:49:40 -0700

> Sent: Thursday, September 16, 2010 3:20 AM
> likely to

I'm worried about that third sentence.  If people are encouraged not to sign Subject:, for example, which is a popular display header field, one could spamify that field and re-send the message.

If you subscribe to the idea that a DKIM signature reflects a domain taking some responsibility for a message, I'd have a hard time not signing Subject: (or From:) for any reason.

---

From: Hector Santos <[email-masked]>
Date: Thu, 16 Sep 2010 13:24:55 -0400

Murray S. Kucherawy wrote:

> I'm worried about that third sentence.  If people are encouraged not 
> to sign Subject:, for example, which is a popular display header field, 
> one could spamify that field and re-send the message.
> 
> If you subscribe to the idea that a DKIM signature reflects a 
> domain taking some responsibility for a message, I'd have a hard 
> time not signing Subject: (or From:) for any reason.

+1,  but nonetheless, it isn't a required header to be hash bound to 
the signature so there isn't much we can do about that but preach it 
and in software, make it a default header among the list of headers to 
be signed.

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 16 Sep 2010 20:03:30 +0200

On 16/Sep/10 18:49, Murray S. Kucherawy wrote:
> From: [email-masked] On Behalf Of Ian Eiloart
>
>> I don't think so. The original signature should only sign the
>> DKIM- required and From headers, and perhaps enough other headers
>> to reduce utility of replay attacks. Importantly, they should
>> only sign parts that are likely to be unbroken by the MLM, thus
>> satisfying ADSP requirements. However, the recipient knows that a
>> valid signature from the MLM is required, too. Thus, the original
>> DKIM signature is only valid for messages going through the list
>> - off list replay isn't possible. On-list replay can be limited
>> by ALSO including a full DKIM signature, for the list to check
>> before redistributing.
>
> I'm worried about that third sentence.  If people are encouraged
> not to sign Subject:, for example, which is a popular display
> header field, one could spamify that field and re-send the
> message.

Yes, suppose I usually sign everything, except when the only recipient 
is [email-masked]: in this case I only sign From: and Date:. 
One cannot replay a modified version of the message, because of the 
2nd party joint signature.  Thus one has to remove mipassoc.org's 
signature, and then she can compose any message, constrained only by 
the original From: and Date:.  A third signed field,

   DKIM-Required: mipassoc.org

is meant to avoid exactly that.

> time not signing Subject: (or From:) for any reason.

Why?  DKIM seeks to forbid modifications in order to avoid replaying.

> I've said it before and I'll say it again. MLMs are the tail, not the

Messages can also be replayed as-is, for the sole purpose to game the 
author domain's reputation.  DKIM can sign To: and Cc:, but not Bcc:, 
and then these are not tied to the actual recipients list.  This 
wagging is about delimiting message streams, hence it's not 
necessarily tied to MLMs only.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 17 Sep 2010 11:46:43 +0100

> OK, I now have an ID in the pipeline. It will take the form of an  

See draft-lindsey-dkim-mailinglists-00

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 17 Sep 2010 14:26:42 +0100

> But for what purpose? To fix the ADSP problem?  Wouldn't it be better

Of course it would. But I do not believe that will happen, or at least  
there will be sufficient sites that have not fixed it to be a significant  
nuisance.

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 17 Sep 2010 15:51:49 +0100

--On 16 September 2010 09:49:40 -0700 "Murray S. Kucherawy" 
<[email-masked]> wrote:

> I'm worried about that third sentence.  If people are encouraged not to
> sign Subject:, for example, which is a popular display header field, one
> could spamify that field and re-send the message.
>
> If you subscribe to the idea that a DKIM signature reflects a domain
> taking some responsibility for a message, I'd have a hard time not
> signing Subject: (or From:) for any reason.
>

I guess for this to work, the MLM admin needs to be looking for a good full 
signature. Lists that don't rewrite the subject are going to work better 
here, but more serious is the lack of signature for the body. Still, the 
attack that you describe is fairly esoteric, and targetted specifically to 
the list (remember, the sender can add a list-id header, and sign that!) It 
may be too expensive to be profitable.

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 17 Sep 2010 18:22:28 +0200

On 17/Sep/10 16:51, Ian Eiloart wrote:
> --On 16 September 2010 09:49:40 -0700 "Murray S. Kucherawy" <[email-masked]>  wrote:
>>  I'm worried about [partial signatures].  If people are encouraged not to

Ah, it wasn't clear to me that Murray meant re-sending the message 
/through the list/.  Yes, in that case the MLM cannot use the first 
signature to authenticate the author, unless an additional datum is 
also signed.  For example, if the first signature also covers Date or 
Message-ID, forgeries would be quite apparent.

Hey, how come message streams have no sequence numbers?
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "John R. Levine" <[email-masked]>
Date: 17 Sep 2010 13:08:45 -0400

> See draft-lindsey-dkim-mailinglists-00

Not a bad start.  But it really needs a Security section, summarizing all 
of the issues people have pointed out.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
Please consider the environment before sending e-mail.

---

From: "J.D. Falk" <[email-masked]>
Date: Fri, 17 Sep 2010 13:17:21 -0700

> necessarily tied to MLMs only.

If this is primarily a workaround for perceived limitations of reputation systems, then I humbly suggest that the premise is invalid.  Today's reputation systems aren't static; the operators are constantly changing them in reaction to what the spammers do.

If the spammers start replaying DKIM-signed messages in order to game reputation systems, the operators WILL adjust.  A scheme like this, rather than helping, may make those adjustments more complex and difficult.

Are there other use cases?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 17 Sep 2010 14:50:46 -0700

> Sent: Friday, September 17, 2010 1:17 PM
> To: DKIM List
> If this is primarily a workaround for perceived limitations of
> reputation systems, then I humbly suggest that the premise is invalid.
> Today's reputation systems aren't static; the operators are constantly
> changing them in reaction to what the spammers do.

I realize that the answer to this will be largely speculation, but: Will that continue to be true in the IPv6-based and domain-based future of reputation systems?

Having to make ongoing adjustments might be a hindrance to such systems.

---

From: "J.D. Falk" <[email-masked]>
Date: Fri, 17 Sep 2010 15:12:56 -0700

> Having to make ongoing adjustments might be a hindrance to such systems.

It's always a hinderance, sure, but there's nothing inherent to IPv4 which makes the adjustments necessary.

Adjustments to reputation systems are necessary because spammers keep changing tactics, attempting to get around the reputation systems.  And, patterns in legitimate mail change over time as well; it wasn't so long ago that Facebook notifications were getting caught by spam filters looking for similarity, which makes sense because they're all extremely similar -- and there's a lot of volume.

Any reputation system, or filter, or other anti-spam method which isn't reacting to changes will quickly become either ineffective at catching spam or ineffective at not catching non-spam, and people will stop using it, and pretty soon it'll be forgotten.

The same is true of other areas of security...the only constant is change.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 17 Sep 2010 16:43:58 -0700

On 9/17/10 3:12 PM, J.D. Falk wrote:
> >> reputation systems, then I humbly suggest that the premise is
> >> invalid. Today's reputation systems aren't static; the operators
> >> are constantly changing them in reaction to what the spammers
> >> do.
> >
> > I realize that the answer to this will be largely speculation,
> > but: Will that continue to be true in the IPv6-based and
> > domain-based future of reputation systems?
> >
>  It's always a hindrance, sure, but there's nothing inherent to IPv4
>  which makes the adjustments necessary.

The purpose of reputation is to curtail abusive source acceptance.  When 
reputation is based upon a DKIM domain, replay abuse must be ignored in 
reputation assessments when recipients are not contained within the 
signed content.  Such abuse must be controlled through other means.  
Please articulate what you see as an adjustment solving the fundamental 
replay issue haunting cryptographic techniques not bound to a specific 
source or destination?  Within an IPv6 environment, the concept of using 
the Return-Path or the PRA as ancillary requirements makes email more 
fragile, where expressing all IP address sources for a single domain is 
both not practical, and at times, not possible.

As a separate issue, the joint-sigs draft assumes the third-party 
service causing practice compliance problems are signing their messages 
using DKIM.  It also shares the difficulty related to the TPA-Label 
scheme in that the sender must anticipate signing domains used by a 
service expected to forward their message.  Unlike the TPA-Label scheme, 
joint-sigs lacks a means to delegate this effort to a different 
entity.   It seems doubtful safety is improved by suggesting Author 
Domains are thereby less accountable allowing a reduction of message 
elements being signed that are normally needed to prevent spoofing.

>  Adjustments to reputation systems are necessary because spammers
>  keep changing tactics, attempting to get around the reputation
>  systems. And, patterns in legitimate mail change over time as well;
>  it wasn't so long ago that Facebook notifications were getting caught
>  by spam filters looking for similarity, which makes sense because
>  they're all extremely similar -- and there's a lot of volume.

When DKIM is used to white-list domains, this then runs the risk of 
white-listed messages being replayed and directed to recipients not 
intended by the signing domain.

>  Any reputation system, or filter, or other anti-spam method which
>  isn't reacting to changes will quickly become either ineffective at
>  catching spam or ineffective at not catching non-spam, and people
>  will stop using it, and pretty soon it'll be forgotten.

Reputation based upon what?  DKIM lacks a means to deal with replay 
abuse, nor is DKIM related to servers introducing email into public 
email streams.  What are you suggesting will happen with DKIM reputation?

-Doug

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 18 Sep 2010 11:55:01 +0200

On 18/Sep/10 01:43, Douglas Otis wrote:
>>>> Today's reputation systems aren't static; the operators are
>>>> constantly changing them in reaction to what the spammers
>>>> do.
>> systems.
> When DKIM is used to white-list domains, this then runs the risk
> of white-listed messages being replayed and directed to recipients
> not intended by the signing domain.

Indeed, if replay attacks did not exist, there would be little reasons 
to be picky about message integrity.  We would sign just "From" and 
get away with it --as some domains do.

I wonder why the idea of binding messages' signatures to their 
destination domains hasn't been considered before.  As Ian pointed 
out, this would limit replay attacks to a single destination domain.

A different, though possibly related, idea is to use sequence numbers 
of some sort.  For example, coupled with monotonically increasing 
"Message-Id"s, signatures can identify message streams consistently. 
This would require stateful verifications, though.

Such wags should be interesting for DKIM as a whole, because they do 
limit replay attacks.  It is not coincidental that they sprout on 
tackling MLMs, given the paradox these pose to DKIM, which is well 
stated in RFC 4686:

  Many mailing lists, especially those that do not modify the content
  of the message and signed header fields and hence do not invalidate
  the signature, engage in a form of signed message replay.  The use of
  body length limits and other mechanisms to enhance the survivability
  of messages effectively enhances the ability to do so.  The only
  things that distinguish this case from undesirable forms of signed
  message replay is the intent of the replayer, which cannot be
  determined by the network.

-- 
I save reputation considerations for another list...
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "John R. Levine" <[email-masked]>
Date: 18 Sep 2010 14:15:26 -0400

> out, this would limit replay attacks to a single destination domain.

It's certainly come up before.

As I recall, the usual conclusion is that it breaks far more things than 
it solves, since forwarding is quite common, and abusive replay of 
legitimate messages is quite rare.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Sat, 18 Sep 2010 19:48:06 -0400

Doug,

Never mind the first or third party - we don't even have the support for

               "Always Expect Valid Signature"

So where is the payoff?  As long as verifiers don't support or enable 
policy in their software and are encouraged not to do so by the 
authors of the current policy draft standard, all these extra 
considerations  especially the more complex suggestions, is all for 
nothing.  I'm willing to explore TPA and my own DSAP, or the exacted 
ASL "lit version" idea for ADSP extension (which my current 
implementation supports), but it means nothing if we can't get the 
other authors and implementations to explore as well.

Only prior arrangement, special signer and receiver arrangements (a 
policy) seems to be of any value.

---

From: Hector Santos <[email-masked]>
Date: Sun, 19 Sep 2010 02:38:37 -0400

> out, this would limit replay attacks to a single destination domain.

One suggestion a few years back when I was doing DSAP was a "target" 
expectation scenario that might play a role under a SSRA (Special 
Signer/Receiver Arrangement) where the DKIM signer has a way to 
confirm the target address receiver is DKIM ready.

Related, I am considering of add subscriber page information regarding 
ADSP and DKIM. But without a doubt, with the next 24 hours or so, our 
List Server will be ADSP ready and will preempt any subscriber with a 
ADSP domain at the subscriber page and during a submission to the 
list.  It will explore an ADSP extension tag called ASL "Allowable 
Signer List" with the verifier already supports.  For example, for the 
ISDG.NET the ADSP record is:

       dkim=all; asl=googlegroups.com,mipassoc.org;

> This would require stateful verifications, though.

I seem to recall a small discussion regarding recording the b= hash or 
the entire DKIM-Signature for tracking/tracking and/or for dupe 
checking.  But many already do this with message-id and if you binding 
the message-id, then that serves the same purpose.

Honestly, all is these ideas are great - but it means nothing is we 
don't have a consistent following in verifiers - just imagine we don't 
have a sender policy that says "all mail is signed by anyone."  This 
would raise the bar to eliminate legacy domain spoofers/phishers that 
don't sign or are totally ignorant of DKIM.

Once a signature is valid, 1st or 3rd party, we always ends up back to 
a reputation or trust layer.

But we need to deal with the faults first.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 20 Sep 2010 21:36:25 +0100

> of the issues people have pointed out.

I am not aware of any scam that a phisher or other malefactor could  
perpetrate with my scheme that he could not equally well perpetrate  
without my scheme.

If someone can spot some new security issue that I have introduced, then  
yes, a security section would be needed.

---

From: Ian Eiloart <[email-masked]>
Date: Thu, 23 Sep 2010 16:19:41 +0100

--On 16 September 2010 07:05:34 -0400 "MH Michael Hammer (5304)" 
<[email-masked]> wrote:

> may or may not be able to identify?

I think they'd only do this for email that's to a mailing list, not for the 
whole stream. Hard to implement, and perhaps infeasible for large domains, 
but it's possible.

---

From: "John R. Levine" <[email-masked]>
Date: 23 Sep 2010 15:16:53 -0400

>> may or may not be able to identify?

I'm with you.  All of this emphasis on complex designs for MLMs strikes me 
as a waste of time, since it's a tiny corner of the mail space that has 
not historically been a vector for abuse, and shows no sign of becoming 
one.

That's why my advice is that lists should sign their mail, which is easy 
and at worst harmless, and we're done.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Thu, 23 Sep 2010 23:46:01 -0400

> and at worst harmless, and we're done.

-1.  As others as stated as well, it all depends on your mail 
integration into your ADMD.

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 24 Sep 2010 13:13:28 +0200

On 23/Sep/10 21:16, John R. Levine wrote:
> All of this emphasis on complex designs for MLMs strikes me as a waste
> of time, since it's a tiny corner of the mail space that has not
> historically been a vector for abuse, and shows no sign of becoming one.
>
> That's why my advice is that lists should sign their mail, which is
> easy and at worst harmless, and we're done.

According to Murray's definition, MLMs include ESPs and email 
marketers, which originate a volume of traffic and have historically 
been a vector for abuse.  Indeed, except for subscription mechanisms 
and deployed software, most of the problems are similar.

Notwithstanding the informative discussion about the relationship 
between SDID and AUID, author domain signatures have a meaning that is 
independent of any assessors that may or may not be installed at the 
verifier's.  A survived author domain signature is significant even if 
the author domain defines no ADSP record.

The notion of a sender's signature would be useful, as a replay 
limitation, whenever messages are not delivered directly.  Should we 
introduce that notion?  By comparison with SPF, it would certify each 
hop along a message path, not just the last one --provided that 
signatures don't break.  Besides courtesy forwarding and MLMs, this 
would also include outsourced backup MXes (an extinguishing species).

In http://www.opendkim.org/stats/report.html the "Correlation of 
Received: count to signature successes" shows an optimum at 3 hops. 
IMHO those failure rates are an indication that message modifications 
occur beyond what DKIM had anticipated.  I don't think a significant 
part of them are actual forgeries.  Do we content ourselves with a 
product that is not reliable?

Transferring messages responsibility (possibly removing broken 
signatures) and MIME-compliant canonicalizations (possibly providing 
for standardized modifications, like subject tags) are just two 
alternative, non mutually-exclusive strategies.  Should we devise more 
of them, and state what strategies seem more promising?

If you answer respectively "no, yes, no", I'm lost.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jeff Macdonald <[email-masked]>
Date: Fri, 24 Sep 2010 10:31:29 -0400

On Thu, Sep 23, 2010 at 3:16 PM, John R. Levine <[email-masked]> wrote:

> That's why my advice is that lists should sign their mail, which is easy and
> at worst harmless, and we're done.

+1

For those lists that provide Web based signup, I'd suggest an ADSP
check before accepting the registration. Heck, even a notification in
the confirmation message would help too.

And once a MLM has confirmed a subscription, it should be harmless to
bounce messages from domains that use ADSP.

-- 
Jeff Macdonald
Ayer, MA

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 24 Sep 2010 13:21:44 -0400

> and at worst harmless, and we're done.

In that case, we should just say we're done.  I see zero value in a document 
that says people should sign mail. 

Scott K

---

From: Michael Deutschmann <[email-masked]>
Date: Fri, 24 Sep 2010 15:46:33 -0700 (PDT)

> > historically been a vector for abuse, and shows no sign of becoming one.

It may be tiny, but users will not tolerate the total destruction of
mailing list traffic, which is the inevitable result of any ADSP use at
both ends which is sufficent to block actual forgeries (without using
whitelists).

> > easy and at worst harmless, and we're done.

It's easy but useless, since the MLM doesn't have the private key
needed to create a *relevant* signature.

Inventing an "LDSP" to allow lists to indicate that certain List-Id:s are
always associated with signatures would not be a total waste of time.  But
it cannot solve the "mailing list problem" alone, because the badguys
would do their mischief using "lists" with List-Id:s in domains they
control.  They'd have the private key, so their bad-mails would trivially
pass "LDSP".

The missing piece is a whitelist of List-Id:s to trust.  If each mailbox
has a custom whitelist covering only lists the user subscribed to, there
is a significant security-by-obscurity effect that means one is likely to
"get away" with trusting a list that is forgeable.  "LDSP" would make
things more reliable, but would never be the essential component.

---- Michael Deutschmann <[email-masked]>
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "John R. Levine" <[email-masked]>
Date: 24 Sep 2010 20:10:15 -0400

> both ends which is sufficent to block actual forgeries (without using

Good point.  So it's two things, lists should sign outgoing mail, and 
discard any incoming mail with dkim=discardable.

Since RFC 5617 says that discardable domains should not send mail to 
lists, nobody who can read should be affected by that.

> needed to create a *relevant* signature.

Hmmn.  I'm not sure what you're talking about here, but since neither DKIM 
nor ADSP say anything about "relevant" signatures, it can't be either of 
them.

R's,
John

---

From: Michael Deutschmann <[email-masked]>
Date: Fri, 24 Sep 2010 20:46:55 -0700 (PDT)

> lists, nobody who can read should be affected by that.

But that means DKIM/ADSP gets deployed so rarely at the sender side, that
it could just as well not exist.  And that still leaves the problem of
dkim=all.

> nor ADSP say anything about "relevant" signatures, it can't be either of

I meant "relevant to ADSP" -- that is, specifying a key in the domain of
the From: address.  Everything else is irrelevant to ADSP, although it is
explictly defined that such signatures are just ignored since they may
have meaning to other protocols layered on DKIM.

We can't just modify ADSP to allow all messages where *either* From: or
List-Id: have a matching signature, since that allows anyone to bypass
the intent of ADSP by creating a rogue list.

Combined with a whitelist of List-Id:s to accept in lieu of a valid From:
signature, "LDSP" would be quite secure.  But the whitelist is pretty
good on it's own.

An armor analogy:

 Whitelist of mailing lists to which one has actually subscribed
   = Chest Plate

 A hypothetical revised ADSP with "all" clarified and an "except-mlist"
   option.
   = Leggings and codpiece

 A hypothetical "LDSP"
   = Gauntlets and helmet

 ADSP as it stands
   = A magic impenetrable sleeping bag

 TPA
   = a full suit of cloth armour

You need the plate to protect against evil opt-out "mailinglists".  You
need the leggings to protect against ordinary forgeries.  And you in
theory need the gauntlets to stop forgeries of mailinglists you do trust
-- but in practice that attack is rare.

TPA gives good coverage, but most attacks -- those that pretend to be
from ultimate senders who didn't have the inclination to deploy the
thing, will go straight through.

The bag is guaranteed to keep you alive, but you'd be a fool to use it in
battle.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 24 Sep 2010 23:58:18 -0700

> both ends which is sufficent to block actual forgeries (without using
Agreed.  Most domains desire protection from blatant spoofing.  
Unfortunately, assertions requiring Author Domain signatures negatively 
affect deliverability.  Regardless how a signature might be damaged or 
missing, the ADSP dkim=all tpa-path allows rejection of any failure not 
recovered with a TPA Label.  TPA-Labels accommodate various verification 
methods from specific domains based upon DKIM signatures, or TLS, or 
SPF, or EHLO/addr to permit highly restrictive acceptance criteria, and 
even accommodate use of specific mailing-lists.  Making such 
accommodations could reduce use cousin or sub domains as a solution to 
protect transactional messages which then makes the phishing problem 
more intractable.

DKIM/ADSP being unable to make exceptions, prevents greater use of 
restrictive acceptance criteria designed to mitigate spoofing.  As a 
result, one of DKIM's strongest features can't be utilized by most 
domains.  Out of about 20 thousand financial domains being heavily 
phished, only 60 have found the only actionable ADSP assertion 
"discardable" appropriate, even though DKIM is significantly better at 
surviving email infrastructure than SPF.  The TPA-Label tool is able to 
recover from any number of problematic downstream services and this 
should offer significant survivability improvements.   Mailing lists 
sign their messages will simplify the recovery process.

Blocking all neutral sources is not practical, nor is reactive blocking 
effective against phishing. DKIM should be able to support proactive 
blocking based upon sender practices.  Recipients processing these 
practices will benefit with less email in an unknown state.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Sat, 25 Sep 2010 09:41:02 -0400

> practices will benefit with less email in an unknown state.

Hi Doug,

+1

And it works great with sender/domain policies.  Here is a A-R record 
examples
with the experimental ASL extension:

This was from a message posted to a list and how a beta tester member got:

  Authentication-Results: dkim.megabytecoffee.com;
    dkim=pass header.d=winserver.com;
    adsp=pass policy=all author.d=santronics.com asl.d=winserver.com;

MegabyteCoffee.com validated the winserver.com signature and also saw
this 3rd party signer was authorized by santronics.com with the domain
included in the asl= list.   In this my AMDM domains white list 
themselves.

Here is another interesting one just created with the SPF Mail Reports 
just posted. The mail bot was off since Nov 2009 and I just turned it 
on to see our signing and listbox.com signing.  This is what I got 
when listbox.com echoed back a list copy:

Authentication-Results: dkim.winserver.com;
   dkim=pass header.i=listbox.com header.d=listbox.com header.s=launch;
   adsp=fail policy=all author.d=winserver.com asl.d=listbox.com 
(unauthorized signer);
   dkim=fail (DKIM_BODY_HASH_MISMATCH) header.i=winserver.com 
header.d=winserver.com header.s=tms1;
   adsp=pass policy=all author.d=winserver.com asl.d=;
From: [email-masked]

As expected, reading the two pairs from the bottom, listbox.com 
destroyed my DKIM body hashing. ADSP passed although it should report 
fail since "there is no signature anymore" for winserver.com.

The resigning listbox.com was valid but the ADSP policy failed since 
it was not within the winserver.com ASL authorized list.

Adding it to the list will solve it but I will use a different domain 
for this mailing list. :)

In a way it seems that a greater granularity will help here for 
example a complex association:

       [email-masked] :: [email-masked]

as this is the only stream I will want this to exist for that address.

Is there a case where winserver.com could of signed with

       d=winserver.com; s=tms1; i=[email-masked];

Overall, I think, at best, I want to tell a TRUST/REPUTATION layer 
what is positively expected.  Not give it a negative.   It should not 
just add weight for just "listbox.com" but a specific association.

How can/will VBR help here?

Adding a VBR-INFO header doesn't seem to provide some assistance?

In layman terms, how can TPA help here?

Maybe, with ATPS, you can hash the entire [email-masked]?

   V:\wc5beta>makeatps
   (c) copyright 2010 Santronics Software, Inc.
   usage: MakeAPTS author-domain signer-domain [... signer-domain]

   V:\wc5beta>makeatps winserver.com [email-masked]
   ;
   ; Zone Records for author-domain: winserver.com
   ;

   f95d718ce593c9062808eec0470edbdb._atps  TXT ("v=atps1; 
d=[email-masked];")

Hmmmm, does this make sense?  I kinda like this idea.

This would be the LDSP extension idea where the LIST-ID is used for 
the hash. BTW, listbox.com has this header:

   List-ID: <[email-masked]>

I thought the format would be (according to RFC 2919)

   List-ID: [description] <spf-discuss.listbox.com>

Comments?

---

From: Michael Deutschmann <[email-masked]>
Date: Sun, 26 Sep 2010 06:55:04 -0700 (PDT)

> discard any incoming mail with dkim=discardable.

One thought - If lists are going to spend any time paying special
attention to DKIM, it would be easier for them to just always rewrite the
headers like so:

From: Joe User <[email-masked]>
becomes
From: Joe User ([email-masked]) <x@invalid>

And thus avoid any problems no matter what the original sender's policy
is.

(Ok, it will silently break take-address-from-message features in the mail
client.  Adding a Cc: header listing the original From: address would
help with that.)

The fact that this would work brings up a separate flaw in DKIM that I
believe has been mentioned before.  There's not much of a solution to
it, though.

---

From: "John R. Levine" <[email-masked]>
Date: 26 Sep 2010 13:06:10 -0400

> attention to DKIM, it would be easier for them to just always rewrite the

No, of course not.  I've already adjusted my list software to put DKIM 
list signatures on outgoing mail.  It was no big deal.  I haven't done 
anything with ADSP because, to several decimal places, nobody uses ADSP.

What have you done on the lists you run?

R's,
John

---

From: Michael Deutschmann <[email-masked]>
Date: Sun, 26 Sep 2010 21:49:00 -0700 (PDT)

> anything with ADSP because, to several decimal places, nobody uses ADSP.

I was suggesting the From: hackery as a substitute for preemptively
blocking ADSP-using posters, not as a substitute for adding a List-Id:
signature.

Although without an "LDSP", List-Id: signing is almost pointless.  To
benefit, you need to tell the recipient, human-to-human, that your list
always signs.  But if that communication channel is open, you could just
promise not to change the bounce-address domain, and protect that domain
with SPF.
 
> What have you done on the lists you run?

I don't run any lists.

One other important thing:  While preemptively blocking
"dkim=discardable" is reasonable, to definitively avoid DKIM false
positives you must also restrict "dkim=all" posters.

A reasonable interpretation of the RFC is that "dkim=all" still indicates
that all mail with no signature is bogus -- the difference from
"discardable" is that the latter indicates the sender is willing to accept
that suspect mail may be silently blackholed (thus making diagnosis of an
FP-causing configuration error harder).  So an MX capable of validating
before responding to CR LF '.' CR LF may treat them identically.

---

From: "John R. Levine" <[email-masked]>
Date: 27 Sep 2010 01:45:02 -0400

> that all mail with no signature is bogus

No.  If that's what we meant, that's what we would have said.

R's,
John

---

From: Michael Deutschmann <[email-masked]>
Date: Mon, 27 Sep 2010 03:01:38 -0700 (PDT)

> No.  If that's what we meant, that's what we would have said.

I base that on section B.1, which specifically mentions mailing lists as
a possible contraindication to "dkim=all" use.

And, last year (2009-10-10), you said:
> People who contribute to mailing lists shouldn't say dkim=all.  We
> argued this ad nauseam when we were hammering out ADSP, it shouldn't
> come as a surprise to anyone.

(which is what lead me to propose except-mlist in the first place.)

So if "dkim=all" is:

* not suitable for senders who are as confident in their signing as
"dkim=discardable" users, but do not approve of discarding mail without a
bounce.

* not suitable for people who sign all first-party mail but post to
legacy mailing lists.

... then what the heck is it good for?

---

From: Ian Eiloart <[email-masked]>
Date: Mon, 27 Sep 2010 10:35:09 +0100

> discard any incoming mail with dkim=discardable.

No, they should reject the email at SMTP time. The email is NOT discardable 
when it arrives at the MLM. Rejection at SMTP time does no harm, and gives 
the sender an opportunity to fix the problem.

---

From: "John R. Levine" <[email-masked]>
Date: 27 Sep 2010 11:07:41 -0400

> the sender an opportunity to fix the problem.

OK, so during the SMTP session, more particularly during the interval 
between receiving the dot at the end of data and returning a status code, 
my SMTP daemon needs to:

* identify recipient addresses that are mailing lists

* look for DKIM signatures in the message header

* find the From: address

* if there's a signature with a d= that matches the From: address, do the 
calculations to generate the DKIM hash, fetch the key record from the DNS, 
and see if it's good

* if there's not a good author signature, fetch the ADSP record and see 
what it says

* if it says discardable, return 5xx

* otherwise return 2xx

That seems an awful lot of work to do with the connection open to deal 
with what is unlikely to be more than a rare misconfiguration.  When you 
made these changes to your MTA, how much work was it?  How much effect did 
it have on overall MTA performance?  If you haven't implemented them, why 
not?

And since this group seems to be obsessed with arcane corner cases, what 
do you do with a discardable message if it's sent to two addresses, one of 
which is a mailing list and one of which isn't?

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Mon, 27 Sep 2010 08:27:11 -0700

Ignorance is bliss, I guess, especially when it comes to pontificates.
That's what every implementation of DKIM for MTA's, both open source and
commercial that I'm aware of does, though some do and don't do the ADSP
lookup. News at 11: email is still delivered, with little to no observable
impact.

You're a big fan of telling people that running code is your friend.
gunzip opendkim and see for yourself.

Mike, next we'll hear that DNSBL lookups can't be done during SMTP time
       either I guess

On 09/27/2010 08:07 AM, John R. Levine wrote:
> between receiving the dot at the end of data and returning a status
> code, my SMTP daemon needs to:
>
> * if there's a signature with a d= that matches the From: address, do
> the calculations to generate the DKIM hash, fetch the key record from
> the DNS, and see if it's good
>
> made these changes to your MTA, how much work was it? How much effect
> did it have on overall MTA performance? If you haven't implemented them,
> why not?
>
> do you do with a discardable message if it's sent to two addresses, one
> of which is a mailing list and one of which isn't?
>
> R's,
> John
>
>
>

---

From: "John R. Levine" <[email-masked]>
Date: 27 Sep 2010 13:38:12 -0400

> lookup. News at 11: email is still delivered, with little to no observable

It is not my impression that they all do the full DKIM validation while 
the SMTP session is open.  Mine doesn't.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Mon, 27 Sep 2010 10:58:14 -0700

> the SMTP session is open. Mine doesn't.

You would be completely wrong in your impression.

Source is your friend.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 27 Sep 2010 11:05:04 -0700

> You would be completely wrong in your impression.

Oh, I see John weaseled from "nobody does that" to the unprovable
"not everybody does that". In any case, John is completely wrong
with his assertion that doing DKIM/ADSP validation at SMTP time
is somehow even vaguely untenable. It isn't. It's common as dirt.

Mike

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 27 Sep 2010 19:26:37 +0200

On 27/Sep/10 17:07, John R. Levine wrote:
>> No, they should reject the email at SMTP time. The email is NOT
>> discardable when it arrives at the MLM. Rejection at SMTP time does
>> no harm, and gives the sender an opportunity to fix the problem.

+1 for the idea, but...

> * identify recipient addresses that are mailing lists

... that's not quite feasible, since your MLM doesn't have to tell 
your MTA what of a particular kind of user it is.  So let's say at 
SMTP time the MTA accepts the message, possibly flagging it with 
dkim-adsp=pass in the A-R field.

Now the MLM does its editing job.  It knows the original message was 
signed, so it makes sense to verify if the signature is still good 
after any changes have been applied.  In case verification fails, it 
shouldn't try to distribute an adsp-breaking message, so it can either 
send back a bounce or drop it.

Going for the bounce is not a bad design decision, because after all 
these are signed messages from verified subscribers.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Al Iverson <[email-masked]>
Date: Mon, 27 Sep 2010 13:17:50 -0500

> is somehow even vaguely untenable. It isn't. It's common as dirt.

It's hard to imagine a large, DKIM-checking mail provider, like, say,
Yahoo, doing that mid-transaction.

Do you have any data/insight on how to quantify "common as dirt"? I'm
doubtful of your claim without it.

Cheers,
Al Iverson

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 27 Sep 2010 11:04:27 -0700

> Sent: Monday, September 27, 2010 10:38 AM
> To: Michael Thomas
> Cc: DKIM List
> Subject: Re: [ietf-dkim] Corner cases and loose ends, was , draft-
> vesely-dkim-joint-sigs
> 

The milter-based ones like OpenDKIM and dkim-milter do.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 27 Sep 2010 11:34:20 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Al Iverson
> Sent: Monday, September 27, 2010 11:18 AM
> To: DKIM List
> Subject: Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs
> 

I think the options being discussed are:

a) Accept the whole message and then take DKIM validation and filtering action after returning 250 to DATA; or

b) Return a 5xx to DATA after doing DKIM validation when being strict about DKIM or ADSP.

I don't think anyone is suggesting to break the SMTP sequence.

> doubtful of your claim without it.

Both implementations exist.  In fact, OpenDKIM can be set to operate in either mode listed above.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 27 Sep 2010 11:38:54 -0700

On 09/27/2010 11:17 AM, Al Iverson wrote:
> On Mon, Sep 27, 2010 at 1:05 PM, Michael Thomas<[email-masked]>  wrote:

Yes, I have a lot of insight. My implementation did it that way, which
along with Murray's (and any other that's based off of milters), do it
that way. I don't have access to Y!'s source to say for sure, but my
impression from Mark and Miles is that they did it in-session and that
all of our experiences were the same: it added very little overhead.

I don't know why this should surprise anybody. Doing DNS lookups in-session
*is* common as dirt for RBL lookups, even if the big boys have the RBL
databases in-house for performance. So the only other issue with DKIM is
the actual computational overhead, and Eric did some calculations that it
was *maybe* 5% overhead, and that was 5 years ago -- Moore's Law only
helps.

So by all means, doubt away. Is there anybody else who was at the Interop
who *doesn't* do DKIM in-session? It was my impression that everybody did
it that way.

Mike

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 27 Sep 2010 11:39:43 -0700

...
> The milter-based ones like OpenDKIM and dkim-milter do.

It's been a significant revelation, for me, to realize how common it is for DKIM 
processing to occur during the SMTP session.

So SMTP issues reduce to finding ways of preventing the cross-net transfer of 
data or even of preventing the SMTP session.  Oddly, I think the latter is more 
feasible than the former.

-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Mon, 27 Sep 2010 14:39:47 -0400

> is somehow even vaguely untenable. It isn't. It's common as dirt.

By the way mike, this is how we see your mail into this list:

Authentication-Results: dkim.winserver.com;
    dkim=pass header.i=mipassoc.org header.d=mipassoc.org header.s=k00001;
    adsp=fail policy=all author.d=mtcc.com;

add a asl=mipassoc.org; tag to your ADSP record:

    dkim=all; asl=mipassoc.org;

and/or to support ATPS:

    dkim=all; atps=y; asl=mipassoc.org;

with a TXT record:

;
; Zone Records for author-domain: mtcc.com
;

206ef86e0a7e3805c54556eff0426484._atps  TXT ("v=atps1; d=mipassoc.org;")

The hash is an MD5 hash of mipassoc.org.

You can verify it at:

    [email-masked]

I expect this week to be very busy solidifying the ASL/ATPS logic and 
writing the I-D for it.

---

From: Hector Santos <[email-masked]>
Date: Mon, 27 Sep 2010 14:07:56 -0400

> the SMTP session is open.  Mine doesn't.

Our DKIM implementation does plus ADSP Extensions (ASL and ATPS 
combined) enabled are processed during the SMTP session.

I am going to do something soon:

    Turn off USER VALIDATE at RCPT TO

where we normally see 63-70% rejects for spoofs or near user names for 
our locally hosted domains.

Since we are enforcing DKIM domain signing with a strong signing 
policy, I expect for all of these to be policy based rejections.

The ASL and ATPS extensions is working out great so far.  I have this 
list whited via ASL.  I have other list and EPS via ATPS.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 27 Sep 2010 11:59:44 -0700

On 9/25/10 6:41 AM, Hector Santos wrote:

>  And it works great with sender/domain policies. Here is a A-R
>  record examples with the experimental ASL extension:
>
>  Authentication-Results: dkim.megabytecoffee.com; dkim=pass
>  header.d=winserver.com; adsp=pass policy=all author.d=santronics.com
>  asl.d=winserver.com;
>
>  MegabyteCoffee.com validated the winserver.com signature and also
>  saw this 3rd party signer was authorized by santronics.com with the
>  domain included in the asl= list. In this my AMDM domains white
>  list themselves.
>
>  Here is another interesting one just created with the SPF Mail
>  Reports just posted. The mail bot was off since Nov 2009 and I just
>  turned it on to see our signing and listbox.com signing. This is
>  what I got when listbox.com echoed back a list copy:
>
>  Authentication-Results: dkim.winserver.com; dkim=pass
>  header.i=listbox.com header.d=listbox.com header.s=launch; adsp=fail
>  policy=all author.d=winserver.com asl.d=listbox.com (unauthorized
>  signer); dkim=fail (DKIM_BODY_HASH_MISMATCH) header.i=winserver.com
>  header.d=winserver.com header.s=tms1; adsp=pass policy=all
>  author.d=winserver.com asl.d=; From: [email-masked]
>
>  destroyed my DKIM body hashing. ADSP passed although it should
>  report fail since "there is no signature anymore" for winserver.com.
>
>  Adding it to the list will solve it but I will use a different
>  domain for this mailing list. :)
>
>  what is positively expected. Not give it a negative. It should
>  not just add weight for just "listbox.com" but a specific
>  association.
>

It can't, especially against phishing.  This also leaves open the issue 
of Sender or List-ID header fields that might be needed to ensure proper 
message sorting of those from third-party services.  In addition, DKIM 
whitelisting reliance makes it an imperative to ensure against damaged 
signatures to retain delivery integrity.  The small percentage of DKIM 
mail that might otherwise fail can be recovered safely using the 
TPA-Label scheme.

>  In layman terms, how can TPA help here?

The TPA-Label scheme is similar to your ASL ADSP extension, however it 
scales to any desired size, and can stipulate what type of 
authentication is to be applied and whether additional header fields are 
required to be compliant with the authorization.

There would be a benefit in adopting your ASL list specifically for 
those wanting to use sub-domain signing when segregating mail streams, 
where scaling or header field compliance would be much less of an issue.

>  V:\wc5beta>makeatps (c) copyright 2010 Santronics Software, Inc.
>  V:\wc5beta>makeatps winserver.com [email-masked] ; ; Zone
>  Records for author-domain: winserver.com ;
>
>  List-ID:<[email-masked]>
>
>  List-ID: [description]<spf-discuss.listbox.com>
>
>  Comments?

The ATPS draft incorrectly assumes two things:

1) All desired third-party services use DKIM.

2) Additional header fields are not needed to ensure proper message 
sorting or recognition.

The TPA-Label scheme can include wildcard or separate domain 
descriptions to match against Sender or List-ID headers.  In other 
words, the Author Domain can allow the third-party signature and List-ID 
or Sender header fields to differ.

-Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 27 Sep 2010 12:10:30 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Douglas Otis
> Sent: Monday, September 27, 2010 12:00 PM
> Subject: Re: [ietf-dkim] Authorizing List Domains
> 

For the purposes of the experiment, that seems to be a reasonable assumption given the associated mechanisms.  It would however be trivial to decouple it from DKIM (or more specifically, ADSP).

> 2) Additional header fields are not needed to ensure proper message

I'm open to adding such extensions to the experiment if they're deemed necessary, but I don't want to pack the content of the record with a bunch of stuff until that's obvious.  Over-engineering these efforts up-front has been proven a very effective way of rendering them unusable.

---

From: "Mark Delany" <[email-masked]>
Date: 27 Sep 2010 12:57:23 -0700

> feasible than the former.

So is this a premature optimization discussion?

In terms of the big guys, it's a complex question as it depends on
what other processing occurs at SMTP time, such as AV and anti-spam
and *where* that processing occurs (on the SMTP socket machine or
somewhere else). Most big guys will have mail processing distributed
across multiple systems during the SMTP session.

All the big guys have an ideal location (or the only realistic
location in some cases) where they did/or-will install DKIM processing
and that will likely vary from player to player. The smart ones might
even do some processing in different places dynamically depending on
the current load of each piece of infrastructure.

Frankly I think that the decision of where a big player does
processing will be driven by their infrastructure and internal design
far more than any tweaks to a standard or set of recommendations we
might make. Even if we knew what they all did today, there is no
reason to expect that will remain unchanged for any substantial period
of time.

As an aside. Just looking at the simple metric of holding times of an
SMTP session, the biggest cost typically comes from slow clients
rather than the CPU latency of processing a DKIM signature or
anti-spam content analysis. Mail from remote ISPs in countries with
constricted connectivity can often trickle in at 1200bps-type speeds.

Mark.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 27 Sep 2010 14:41:32 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave CROCKER
> Sent: Monday, September 27, 2010 11:40 AM
> To: DKIM List

I think, as Mark points out, this is often an artifact of the constraints of the existing environment (in our case, the architecture of milter) rather than a decision that doing so during the SMTP session is obviously the right way to do it.

That said, there's a lot of agreement that filtering during SMTP is better than accept-and-then-deal-with-it approaches.  (cf. RFC5451, Appendix C)  Unfortunately post-DATA rejection is the only way that can be done, short of changes to SMTP in the way of yet another extension that wouldn't receive wide adoption in the short term anyway.

> feasible than the former.

This is probably one of the main reasons SPF remains in widespread use.  That no workable envelope-level DKIM equivalent has materialized to date is unfortunate.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 27 Sep 2010 15:01:31 -0700

On 9/27/10 12:10 PM, Murray S. Kucherawy wrote:
>> On Monday, September 27, 2010 12:00 PM, Douglas Otis wrote:
>>
You have placed TPA information in a domain not below 
"_domainkey.<signing-domain>".  This increases the response size by 11 
bytes with a trade-off of making delegations to signing mail providers 
more difficult.  I am open to either approach, however only DKIM makes 
this scheme practical.
> I'm open to adding such extensions to the experiment if they're deemed necessary, but I don't want to pack the content of the record with a bunch of stuff until that's obvious.  Over-engineering th…
Unless there is a recognized need, additional information should not be 
included.  At the same time, unless authorizations can defend against 
likely abuse, that too would render efforts unusable.  The additional 
information also benefits the recipient when it simplifies their process 
and increases the number of messages being properly marked for rejection.

-Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 27 Sep 2010 15:13:28 -0700

> Sent: Monday, September 27, 2010 3:02 PM

How does it make something more difficult?

> At the same time, unless authorizations can defend against
> information also benefits the recipient when it simplifies their
> process and increases the number of messages being properly marked for
> rejection.

I don't really want to conduct an experiment that includes myriad optional policy specifications without some operational data to suggest they stand a chance of adoption.  Simpler is better.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 27 Sep 2010 16:18:39 -0700

On 9/27/10 3:13 PM, Murray S. Kucherawy wrote:
>> On Monday, September 27, 2010 3:02 PM, Douglas Otis wrote:
>>
Two zones might need delegation instead of just one.
> I don't really want to conduct an experiment that includes myriad optional policy specifications without some operational data to suggest they stand a chance of adoption.  Simpler is better.
Agreed, but not having a defense against trivial exploitation of an 
authorization is not better.  When a defensive requirement proves 
unused, it can be removed without impact.  Since this information sets 
authorization requirements, adding the information at a later date would 
not be compatible with existing implementations.

Perhaps we can work on the bare essentials independent of the notation used.

Types of authentication that might be used for existing third-party 
services-

  1) DKIM
  2) TLS
  3) SPF
  4) EHLO/ADR

Additional header field requirements ensure message sorting or 
presentation.  The header field requirement is to offer simple tactics 
against most phishing exploits:

  a) Sender
  b) List-ID

One could describe the current ADSP scheme as being "simple".   Simple 
is not better when only ~200 out of 20,000 phished domains use the 
mechanism intended to mitigate the negative impact caused when users 
wonder about spoofed messages.  The result of wondering is they might 
decide to curtail future business with the domain, which likely has a 
greater impact than losses due to fraud.

The MLM recommendation of using different sub-domains ignores the fact 
that most recipients don't understand name changes on the right or the 
left of a recognizable name.  Name recognition is improved when a single 
name is always used.  The most visible name to recipients is the domain 
found in the From header, whether used as a basis for sorting, or when 
displayed in addition to that of the friendly name.

It is unfortunate, the From header field is not always emitted by 
servers controlled by the Author Domain.  The TPA-Label scheme seeks a 
means to retain a reasonable level of authentication compliance without 
mandating an often unobtainable requirement that messages only be 
emitted by Author Domains.  In many cases, transparent authorization 
techniques are simply not practical, nor will any neutral status offer 
the proactive protections needed to mitigate phishing.

-Doug

---

From: "John R. Levine" <[email-masked]>
Date: 27 Sep 2010 23:05:46 -0400

> That said, there's a lot of agreement that filtering during SMTP is better than accept-and-then-deal-with-it approaches.  (cf. RFC5451, Appendix C)  Unfortunately post-DATA rejection is the only wa…

I hadn't realized how many medium-sized MTAs do their DKIM during the 
SMTP session.  You learn something new every day.  It still sounds like a 
design that *requires* that an MTA do DKIM at SMTP time would present a 
problem for some mail systems too large to ignore.

For Ian, I'm still wondering if he's yet implemented a setup which knows 
at SMTP time what addresses deliver to mailing lists so it knows whether 
to reject or discard on ADSP failures.  Still seems like a lot of work for 
a largely nonexistent problem.

R's,
John

PS:

> That no workable envelope-level DKIM equivalent has materialized to date 
> is unfortunate.

Not for lack of trying, but I just don't see how you could prevent bad 
guys from replaying good envelopes on bad mail.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 27 Sep 2010 21:38:00 -0700

> From: John R. Levine [mailto:[email-masked]]
> Sent: Monday, September 27, 2010 8:06 PM
> To: Murray S. Kucherawy
> Cc: DKIM List

Yeah.  Short-lived keys is the best thing I can come up with.

Do you think it's worth a shot?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 27 Sep 2010 21:38:55 -0700

> Sent: Monday, September 27, 2010 4:19 PM

As this work isn't specifically within charter, I'd like to continue it on [email-masked].

I'll reply over there.

---

From: Michael Deutschmann <[email-masked]>
Date: Tue, 28 Sep 2010 01:09:07 -0700 (PDT)

On 2010-09-27, John R. Levine wrote:
> And since this group seems to be obsessed with arcane corner cases,
> what do you do with a discardable message if it's sent to two addresses,
> one of which is a mailing list and one of which isn't?

That's a trivial specific case, of a general problem important in
spamfighting.  While a perfect solution would indeed require an extension
to SMTP, we have ways to approach it.

(Basically, give 4xx's at RCPT TO: when about to accept mail to boxes
with divergent filters.  But since this delays mail, when possible just
merge the competing filters into one common denominator, accepting
possible "overblocking".)

But it's not even a problem for modern mailing lists.  They can afford to
send a "bounce" message in this case, as they already have a confirmed
opt-in communication channel to talk with their subscribers.

It wouldn't work out if a non-subscriber posts to the list, but for other
reasons, modern lists make it a requirement to opt-in subscribe and then
suspend delivery, should one want to post without reading.

---

From: Michael Deutschmann <[email-masked]>
Date: Tue, 28 Sep 2010 01:37:48 -0700 (PDT)

> problem for some mail systems too large to ignore.

If DKIM and ADSP had been invented ten years ago, perhaps
post-transaction validation would have become the norm.

But some time ago, spamfighters (who have been driving MTA software
innovation) became deeply troubled by the fact that content-level
spamfilters such as SpamAssassin could only be used in a way that either
generates backscatter or causes false-positives to simply vanish.

So, by lobbying and contribution of coding effort, they've pushed the
dominant MTAs to structure themselves so as to be able to do significant
analysis during the moment between CR LF '.' CR LF and its reply.

It does break the intent of the RFCs, which expressly demand minimal
delay at that juncture to avoid duplicate messages, but we don't care.
Duplicate messages are far less horrible than backscatter.

Anyhow, with that infrastructure in place, DKIM checking is trivial.  At least
message hashing can be streamed.  We don't need to wait until CR LF '.'
CR LF to *begin* analysing.

Oh, and in any ADSPbis, I would like to see a flag that forbids silent
discard but permits in-transaction rejection.

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 28 Sep 2010 11:39:58 +0100

--On 27 September 2010 11:07:41 -0400 "John R. Levine" <[email-masked]> 
wrote:

> with what is unlikely to be more than a rare misconfiguration.

You recommend a particular course of action (discarding) for dealing with 
ADSP/MLM problems. I think you're almost exactly right except that the 
action should be to deny instead of discarding. The rarity of the 
misconfiguration would be an argument for ignoring the case entirely: it 
doesn't speak to whether one should discard rather than deny once you've 
gone to the trouble to detect the case. That's the only disagreement that I 
have with your message.

> When you

I already know when I have a good DKIM signature because SpamAssassin 
checks this at SMTP time. I already know when I'm delivering a message to a 
locally hosted list, because I couldn't route the message otherwise. I 
haven't implemented ADSP checks yet, because the community is still 
discussing the best way to do this. However, it's just another DNS lookup. 
We already do several of those for every message that we handle.

Exim (our MTA) is designed to do *all* message checking at SMTP time. It 
uses ACLs that can run at any point in the SMTP session limited only by the 
availability of information. It's trivial to move an ACL from one part of 
the SMTP process to another. The alternative is to pipe the message to an 
external process which would then deliver it back. It's *much* easier to 
simply do this in an ACL, and there is no ACL that runs after the SMTP 
session is closed.

Exim documentation gives instructions for running anti-spam software like 
SpamAssassin, and anti-malware software like ClamAV during the SMTP 
session. After the SMTP session, you'd have to route the messages through a 
secondary server to perform those functions. It would be arcane, and less 
flexible. We've been running SpamAssassin and ClamAV during the border SMTP 
session for many years now, and introduced DKIM checks about two years ago 
with zero impact on performance (because spamassassin and ClamAV already do 
a heck of a lot more DNS lookups and content processing).

Here's the hardware that I'm running it on. We've got four of these 
machines for resilience (two each in two data centres). Any one of the 
machines can handle peak loads on its own: They're specced to handle our 
IMAP load, but don't perform that role any longer, because OSX has an 
artificial limit on simultaneous process numbers.

XServe G5 (purchased in 2004)
2x Power PC G5 2.0GHz processors, with typical load averages of about 1.0
6GB RAM (that was for IMAP processes). Currently they use about 1GB, and 
I'd be happy with 2GB per machine.
DNS servers are local to the machines, to reduce network accesses.

Really, performance isn't a problem.

> of which is a mailing list and one of which isn't?

It'll remain an arcane corner case only if you're successful in preventing 
uptake of ADSP. Either way, the correct solution is worth discovering. Our 
configurations deal with a lot of corner cases already.

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 28 Sep 2010 12:17:25 +0100

--On 27 September 2010 23:05:46 -0400 "John R. Levine" <[email-masked]> 
wrote:

> to reject or discard on ADSP failures.  Still seems like a lot of work
> for  a largely nonexistent problem.

I know which addresses deliver to *my* mailing lists. They live on a 
different host, and I check the address so that I know the recipient is 
valid before accepting the message.

The only difficulty arises when messages have multiple recipients. There 
are several options here, when one of the recipients turns out to be 
troublesome, but others don't:

1. Treat them all the same, and reject the entire message.
2. Treat them all the same, and deliver to all.
3. Use selective defers to split the stream into two (this is a fairly 
widely known technique in Exim circles, used to permit application of 
different SMTP time content based filtering rules)
4. Discard the troublesome recipients, notifying the sender (perhaps only 
when the sender mail domain matches the signing domain).

If selective defers are regarded as difficult, then it's probably best to 
(A) reject troublesome messages when their is only one recipient, and (B) 
discard troublesome recipients when there are multiple recipients, and 
notify the sender. Since the message has a good DKIM signature, the signer 
may be held responsible for any collateral spam that's generated.

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 28 Sep 2010 12:24:43 +0100

--On 27 September 2010 11:39:43 -0700 Dave CROCKER <[email-masked]> wrote:

> It's been a significant revelation, for me, to realize how common it is
> for DKIM  processing to occur during the SMTP session.
>
> So SMTP issues reduce to finding ways of preventing the cross-net
> transfer of  data or even of preventing the SMTP session.  Oddly, I think
> the latter is more  feasible than the former.

Actually, it's not the traffic that I see as the problem. It's the amount 
of processing that is performed on the body of the message. We already use 
SpamAssassin and ClamAV on every message that we accept, and that's way 
more effort than a DKIM verification.

However, with Spamhaus' new DKIM/domain and IP whitelists, I expect to be 
able to reduce the SpamAssassin scanning (we'd never fail to use ClamAV), 
once we have confidence in the whitelists. Therefore, I expect to be able 
to reduce the load on our hosts when good DKIM signatures are present.

For domains like gmail.com, I'm considering working on rate-limiting by 
author address. Of course, the rate limit would be different for a message 
with a dkim pass.

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 28 Sep 2010 12:28:01 +0100

> to SMTP, we have ways to approach it.

LMTP would be a fine extension to SMTP, for these purposes.

But why not accept, then later bounce, messages with good DKIM signatures? 
That should be acceptable where the signing domain and return-path domain 
match, should it not? Otherwise, send the notification to the author.

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 28 Sep 2010 11:59:42 +0100

> send back a bounce or drop it.

Oh, but I already know that my MLM is going to break any message with a 
signed body. UK law practically mandates the addition of unsubscription 
information in a message footer. We certainly require it locally.

---

From: Graham Murray <[email-masked]>
Date: Tue, 28 Sep 2010 13:10:51 +0100

> information in a message footer. We certainly require it locally.

Why does it have to be in the footer when (for many MLMs) it is also in
the List-Unsubscribe: header[1]? The 'excuse' that MUAs do not display
the header details does not hold water as the MLM footer would come
after the '-- ' author's signature separator and some MUAs will not
display the signature and if the original email was multipart/alternate
does the unsubscription information have to be included in all (normally
text/plain and text/html) alternatives?

[1] Which does not break the author's DKIM signature.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Steve Atkins <[email-masked]>
Date: Tue, 28 Sep 2010 06:33:06 -0700

On Sep 28, 2010, at 5:10 AM, Graham Murray wrote:

> the header details does not hold water

Putting it in the List-Unsubscribe header that's not displayed
to recipients is pretty much equivalent to putting it in the X-Bamboozle
header that's not displayed to recipients when it comes to displaying
legally required content to recipients.

> as the MLM footer would come
> display the signature

I don't believe that's a behaviour you'd see in any commonly used MUA.

> and if the original email was multipart/alternate

You'd need to consult a lawyer familiar with your local laws, and ideally
also the local laws of every one of your recipients to answer those
questions[1].

But, when talking about legally required elements of a message the
sensible question to ask is often "Do you want to fund the lawsuit?".

Much more to the point, many people sending email via mailing lists have
a need to add information by modifying the body of the message, most
easily by adding it in the footer of the mail. Arguing that they
don't have that need, and hence that you don't need to support
that behaviour, isn't going to fly.

Cheers,
  Steve

[1] In the US the answer is yes, the unsubscription information
needs to be displayed to the recipient whether they're using
a plain-text only MUA or not, if it's a situation where it needs
to be displayed at all.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 28 Sep 2010 16:33:13 +0100

> text/plain and text/html) alternatives?

The law requires that there be an easy to use address for unsubscribing. 
The List-unsubscribe header: would do the job nicely, if the majority of 
people were using mail clients that expose it by default. I don't know of 
any mail client which does that.

The footer, on the other hand, is displayed by most mail clients. The 
legislation doesn't require that absolutely every case is covered. It's not 
been tested in court, but I imagine that reasonable effort would be the 
test applied.

Now, it may be that adding a footer isn't enough, but if that's the case, 
then relying on the header is even worse.

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 28 Sep 2010 09:32:23 -0700

On 9/13/2010 11:58 AM, Murray S. Kucherawy wrote:
> people believe the cost incurred by switching to end-of-DATA filtering vs.
> connect-time filtering is a lot larger than I believe.  And they [claim to]
> have the data to support that position from large customers,...

This issue keeps popping up.  We need to find a way to get some solid data
published about the costs and tradeoffs.

I wonder whether this is a task best pursued in MAAWG?

d/
-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 28 Sep 2010 10:18:02 -0700

> mailstreams then all I can say is "Darwin was right".

I agree with you completely.

The problem is that customers of a receiving ISP often do /not/ agree with you.

When their ISP discards mail the customer wanted, the explanation "well, it's 
what the author told me to do" typically does not work.  And since the 
customer's contact is with the receiving ISP, it is the receiving ISP that must 
alter their activity.  Since discarding got them in trouble, they will, at best, 
start discarding much more selectively. "Selectively" means using information 
beyond ADSP.

Given sufficient selectivity, the mechanism that defines "selective" will 
contain enough information to make ADSP redundant.

d/
-- 

   Dave Crocker

---

From: John Levine <[email-masked]>
Date: 28 Sep 2010 17:53:54 -0000

>> That no workable envelope-level DKIM equivalent has materialized to
>> date is unfortunate.
>> 

Probably not.  BATV is about 2/3 of what a scheme like that would be.
It has a bounce address with a signature hash of the original bounce
address and a timestamp, with its main limitation being that it uses a
private key rather than public key signature, which would be
straightforward to add.

It works well for me, but people say it causes problems due to
changing bounce addresses for the same correspondent (a surprising
amount of software keys on bounce address) and local parts longer than
64 characters, a limit that some MTAs still enforce.

To limit replays, it could include both the bounce and recipient
addresses in the hash, but that would recreate much of what's wrong
with SPF.  So unless you have a truly brilliant way to solve all
these problems (we can always hope), I don't see any point to going
down this road again.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 28 Sep 2010 20:01:54 +0200

On 28/Sep/10 12:59, Ian Eiloart wrote:
> --On 27 September 2010 19:26:37 +0200 Alessandro Vesely<[email-masked]>
> wrote:
>

Signatures may still survive if they use l=.  Probably, the best 
method for determining whether a signature has been broken is to 
simply verify it again.  BTW, running OpenDKIM testsuite, it seems 
that verifying is an order of magnitude faster than signing.  Thus, an 
extra verification shouldn't hurt.

As a curiosity, I've noted that MLMs usually avoid duplicating the 
subject-tag (possibly even if it was present twice in the original.) 
However, they almost invariably duplicate the footer, if it's already 
present.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 28 Sep 2010 14:35:26 -0400

> From: Dave CROCKER [mailto:[email-masked]]
> Sent: Tuesday, September 28, 2010 1:18 PM
> To: MH Michael Hammer (5304)
> Cc: DKIM
> The problem is that customers of a receiving ISP often do /not/ agree
with
> you.

Where someone stands depends on where they sit. 

> When their ISP discards mail the customer wanted, the explanation
"well,
> it's
> customer's contact is with the receiving ISP, it is the receiving ISP
that
> must
> alter their activity.  Since discarding got them in trouble, they
will, at
> best,

I've been saying for a while that ADSP is broken by design. When we (the
group) reached the compromise that we did, I fully expected that data
would become publicly available that would help generate a collective
will to come up with a better/more robust implementation of ADSP. Put
hope in one hand and.... never mind.

> contain enough information to make ADSP redundant.

Not intending to be tongue in cheek but I have to ask.... so what's your
point? I think the activity in the "3rd party intermediary" space is
indicative that there is a need to solve the issue of whether folks
really mean the assertions they make and whether mailbox providers are
willing to believe/act on those assertions.

Mike

---

From: Jeff Macdonald <[email-masked]>
Date: Tue, 28 Sep 2010 15:11:52 -0400

On Tue, Sep 28, 2010 at 1:18 PM, Dave CROCKER <[email-masked]> wrote:
> alter their activity.

I'm not convinced this is entirely true. We often get queries from our
clients who get queries from their subscribers asking what happened to
the email they were expecting. In other words, the questions are being
initially directed to the Author, not the recipient's ISP, about the
missing email.

So the exchange is more likely to be:

1) message sent with restrictive policies
2) message bounces/is discarded
3) recipient feels unloved, asks Author why?
4) Author looks at logs and sees message was delivered, asks recipient
to ask their ISP why
5) recipient asks ISP why
6) recipient gets an answer from ISP (really?)

-- 
Jeff Macdonald
Ayer, MA

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 28 Sep 2010 15:29:22 -0400

> [email-masked]] On Behalf Of Jeff Macdonald
> Sent: Tuesday, September 28, 2010 3:12 PM
> To: DKIM
> with you.
> that must

Jeff,

Are you telling us that your clients are sending mail through your systems using ADSP=discardable? If not, what are the restrictive policies indicated in item "1)"?

For item "3)", can you indicate generally the nature of the mails involved? Are these transactional? marketing? Where's the love?

Just trying to understand.

Mike

---

From: Jeff Macdonald <[email-masked]>
Date: Tue, 28 Sep 2010 15:46:25 -0400

> Are you telling us that your clients are sending mail through your systems using ADSP=discardable? If not, what are the restrictive policies indicated in item "1)"?

Sorry, that was a generalization. I don't see us promoting ADSP. We
are not doing DKIM yet (about to pilot any week now). I just wrote
some documentation for client services in which I left out ADSP on
purpose. Although I do feel that ADSP is fine for marketing domains, I
suspect that our clients want all their messages delivered.

However, we do strict SPF/SenderID. Simply because of mandates by
certain groups or ISPs. And we'll publish ADSP records for clients who
ask for it.

> For item "3)", can you indicate generally the nature of the mails involved? Are these transactional? marketing? Where's the love?

Both. Believe it or not, some people live for bargains and haven't
discovered what a RSS reader can provide.

> Just trying to understand.

#1 could be shortened to "message sent" and the rest would still be true.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 28 Sep 2010 15:02:16 -0700

On 9/27/10 9:47 PM, Murray S. Kucherawy wrote:
> > On Monday, September 27, 2010 4:19 PM, Douglas Otis wrote:

TPA-Label involves ADSP being discussed on the dkim list.

> > Agreed, but not having a defense against trivial exploitation of
> > an authorization is not better. When a defensive requirement
> > proves unused, it can be removed without impact. Since this
> > information sets authorization requirements, adding the information
> > at a later date would not be compatible with existing
> > implementations.
>
>  That seems antithetical to the idea that this is all experimental
>  work, explicitly not on the standards track.

Some have expressed strong desires to improve DKIM deliverability by 
allowing fallback to other adopted verification methods.  TPA-Label 
permits such fallback without also requiring the same domain be used by 
alternative methods.

> > Types of authentication that might be used for existing
> > third-party services-
> >
> > 1) DKIM 2) TLS 3) SPF 4) EHLO/ADR
>
>  I wasn't aware we were scoping something intended to be universally
>  used. My focus has been strictly on DKIM. Other than TLS, we're not
>  talking about particularly strong authentication systems here so I'm
>  not sure we should spend the cycles to be that accommodating.
>  However, as I said before, decoupling ATPS from ADSP is a trivial
>  matter if that turns out to be the right way to go.

DKIM is unable to unilaterally authorize third-party services which 
impedes use of restrictive acceptance criteria.  With few exceptions, 
DKIM/ADSP "discardable" disrupts normal email use, and ADSP/SPF "all" is 
ineffective at blocking spoofed domains.  TPA-Label can remedy 
inappropriate message rejection or acceptance while also avoiding 
discarded messages.

You seem to agree TLS could be included as a compliance option in 
conjunction with restrictive acceptance assertions.  TPA-Label offers a 
fallback to other authentication/verification methods for graceful DKIM 
methodology transitions.

While SPF does not authenticate a source domain, SPF "-all" currently 
represents the predominate restrictive acceptance assertion aimed at 
mitigating loss of email credibility caused by domain spoofing.  The 
TPA-Label scheme offers fallback options that don't wait for universal 
DKIM adoption to improve legitimate domain acceptance and spoofed domain 
rejection rates.

Perhaps TLS will be adopted as a means for IPv6 email acceptance based 
upon a domain, and might even become a governmental requirement.  After 
all, restrictive assertions requiring Author Domain DKIM signatures 
accompany the From header field is disruptive for most third-party 
services, when compared with restrictive SPF assertions.  In addition, 
DKIM signatures will not be as good at protecting domain reputations 
when compared with the use of TLS.

>  Since any client can say anything it wants for an EHLO parameter, why
>  should it be considered a type of authentication?

The SMTP client identified by the EHLO might resolve the IP address used 
in the exchange.  While such resolution is not required by SMTP 
protocol, it might offer an opportunistic means to authenticate the 
administering domain as a fallback method.

> > presentation. The header field requirement is to offer simple
> > tactics against most phishing exploits:
> >
> > a) Sender b) List-ID
>
>  Why would one base any kind of security mechanism on a trivially
>  spoofed header field?

These header fields must match against TPA-Label specified domains.  The 
contained domains ensure the effectiveness of message sorting or header 
display in allowing recipients a means to differentiate email sources 
that might also contain the From header used by ADSP.  The source of 
these header fields must also correspond with specified domain and 
authentication/verification methods.

> > The most visible name to recipients is the domain found in the From
> > header, whether used as a basis for sorting, or when displayed in
> > addition to that of the friendly name.
>
>  Then why create semantics around other fields?

The From header field is not strictly bound to specific email sources, 
especially for third-party services.  In reviewing the number of such 
sources involved, a dedicated effort at constructing comprehensive _tpa 
zones can fully encompass all legitimate sources and avoid most of the 
issues related with SPF and ADSP discardable/all.  Ensuring inclusion of 
Sender or List-ID header fields helps isolate third-party service mail 
streams and provides recipients a means to differentiate direct and 
indirect messages.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 28 Sep 2010 23:27:52 +0100

> TPA-Label involves ADSP being discussed on the dkim list.

I've no idea precisely what Doug means here, but to avoid
doubt: the DKIM WG has a charter that does not currently
include work on TPA nor other possible alternatives, nor
any other tweak or alternative to ADSP.

There does seem to be interest (though nothing like
consensus) in these however so we're not trying to stop
discussion for now, in the hope that one or other garners
sufficient consensus that we might re-charter. (And in
any case, its clear that asking people on this list to
stop typing is currently pointless;-)

So these are all "unofficial" activities in the sense
that there is no plan for the WG to produce any RFCs.

S.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 28 Sep 2010 19:01:11 -0700

On 9/28/10 3:27 PM, Murray S. Kucherawy wrote:
>  Unless you're talking about revising ADSP (which it seems you are
>  specifically not doing since TPA is meant to cover other
>  technologies as well; plus, ADSP wasn't in your list), we're talking
>  about something new that is not in the current DKIM WG Charter.

The TPA-Label draft offers additional ADSP assertions having semantics 
intended to support _existing_ mailing-list and third-party practices.  
The DKIM charter states the following:
,---
Consider issues related to mailing lists, beyond what is
already documented. ...
'---

> > Some have expressed strong desires to improve DKIM deliverability
> > by allowing fallback to other adopted verification methods.
> > TPA-Label permits such fallback without also requiring the same
> > domain be used by alternative methods.
>
>  The first sentence there seems contradictory to me; if you're
>  falling back to other methods, we're no longer talking about mere
>  DKIM deliverability.

Sorry, should have said DKIM/ADSP deliverability, which is based upon 
DKIM Author Domain Signatures.  The TPA-Label draft offers alternative 
ADSP assertions that indicate the possible availability of domain 
specific exceptions.  When exceptions are not found, non-compliant 
messages are to be rejected, as opposed to being discarded or scored in 
some fashion.

> > impedes use of restrictive acceptance criteria.
>
>  DKIM specifically allows a domain to give a third party signing
>  authority by putting into the DNS a public key matching a private
>  key that is in possession of that authorized third party. Unless
>  there's an assertion being made that this mechanism creates a
>  hardship, I'm still not clear why that's been dismissed as a
>  possibility.

Utilizing a discussion list and mitigating domain spoofing is not 
possible with existing ADSP assertions.  Nor is publishing public keys 
for all such discussion lists either a practical or a wise solution.  
Inclusion of List-ID or Sender header fields as an ADSP compliance 
requirement places less reliance upon only the From header fields in the 
recognition of message sources whenever authorizing third-party services.

> >> Since any client can say anything it wants for an EHLO
> >> parameter, why should it be considered a type of authentication?
> >
> > The SMTP client identified by the EHLO might resolve the IP address
> > used in the exchange. While such resolution is not required by
> > SMTP protocol, it might offer an opportunistic means to
> > authenticate the administering domain as a fallback method.
>
>  The DNSOP working group has repeatedly advised against use of
>  reverse DNS as a mechanism for client authentication. Do we claim to
>  have expertise they are lacking?

See:
http://tools.ietf.org/html/draft-otis-dkim-tpa-label-06#section-12.4
The SMTP EHLO or HELO hostname must resolve the IP address of the SMTP 
client.  Reverse DNS is not used.

>  For that matter, one could invent a scheme that mandates any piece
>  of data must match any other piece of data, both of which are
>  potentially (perhaps even often) under the control of a miscreant.
>  I'm not sure I see how this is useful.

Requiring additional header field compliance better ensures different 
mail streams remain recognizable by recipients.  Many MUAs already 
display Sender, and many who subscribe to mailing-lists already sort 
using List-IDs.  Whether or not recipients see the required header 
field, their requirement helps isolate authorizations to specific mail 
streams, such as messages emitted by the authorized domain's 
mailing-list services.  The TPA-Label response includes authentication 
requirements intended to exclude miscreants.  The general premise is 
exceptional authorization is only given to trustworthy services.

>  Moreover, identification of a client as legitimate or otherwise
>  based on HELO/EHLO data has proven problematic if only because of
>  common configuration errors. Enforcing something along these lines
>  will likely create more operational problems than it solves.

There is no assured authentication method specified by SMTP.   This 
leaves a range of options that might be employed by third-party 
services, such as mailing-lists.  However, ADSP's convention of only 
binding Author Domain DKIM signatures with the From header field 
disrupts these services whenever restrictive assertions are made.  A 
goal of the TPA-Label draft is to leverage the strongest authorization 
method available.  The strongest confirmed authentication method 
indicated within the TPA-Label for the domain in question reduces the 
receiver's discovery efforts.

> > These header fields must match against TPA-Label specified
> > domains. The contained domains ensure the effectiveness of message
> > sorting or header display in allowing recipients a means to
> > differentiate email sources that might also contain the From header
> > used by ADSP. The source of these header fields must also
> > correspond with specified domain and authentication/verification
> > methods.
>
>  ADSP makes a binding between the "d=" and the domain in the From:
>  field, the most visible of them all, and we've seen extremely narrow
>  use of this, much less success. I have doubts that expanding that
>  logic to other less common or less visible fields will see more
>  adoption or success.

Few are willing to allow a few percent of their mail stream to be 
discarded just to mitigate domain spoofing.  Those who have taken the 
extreme measure of asserting ADSP "discardable" did so after realizing a 
significant reduction in return business whenever recipients are not 
adequately protected against spoofing.  By asserting "discardable", 
their domain is no longer able to exchange messages with most 
mailing-lists.  Use of sub-domains or cousin domains is likely to create 
confusion and similar negative reactions driving away business when 
mailboxes become flooded with messages containing their new unrestricted 
domains.

The goal of the TPA-Label draft is to allow consolidation on to a well 
protected email domain, where issues of unintended rejection or 
discarding are avoided.  While this requires additional effort by the 
sender, the data needed to publish necessary exceptions is already 
available and can be used to populate a _tpa zone. :^)

>  I think if you're going to say a particular domain is authorized to
>  sign your mail and verifiers should consider such mail "good", then
>  you've already granted that domain the ability to pass your policies
>  through at least one vector. Constraining that domain to pass your
>  policies only one particular way doesn't gain you anything: Either
>  the domain is not compromised in which case everything's fine
>  anyway, or it does get compromised in which case the intruder can
>  simply generate malicious mail within the constraints of your policy,
>  and you're burned regardless of what policy you post.

While many mailing-lists adequately exclude abusive subscribers, and 
properly confirm subscriptions, most simply redistribute messages as 
received, flattened, annotated, with header fields added.  Annotations 
within the Subject line and message body, along with inclusion of 
specific header fields can be leveraged to discourage exploitation of 
authorized third-party services.  This should offer far superior results 
over that obtained using SPF -all or ADSP discardable.  The TPA-Label 
mechanism also offers a method to recover from damaged signatures 
whenever a path related authentication remains available and offers 
adequate protections.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Tue, 28 Sep 2010 22:32:53 -0400

> that there is no plan for the WG to produce any RFCs.

Early this year, the group "new goals" and correct me if I 
misunderstood, was to implement, experiment and collect data, 
especially for ADSP and Mailing List Software designs.

If I recall, we gave ourselves at least 1 year to collect data.

This is happening now. We implemented DKIM + POLICY, the R&D and 
statistics collection has commenced, and specifically with a focus 
towards policy and interaction/associations with Mailing List 
Software. The market research is very clear there is a strong interest 
for third party authorization protocols.

ASDP as it stands now has limited value.  But it offers an extensions 
feature and we are leveraging this to explore third party 
authorization solutions - the missing big piece in all this.

While I clearly understand the charter does not include new I-D, I 
believe in the same way the "Out of Scope" Reputation modeling helped 
alter 4871 with 4871bis, we can also learn from the "out of scope" 
ADSP extensions R&D to help codify and fine tune RFC 5617 (ADSP) with 
a 5617bis.

---

From: "John R. Levine" <[email-masked]>
Date: 29 Sep 2010 00:44:31 -0400

> any mail client which does that.

pine/alpine does, but I agree, most MUAs don't show headers other than To, 
From, Cc, and Subject.

This might be a good time to remind people that MLMs in their current form 
are not broken, and any proposal that requires them to stop doing 
something that they're currently doing, like rewriting messages or adding 
message tags, is a non-starter.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Wed, 29 Sep 2010 03:01:16 -0400

> contain enough information to make ADSP redundant.

Dave,

Policy is policy, whether its another form or not, heuristic policy, 
classification, reputation or a "selective approach" or what have you, 
it is still a sender/receiver "policy" per se.

I don't think anyone wants to delete mail for no good reason, thats no 
fun. And that includes mail marked as discardable.  For some 
implementations, it could just mean a larger negative weight for a 
classification policy.

But I think those who believed in strong self-asserting policies, as 
in SSH and and SPF will also like to see them in DKIM as well.  There 
many industry special arrangements where a hard DKIM policy is 
desirable before REPUTATION - a requirement I believe, takes place.

The Online Trust Alliance started in its September 2010 "Email 
Authentication Adoption Progress Report" [1]

    Use of ADSP is recommended for high profile brands at potential
    risk of abuse.

The popular MLM Mailman started [2]

     To develop standards to assist with email lists as an
     alternative to the last option above that provides a neat solution,
     there could be a third-party domain signing policies. Some standard
     that allows senders to define which third party signatures 
receipents
     should receive, even if the author domain signature is broken.

SpamAssasin now incorporates logic to "assign" local ADSP policy 
overrides for domains that don't have them [3]

The eCert report "Email Sender Authentication Deployment Best 
Practices and Considerations" is riddled with recommendations for 
strong DKIM Polices [4], even though the 2009 report recognize ADSP is 
still work in progress.

The inertia is growing and systems large to small, from all segments 
of the industry want to see how DKIM implementation can help besides 
just reputation.

The point is - give people the option to screw up and get their 
sender/receiver policy and technology right to allow them the learn 
how to disseminate their mail more deterministically than what 
Reputation currently provides.

One small point. On our system, the stats show a high phishing of our 
local domain or hosted domain accounts (MAIL FROM: 
[email-masked]).  They are all 100% immediately 
rejected simply because the names don't exist.

Some systems will not have a SMTP LEVEL Mail From check (for 
scalability reasons or just not capable, not integrated) and if the 
mail was allowed to be accepted, only will a DKIM+POLICY provide a 
100% equivalent protection.  Without policy, many of these exclusive 
messages would be passed to the user putting them at risk.

Note there is an operational reason for validating the MAIL FROM. I am 
not speaking of CBV (Call back Verifier), but local account 
verification.  If not checked, a bounce can to a non-existing account. 
  So we check the return path if its locally hosted domain.

[1] 
https://otalliance.org/resources/authentication/Q3_2010%20Email%20AuthenticationSup9-14.pdf
[2] http://wiki.list.org/display/DEV/DKIM

[3] 
http://mail-archives.apache.org/mod_mbox/spamassassin-dev/200903.mbox/[email-masked]/SpamAssassin/%3E
[4] 
http://www.bitsinfo.org/downloads/Publications%20Page/BITSSenderAuthenticationDeploymentFINALJun09.pdf

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 29 Sep 2010 05:55:53 -0400

>message tags, is a non-starter.
Since nothing requires anyone do anything with respect to DKIM, I'm hard pressed to imagine something that doesn't meet that requirement.

Scott K

---

From: John Levine <[email-masked]>
Date: 29 Sep 2010 17:52:01 -0000

>>This might be a good time to remind people that MLMs in their
>>current form are not broken, and any proposal that requires them to
>>stop doing something that they're currently doing, like rewriting
>>messages or adding message tags, is a non-starter.

>Since nothing requires anyone do anything with respect to DKIM, I'm
>hard pressed to imagine something that doesn't meet that requirement.

I was thinking of the various proposals to rewrite From: addresses, to
outlaw subject tags and message footers, and otherwise change the
behaviors that MLM users expect in order to make them conform to
various ideas of how DKIM and/or ADSP are supposed to work.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 29 Sep 2010 11:19:02 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of John Levine
> Sent: Wednesday, September 29, 2010 10:52 AM
> Cc: [email-masked]
> Subject: Re: [ietf-dkim] Corner cases and loose ends, was, draft-vesely-dkim-joint-sigs
> 

If the current MLM draft attempts to "outlaw" anything, that should be corrected.  But I don't think it hurts anyone to point out that an MLM that actually does want to try to preserve author signatures, for whatever reason, should realize what options it has.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 29 Sep 2010 18:03:04 -0700

On 9/29/10 11:15 AM, Murray S. Kucherawy wrote:
> > On Tuesday, September 28, 2010 7:01 PM, Douglas Otis wrote:
> > The TPA-Label draft offers additional ADSP assertions having
> > semantics intended to support _existing_ mailing-list and
> > third-party practices. The DKIM charter states the following:
 >>,---
> > Consider issues related to mailing lists, beyond what is already
> > documented. ...
 >>'---
 >
>  I believe the intent of that item is to document current MLM/DKIM
>  issues vis a vis already-published documents, as is done in the draft
>  that is currently a WG item. Extending ADSP or creating new
>  protocols doesn't seem to fit within that goal.

While done with the best intentions, the dkim-mailinglists draft in 
section 4.1 Author-Related Signing, recommendations should be considered 
a bad practice for domains being phished and making strict ADSP assertions.
http://tools.ietf.org/html/draft-ietf-dkim-mailinglists-02#page-11

The motivation behind strict ADSP assertions is to mitigate damage 
caused when recipients are heavily phished.  Redirecting phishing to 
unprotected sub-domains represents a bad practice as this will add to 
user confusion and dissatisfaction.  Problems related to ADSP will not 
be resolved by permitting delivery of phishing attempts that purport to 
be from a sub-domain.  At least the last sentence in the section admits 
only prohibiting use of mailing-lists is likely to be successful since 
any restrictive ADSP assertion will disrupt most of these informal 
third-party services.

DKIM/ADSP can exclude delivery of deceptive messages that neither SPF or 
Sender-ID are able to reliably accomplish.  Using ADSP with TPA-Label 
exceptions can also significantly reduce false positives by taking 
advantage of the strongest verification method available.  This 
includes, but is not limited to, using DKIM signatures not within the 
Author Domain.

As a secondary effect, domains making the only actionable restrictive 
ADSP assertion of "discardable" will find their email delivery integrity 
will suffer.  In no small part, much of the damage to delivery integrity 
is caused by a unilateral change with ADSP assertion of "strict" to 
"discardable".  This change was done with a mistaken belief DKIM 
signatures are not normally verified prior to acceptance.

> > Sorry, should have said DKIM/ADSP deliverability, which is based
> > upon DKIM Author Domain Signatures. The TPA-Label draft offers
> > alternative ADSP assertions that indicate the possible availability
> > of domain specific exceptions. When exceptions are not found,
> > non-compliant messages are to be rejected, as opposed to being
> > discarded or scored in some fashion.
>
>  I'm confused. You say TPA allows fallback to other adopted
>  verification methods, but you also say it refers specifically to
>  DKIM/ADSP deliverability. I'm not clear on how both can be
>  simultaneously true.

SPF authorizations fail more often than DKIM signature validations, but 
the percentages for either are not insignificant.  As such, some domains 
would like path verifications to act as a fallback method whenever DKIM 
signatures don't verify.

More than a third of business related domains publish the most 
restrictive SPF assertions that pertain to Mail From parameters,  and 
only 0.3% of domains being heavily phished publish the most restrictive 
ADSP assertions that pertain to the From header field.  As such, ADSP's 
inability to pass accountability to subsequent systems makes "simple" 
ADSP implementations incompatible with most third-party services.

TPA-Label records give senders a means to recommend appropriate 
exceptions that are needed to overcome ADSP's accountability passing 
limitations.  Without this ability, ADSP is likely to remain largely 
unpublished, and when published, not acted upon due to its high rate of 
false positives.

> >> reverse DNS as a mechanism for client authentication. Do we claim
> >> to have expertise they are lacking?
> >
> > See:
> > The SMTP EHLO or HELO hostname must resolve the IP address of the
> > SMTP client. Reverse DNS is not used.
>
>  I think that's a marginal improvement. Even if the HELO/EHLO
>  parameter can be resolved to the client IP address, that doesn't tell
>  you anything about the client other than it has control over some
>  portion of the DNS.

Control of the DNS also identifies the DKIM administrative domain.  In 
addition, verification of the SMTP client indicates which domain is 
actually introducing the message into the mail stream, where DKIM may 
not whenever a signature does not include an origination header field 
that matches the RCPT TO parameter.  This difference becomes significant 
when dealing with replay abuse.

> > Requiring additional header field compliance better ensures
> > different mail streams remain recognizable by recipients. Many
> > MUAs already display Sender,
>
>  Which ones? None that I've ever used do.

Perhaps you have not used Microsoft Outlook or did not recognize how the 
information is displayed, or haven't selected these headers in Apple 
Mail by using the viewing show header detail selections?  Displaying 
these headers is not really necessary, as they are just intended to 
isolate different mail streams.

> > and many who subscribe to mailing-lists already sort using
> > List-IDs. Whether or not recipients see the required header field,
> > their requirement helps isolate authorizations to specific mail
> > mailing-list services. The TPA-Label response includes
> > authentication requirements intended to exclude miscreants. The
> > general premise is exceptional authorization is only given to
> > trustworthy services.
>
>  Again, I'm not seeing the utility here. If A can say "You can trust
>  that mail apparently from us and signed by B is authorized by us as
>  long as it bears a Sender: header field containing B", then an
>  intruder compromising B need only meet that requirement to be able to
>  send mail as A and have verifiers improperly trust it.

No authorization scheme can fully mitigate problems caused when normally 
reputable third-party services become compromised.  On the other hand, 
by overtly authorizing a third-party and leveraging their own 
authentication/verification methods, it remains clear which 
administrative domain needs to remediate a compromised system.

This would not be the case had the Author Domain routinely published 
public keys for various third-party services, after also arranging to 
have unique selectors used by each of these services.  It is also 
difficult to imagine a safe practice for widely distributing DKIM keys 
when such exchanges currently rely upon ad-hoc methods.  The TPA-Label 
scheme avoids any exchange of key and selector information and always 
ensures the administrative domain of the third-party service remains 
apparent.

>  That you're catering to MUA display or sorting options only makes
>  that worse in my view. In any case, it's a tiny hurdle to overcome once
 > a penetration has occurred. Thus, there seems little gain here over
>  simply authorizing B to sign for A regardless of message structure.

Required inclusion of specific header fields uses simple flags "S" or 
"L".  These header fields ensure recipients are able to utilize more 
than just From header fields when determining the source of a message, 
such as those from various informal third-party services.  Since 
mailing-lists are often unable to authenticate who issued the message, 
ensuring the means to isolate these mail streams represents an essential 
mechanism needed to discourage this weakness from becoming exploited.

Another level of protection is afforded when most who now subscribe to 
mailing-lists already segregate these messages from other messages 
arriving in their inbox.  The display of the header field is not always 
needed for the header field requirement to be an effective exploitation 
deterrent.

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 30 Sep 2010 12:05:00 +0100

> various ideas of how DKIM and/or ADSP are supposed to work.

But nowhere has anyone suggested REQUIRING any MLM to do any of those  
things.

They are all offered as suggesstions for things MLMs MIGHT do do get  
themselves out of such DKIM-caused troubles as they find themselves in.

---

From: Steve Atkins <[email-masked]>
Date: Thu, 30 Sep 2010 08:15:25 -0700

> themselves out of such DKIM-caused troubles as they find themselves in.

There are no DKIM-caused troubles they could possibly get themselves
into.

If you mean ADSP, say ADSP. If you really mean DKIM you need
to expand on what sort of troubles you're talking about.

Cheers,
  Steve

---

From: Douglas Otis <[email-masked]>
Date: Thu, 30 Sep 2010 18:19:50 -0700

On 9/30/10 8:15 AM, Steve Atkins wrote:
> >> I was thinking of the various proposals to rewrite From:
> >> addresses, to outlaw subject tags and message footers, and
> >> otherwise change the behaviors that MLM users expect in order to
> >> make them conform to various ideas of how DKIM and/or ADSP are
> >> supposed to work.
> >
> > But nowhere has anyone suggested REQUIRING any MLM to do any of
> > those things.
>
> > They are all offered as suggestions for things MLMs MIGHT do do
> > get themselves out of such DKIM-caused troubles as they find
> > themselves in.
>
>  If you mean ADSP, say ADSP. If you really mean DKIM you need to
>  expand on what sort of troubles you're talking about.

Agreed.  Those receiving benefits from a protocol change have an 
incentive to make additional efforts.   Companies who employ email in 
their services are finding customers will discontinue the service when 
inundated with phishing attempts.  The impact of this is more 
significant than fraud losses related to phishing.

ADSP's use of From header fields to establish signature compliance is 
incompatible with third-party services, unlike SPF's use of MailFrom 
parameters for authorization compliance.  Unfortunately, since SPF 
compliance is based upon unseen header fields, it can not mitigate 
receipt of phishing attempts and its authorizations fail more often than 
DKIM validations.

The problem is clearly related to ADSP and not DKIM, although domains 
publishing ADSP assertions can exclude phishing messages on behalf of 
their customers.  It is counter productive to suggest mailing-lists 
should make changes when these services are not commonly used in 
phishing attempts for several reasons.

Annotations applied by most mailing-lists allow sorting and recognition 
of messages not received directly from the identity within the From 
header field.  Although the actual source of these messages is seldom 
confirmed, the typical segregation of mailing-list messages from other 
direct sources help prevent these services from becoming a likely 
phishing exploitation vectors.  Recommending that mailing-lists to 
discontinue their annotations will cause problems, since these messages 
often lack source authentication, and without annotations, recipients 
will be unable to discern which are from less trustworthy sources.

Rather than suggesting changes to the From header field, it might be 
better to have third-party services include a Sender header field 
instead.  After all, this was a feature found in the original SSP 
draft,  expecting to leverage "on behalf of" notations made by Outlook.  
Changing the use of the From header field would require a number 
handling changes that seem counter productive.

Is there a safe way to shift DKIM signature compliance based upon the 
 From header field to that of the Sender header field?  The TPA-Label 
scheme would be one such method, which also allows the use of the 
List-ID header field as well.  The TPA-Label scheme also has the domain 
being phished making the greatest effort, as it should be.

Receivers that then implement this scheme benefit by having lower false 
positive detections of illegitimate messages, while not seeing the 
disruption of third-party services.  This also avoids a bad practice of 
using sub or cousin domains in attempts to limit protection rather than 
seeking comprehensive solutions.

-Doug