Re: [ietf-dkim] Case for ADSP "dkim=except-mlist"

[Michael Deutschmann]

On Fri, 16 Oct 2009, hector wrote:
> mich...@talamasca.ocis.net wrote:
> > But you don't need to be a vanity domain to *advertise* except-mlist, and
> > us vanity domains would appreciate it if you do.
>
> If you could Package this and provide it as a persistent protocol
> methodology for everyone to follow, then GO WEST!!

The problem is that any solution that doesn't require the intelligence
typically only possessed by vanity domains, will require a global whitelist
of mailing lists -- so that spammers and phishers cannot make fake lists just
to use the back door.

To improve upon except-mlist as I've described it, every mailinglist in the
whitelist must be unforgeable -- either via SPF, or a third-party DKIM.  No
exceptions, since the public whitelist neutralizes the SbO advantage of the
vanity-domain approach.

Then, we have the problem that a site can only publish
"dkim=except-mlist-on-global-whitelist" if it *knows* that none of it's users
subscribe to mailinglists unknown or unacceptable to the GW.

So, we've then made a lateral move from a policy that can only be *applied*
by vanity domains, to one that can only be *advertised* by vanity domains

It's still a worthy goal, which is why I've suggested that we also reserve a
namespace of policy names which devolve to except-mlist when not specifically
known to a validator.  It just doesn't replace naked except-mlist.

(Actually, I see one escape from the global whitelist -- a sender could
program his mailserver to recognize mail outgoing to trusted mailing lists
and use l=0 signatures in that case.  But that is also practical only for
vanity domain senders.)

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

Re: [ietf-dkim] Case for ADSP "dkim=except-mlist"

[hector]

mich...@talamasca.ocis.net wrote:

> In theory, a spammer could forge them, since none of them (not even
> spf-discuss!!) use SPF.  


I see in our SPF Mail Summary Reports that you are one of the top
posters. :)

> Loosely, you could say that dkim=except-mlist is equivalent to dkim=unknown
> when the validator is a big ISP, and equivalent to dkim=all when the
> validator is a vanity domain.
> 
> But you don't need to be a vanity domain to *advertise* except-mlist, and
> us vanity domains would appreciate it if you do.



If you could Package this and provide it as a persistent protocol
methodology for everyone to follow, then GO WEST!!

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

Re: [ietf-dkim] Case for ADSP "dkim=except-mlist"

[hector]

Steve Atkins wrote:

> On Oct 16, 2009, at 6:33 AM, Michael Deutschmann wrote:
>>
>> To review, "dkim=except-mlist" would mean:

 >> ..

>> (Incidentally, anyone have a better name for this policy?)
> 
> dkim=all.
> 
> dkim=all says that you sign all mail you send, and nothing more. The
> difference between that and what you write above for a receiver is
> nil, I think.

0.89+ IFF "nothing more" implies additional 3rd party signatures are 
possible.  In other words, there will be two or more, but the 1st 
party signature is expected.

From: per...@1ps.com
Dkim-Signature: d=1ps.com ...
Dkim-Signature: d=3ps.com ...

Part of the problem is the lost of integrity and 3ps will strip the 
1st party.

From: per...@1ps.com
Dkim-Signature: d=3ps.com ...

So the receiver seeing that 1ps has DKIM=ALL sees a violation and does 
not know what to do.

Is 3ps.com a known trusted party?  <<  GOOD! Excellent!
Is 3ps.com an anonymous party? <<  MAYBE BAD?

DKIM=ALL is exactly like the SPF = SOFTFAIL (?ALL rule)

"Something is wrong, but we don't know why. It could be bad
 it might be a good partner. We don't know, so its probably
 safer if you just record this, maybe score it and watch it.
 If you have other proof that 3ps.com is doing something
 bad or wrong, then you decide."

DKIM=DISCARDABLE is exactly like a SPF=FAIL  (-ALL rule)

"This is not what we expected, I don't care what went wrong.
 Its not ours. Please do us a favor and you a favor by getting
 rid of it. I promise, I won't sue you."

The point of this discussion, now in its different thread forms, at 
least from my POV, is whether 3ps.com should of preempted this problem 
by seeing the 1ps.com DKIM=ALL and saying:

"Hmmm, you know, this is a can of worms. I think it is best
 to filter this submission and not forward a 1st party
 broken message. What is the risk assessment here?

   break and forward?GOOD or BAD?
   filter?   GOOD or BAD?

 h, I wonder if I should send a report to the domain
 that it was probably hacked? If I don't get a feedback,
 then we can remove its membership if this problem continues."

Who knows steve! :)

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

Re: [ietf-dkim] Case for ADSP "dkim=except-mlist"

[Wietse Venema]

Michael Deutschmann:
> But guessing which list to forge is an SbO that the
> spammers have not pierced yet  Impersonating any list other than those 6
> is futile -- it will bounce off my anti-Bcc filter.

It's called spear-phishing, which is a form of targeted attack that
occasionally makes headline news.

Speaking of unintended consequences, this kind of anti-BCC filter
is an example of how a well-intended security feature can actually
help opponents to make email look more authentic (because they know
what list headers to impersonate in order to pass the filter).

You can require that those six approved lists sign such mail. That
requirement makes the proposed DKIM feature even more redundant.

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

Re: [ietf-dkim] brand protection, was Is anyone using ADSP?

[John Levine]

>I think you have missed the point. A malicious registrar might add/change  
>an ADSP record, contrary to the instructions of the domain owner who is  
>paying him.

Hmmn.  You might want to stop and familiarize yourself with the way that
domain registrations work.

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

Re: [ietf-dkim] Case for ADSP "dkim=except-mlist"

[Michael Deutschmann]

On Fri, 16 Oct 2009, hector wrote:
> How does a receiver know that the client is sending list mail? Do they
> need to look at some other 2822/5322 header?

In many cases, they don't.  Then they have to treat dkim=except-mlist as
dkim=unknown.  But they lose nothing from the existence of dkim=except-mlist.

But *I* can treat dkim=except-mlist as dkim=all, because my mailserver is
programmed to specifically recognize the six mailing lists I am subscribed
to, by their bounce addresses.

In theory, a spammer could forge them, since none of them (not even
spf-discuss!!) use SPF.  But guessing which list to forge is an SbO that the
spammers have not pierced yet  Impersonating any list other than those 6
is futile -- it will bounce off my anti-Bcc filter.

Loosely, you could say that dkim=except-mlist is equivalent to dkim=unknown
when the validator is a big ISP, and equivalent to dkim=all when the
validator is a vanity domain.

But you don't need to be a vanity domain to *advertise* except-mlist, and
us vanity domains would appreciate it if you do.

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

Re: [ietf-dkim] Issue: Deployment Guide Section 6.1/6.5 (ADSP/Forwader) conflict

[Franck Martin]

- "J.D. Falk"  wrote:

> Ian Eiloart wrote:
> 
> > That seems sensible to me. So lists should not forward email that
> they're 
> > about to render 'discardable' by breaking the signature. Instead,
> they 
> > should reject (5xx) or bounce (DSN) the message. Presumably, a bank
> wants 
> > to know if it has a bad email address for a customer.
> 
> Yep.
> 
> > Of course, if you 
> > aren't going to break the signature, or are rewriting the From:
> address, 
> > then it's OK to forward the email.
> 
> Probably.
> 
if you are rewriting the from and put the original sender in the sender: field, 
most MUA will display it like this:

Sent by JD Falk
on the behalf of DKIM-WG

Seems strange to me.

If you rewrite only the From: header then the MUA will display

from: DKIM-WG

then you hope there is a signature of some sort to know who sent the email 
originally.
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] brand protection, was Is anyone using ADSP?

[J.D. Falk]

Ian Eiloart wrote:

> As an admin, I'd like to be able to reject mail for lacking a DKIM 
> signature. Without a supporting ADSP, I risk the ire of my users. With a 
> supporting ADSP, I can point the finger at the publisher of the policy.

That's (more or less) the exact receive-side use case we were discussing 
when developing ADSP.

-- 
J.D. Falk
Return Path Inc
http://www.returnpath.net/
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Issue: Deployment Guide Section 6.1/6.5 (ADSP/Forwader) conflict

[J.D. Falk]

Ian Eiloart wrote:

> That seems sensible to me. So lists should not forward email that they're 
> about to render 'discardable' by breaking the signature. Instead, they 
> should reject (5xx) or bounce (DSN) the message. Presumably, a bank wants 
> to know if it has a bad email address for a customer.

Yep.

> Of course, if you 
> aren't going to break the signature, or are rewriting the From: address, 
> then it's OK to forward the email.

Probably.

> Oh, and if the list sees incoming mail 
> already has a broken signature, or none at all, then it should be discarded 
> by the list software (or its MTA).

Yep.

> The treatment of email with authors in a domain with 'dkim=discardable' 
> policy seems absolutely straightforward. What's more complicated is the 
> treatment of email with authors in a domain with 'dkim=all' policy. There's 
> no guidance about handling such mail.

Agreed; we need more operational experience here.

-- 
J.D. Falk
Return Path Inc
http://www.returnpath.net/
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] brand protection, was Is anyone using ADSP?

[hector]

John R. Levine wrote:

> Really, reputation is about individual registrants and domains, and as we 
> all know, you don't need ADSP for people you already know something about.
> 

John we all concur with you. we always have.  But you continue to 
ignore what others are saying; with no reputation information, no 
dkim-signature d=thirdparty.com to base it on,  the domain is at risk 
for abuse in the same way its done today - legacy spoofed domain with 
no attempt DKIMized it.

POLICY allows you to cover those security holes when the reputation is 
indeterminate.

Of course, thats besides the fact that we have no reputation standard 
to work with anyway and certainly not even a dozen or more if they 
were available that everyone can use with equal results.  Is that 
going to change any time soon?  Sound like a very very long wait.

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

Re: [ietf-dkim] brand protection, was Is anyone using ADSP?

[John R. Levine]

>> To put it concretely, your registrar is JANET, ...
>
> Mine's JANET, too. Sure, they won't all be accurate, but if they're 
> inaccurate then I know how to get hold of someone to fix the problem. Anyway, 
> the person who cares most about the accuracy is the domain owner (or their 
> customers).

I have to disagree.  The person who cares most about the accuracy of ADSP 
is the recipient who has to decide whether to believe it.

If you say that Janet gets involved in fixing individual DNS records, I 
find that hard to believe, but you know them better than I do.  For 
commercial registrars such Godaddy and Tucows, whose service I resell to a 
few friends, I can assure you they know nothing, and I mean nothing, about 
their registrants beyond their credit card number what's in the WHOIS.  If 
someone complained to Tucows about one of their registrants, the most they 
could do is point to the reseller, who in most cases can't do much more 
than point to the WHOIS info.  In particular, they have no control over 
the registrant's DNS servers and couldn't fix them if they wanted to, 
which in most cases they wouldn't.

Really, reputation is about individual registrants and domains, and as we 
all know, you don't need ADSP for people you already know something about.

> As an admin, I'd like to be able to reject mail for lacking a DKIM signature.

With or without ADSP, you're going to have a very, very, very, very long 
wait.

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

Re: [ietf-dkim] brand protection, was Is anyone using ADSP?

[hector]

Ian Eiloart wrote:

> 
> --On 16 October 2009 10:28:01 -0400 hector  
> wrote:
> 
> I'd reduce it to this:
>ADSP RECORD
>   +=+
>   |   |  UNKNOWN  | ALL  |  DISCARDABLE |
>   |=|
>D  | NONE  |  pass | reject*  |   discard|
>K  |---+---+--+--|
>I  | 1PS   |  pass | pass |   pass   |
>M  |---+---+--+--|
>   | 3PS   |  pass | pass**   |   discard|
>   +=+
> 
> * reject rather than discard, so that the sender has a chance of detecting 
> their error. Especially true if you have an spf pass, for example, and the 
> domain has a reasonable reputation score.
> 
> ** pass, provided the third party signature passes, and you have some 
> explanation for the breakage - eg, the message has been through the list. 
> However, in this situation, you must rely on the reputation score for the 
> third party signing domain, not the original signing domain or the author. 
> This is a case where I'd (very slightly) prefer to see a broken signature, 
> than none at all, I think. I might even give credence to an 
> authentication-results header for the original signature, if that header 
> were signed, and the list domain had a reasonable reputation.

The problem with rejects is that it can cause a MLS to initiate 
sending subscriber removal notification messages. For example, the 
mipassoc.org list server will send you a "Last Warning" removal 
notification if your hosting server rejected a list message X number 
of times.  That was the key issue and reason I posted the concern; we 
now have concrete proof of an interoperability problem caused by the 
intermediary intentionally ignoring RFC 5671 restrictive policies. 
IOWs, we now have user victims who with no fault of their own are now 
subject to removal threats due to MLS signer *neglectfully* not 
filtering this ADSP domains.

In regards to the **pass, IMV, I am not concern about how we can 
accept 3rd party signatures.  There are ideas for this.  But its 
probably better to use another policy and not DKIM=ALL unless the 
specs were changed to provide those semantics. But as it stands, it 
clearly does not say that 3rd party signatures are implied in shape or 
form.  I see no proof or wordings whatsoever that DKIM=ALL allows 3rd 
party signers. The fact that it is open-ended with no explicit action 
semantics does not mean 3rd party signatures are allowed. If that is 
the desire then IMV it needs to be updated to say so.  Otherwise we 
have what we have now - confusing.  With all due respect to Mr. 
Deutschmann, Mr. Levine wrote RFC 5617. Not Mr. Thomas. Mr. Levine's 
interpretation is what counts.

--

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

Re: [ietf-dkim] brand protection, was Is anyone using ADSP?

[Ian Eiloart]

--On 16 October 2009 10:28:01 -0400 hector  
wrote:

>
>ADSP RECORD
>   +=+
>   |   |  UNKNOWN  | ALL  |  DISCARDABLE |
>   |=|
>D  | NONE  |  pass | discard? |   discard|
>K  |---+---+--+--|
>I  | 1PS   |  pass | pass |   pass   |
>M  |---+---+--+--|
>   | 3PS   |  pass | discard? |   discard|
>   +=+

I'd reduce it to this:
   ADSP RECORD
  +=+
  |   |  UNKNOWN  | ALL  |  DISCARDABLE |
  |=|
   D  | NONE  |  pass | reject*  |   discard|
   K  |---+---+--+--|
   I  | 1PS   |  pass | pass |   pass   |
   M  |---+---+--+--|
  | 3PS   |  pass | pass**   |   discard|
  +=+

* reject rather than discard, so that the sender has a chance of detecting 
their error. Especially true if you have an spf pass, for example, and the 
domain has a reasonable reputation score.

** pass, provided the third party signature passes, and you have some 
explanation for the breakage - eg, the message has been through the list. 
However, in this situation, you must rely on the reputation score for the 
third party signing domain, not the original signing domain or the author. 
This is a case where I'd (very slightly) prefer to see a broken signature, 
than none at all, I think. I might even give credence to an 
authentication-results header for the original signature, if that header 
were signed, and the list domain had a reasonable reputation.


-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Case for ADSP "dkim=except-mlist"

[Steve Atkins]

On Oct 16, 2009, at 6:33 AM, Michael Deutschmann wrote:

> I'd like to more emphatically state the case for adding a
> "dkim=except-mlist" policy to ADSP.  It will soon become a practical
> issue for me, since my mailserver software (Exim) is going to support
> DKIM in its next version.
>
> Without it, I'd have to use "dkim=unknown", which is effectively no  
> ADSP
> at all.
>
> To review, "dkim=except-mlist" would mean:
>
> I sign everything leaving my bailiwick, but may post to mailing lists
> that break the signature.  You are *on your own* in telling the
> difference between mailing list mail (which may be good despite a
> broken signature) and directly sent mail (that is always signed).  If
> you can't tell, then treat as dkim=unknown (ie: assume a message is
> ML traffic unless you know otherwise.).
>
> (Incidentally, anyone have a better name for this policy?)

dkim=all.

dkim=all says that you sign all mail you send, and nothing more. The
difference between that and what you write above for a receiver is
nil, I think.

Cheers,
  Steve
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Case for ADSP "dkim=except-mlist"

[hector]

Michael Deutschmann wrote:

> I'd like to more emphatically state the case for adding a
> "dkim=except-mlist" policy to ADSP.  It will soon become a practical
> issue for me, since my mailserver software (Exim) is going to support
> DKIM in its next version.
> 
> Without it, I'd have to use "dkim=unknown", which is effectively no ADSP
> at all.
> 
> To review, "dkim=except-mlist" would mean:
> 
>  I sign everything leaving my bailiwick, but may post to mailing lists
>  that break the signature.  You are *on your own* in telling the
>  difference between mailing list mail (which may be good despite a
>  broken signature) and directly sent mail (that is always signed).  If
>  you can't tell, then treat as dkim=unknown (ie: assume a message is
>  ML traffic unless you know otherwise.).
> 
> (Incidentally, anyone have a better name for this policy?)


IMO  dkim=list would be fine for what you describe.

The concern I have two folds:

   1) Its a threat entry point.

I rather see Doug's TPA or something list the DSAP 3pl=domain-list idea.

   2) Complexity.

It appears to require a rule such as:

if signed and 3rd party and contains some form of
   a list header, precedence: list perhaps
  then pass (positive classification).

Now, this is GREAT.  Fantastic!  It might work, but we have the same 
problem that is always the case for everything else:

What do you do when it fails?

Its hard for me to shallow the idea that its ok to accept mail when 
you declare all these parts are needed, but not say anything about 
when its not detected.

> The determination of whether it is good to add a new policy to ADSP
> should rest on three issues:
> 
> 1. Is it backwards compatible?


+1

> 2. Will senders ever deploy it?
> 3. Will receivers ever treat it differently than what the senders would
> use if it were unavailable?
> 
> For #1, it is indeed compatible.  RFC 5617 explictly says that unknown
> values are to be treated identically to "unknown".
> 
> Under Levine's interpretation of RFC 5617, "unknown" is clearly the best
> approximation to "except-mlist".  Under the Thomas interpetation, it is
> a small step back, but enough people endorse the Levine interpretation
> that it would be foolish to count on sites treating "all" as
> "except-mlist".


Hmmm, wouldn't it be nice if we have a WG interpretation?

The Levine doctrine "Do as I say, not as I write" A.K.A IGNORE it, is 
design to have unrestricted 3rd party signers (middle ware). They are 
not going to look at it.

> For #2, do I even need to argue?  


I hope so. Everyone else is required to argue their case. :)

> Any site that passes all outgoing mail
> through a DKIM-aware smarthost qualifies for "except-mlist", but not for
> "all" if there are any mailing list subscribers.


How does a receiver know that the client is sending list mail? Do they 
need to look at some other 2822/5322 header?

Who adds this? senders or author domains?  It sounds like the sender. No?

> #3 is the weakest point, but I can offer my personal testimony that I
> have all my mailing lists whitelisted, and could thus only improve my
> bad-mail determination accuracy if this extra information was available
> in the ADSP records of purported senders.


IMO, it is the weakest point and also the one you need to address.

Our SMTP server is integrated with our LIST Server, so all list agents 
ids are validated at SMTP level (RCPT TO) and its validated like its 
any other hosted user or domain.  Thats not an issue to accept the 
message.

The issue is the failure of the author domain policy.  Lets assume the 
following DNA:

From: us...@domain1.com
To: user2:domain2.com
Dkim-Signature:  d=mipassoc.org
Precedence: list

I believe you are saying domain1.com has ADSP++ record:

   dkim=except-mlist

and the domain2.com receiver sees this policy and also maybe 
Precedence: list to determine it was a list message?

Why?  What is gained by checking for some "list" header?

Why not just consider previous polices like in SSP

 op=-  which is a must sign and allows for 3rd party signatures.

Anyway, what I want to know if what happens when you have this:

From: us...@domain1.com
To: user2:domain2.com  (MDA2)
Precedence: list

and there is no signature, Is this a Discardable message for domains 
with dkim=except-mlist?

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

Re: [ietf-dkim] Case for ADSP "dkim=except-mlist"

[Ian Eiloart]

--On 16 October 2009 06:33:08 -0700 Michael Deutschmann 
 wrote:

> I'd like to more emphatically state the case for adding a
> "dkim=except-mlist" policy to ADSP.  It will soon become a practical
> issue for me, since my mailserver software (Exim) is going to support
> DKIM in its next version.
>
> Without it, I'd have to use "dkim=unknown", which is effectively no ADSP
> at all.
>
> To review, "dkim=except-mlist" would mean:
>
>  I sign everything leaving my bailiwick, but may post to mailing lists
>  that break the signature.  You are *on your own* in telling the
>  difference between mailing list mail (which may be good despite a
>  broken signature) and directly sent mail (that is always signed).  If
>  you can't tell, then treat as dkim=unknown (ie: assume a message is
>  ML traffic unless you know otherwise.).
>
> (Incidentally, anyone have a better name for this policy?)

"dkim=all" If you read ADSP in conjunction with section 3.1 of RFC 5016, 
then "dkim=all" means exactly that: "Domain Alice provides information that 
it signs all outgoing mail, but places no expectation on whether it will 
arrive with an intact first party signature."




> --
>
> The determination of whether it is good to add a new policy to ADSP
> should rest on three issues:
>
> 1. Is it backwards compatible?
> 2. Will senders ever deploy it?
> 3. Will receivers ever treat it differently than what the senders would
> use if it were unavailable?
>
> For #1, it is indeed compatible.  RFC 5617 explictly says that unknown
> values are to be treated identically to "unknown".
>
> Under Levine's interpretation of RFC 5617, "unknown" is clearly the best
> approximation to "except-mlist".  Under the Thomas interpetation, it is
> a small step back, but enough people endorse the Levine interpretation
> that it would be foolish to count on sites treating "all" as
> "except-mlist".
>
> For #2, do I even need to argue?  Any site that passes all outgoing mail
> through a DKIM-aware smarthost qualifies for "except-mlist", but not for
> "all" if there are any mailing list subscribers.
>
># 3 is the weakest point, but I can offer my personal testimony that I
> have all my mailing lists whitelisted, and could thus only improve my
> bad-mail determination accuracy if this extra information was available
> in the ADSP records of purported senders.
>
>
> (By the way, it might be a good idea to pre-reserve a family of policy
> names, which would have the property of devolving to "except-mlist"
> instead of "unknown" when the validator does not know them specifically.
> This would allow 100% backwards-compatible later deployment of schemes
> that provide for easier detection of desired mailing list traffic.)
>
>  Michael Deutschmann 
> ___
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rules.html



-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] brand protection, was Is anyone using ADSP?

[hector]

Ian Eiloart wrote:

> 
> --On 14 October 2009 15:39:12 -0400 hector  
> wrote:


> It may never be. But, it's relatively new, so it doesn't surprise me that 
> it's not in use. However, It's also not surprising that people who may use 
> the RFCs wish to understand the implications, and explore the problems 
> before implementing.


I couldn't agree more.

But I think the current advisement is not to use it, so R&D, 
exploration, experimentation, and developing corrective measures is 
next to nil.  Under such conditions most systems won't bother or can't 
afford to deal with alpha ware in a production environment.  So to me, 
it shouldn't be a surprise that there is little support, even thought 
that might be high interest.

Its not very hard to create a DKIM simulation based on establishing 
your boundary conditions for this process with the current specifications.

ADSP has three possible boundary conditions:

 unknown
 all
 discardable

DKIM-BASE has five possible boundary conditions:

  not signed
  signed by 1st party - valid
  signed by 1st party - invalid
  signed by 3rd party - valid
  signed by 3rd party - invalid

when can be reduced to three using the RFC 4871 semantics that 
promotes/demotes an invalid signature to no signature (never signed) 
status:

  not signed
  signed by 1st party - valid
  signed by 3rd party - valid

Therefore you have nine theoretical possible outcomes:

   ADSP RECORD
  +=+
  |   |  UNKNOWN  | ALL  |  DISCARDABLE |
  |=|
   D  | NONE  |  pass | discard? |   discard|
   K  |---+---+--+--|
   I  | 1PS   |  pass | pass |   pass   |
   M  |---+---+--+--|
  | 3PS   |  pass | discard? |   discard|
  +=+


IMO, we have seven high confidence deterministic possibilities.  For 
the DISCARD? results, as you said, DKIM=ALL is open-ended with no 
semantics (by design) so its left to ambiguous interpretation and 
local policy.

Now, consider the following:

IMV, I think the RFC 4871 semantics for promoting/demoting a broken 
signature to no signature is somewhat flawed.   IMV, it was not when 
policy was a major consideration of the DKIM specification and such a 
semantic naturally fit the valid signature requirement policies.

But when you separate POLICY from DKIM-BASE, "data" was now lost for 
augmented technologies to learn, explore, etc.  In other words, when 
the WG decided to separate the two developments, it invalidated this 
semantic. It should of been removed IMO. The reason is because we lost 
intent.

In the NONE/DKIM=ALL cell, this could be the result of two different 
mail scenarios:

  NO (REAL) SIGNATURE
  INVALID SIGNATURE

To me, that is two different classification or weights.

I don't have the answer, but I believe it begins with the question, 
which message do you trust more, one that didn't have a signature or 
one that was broken?

For the former (Missing), one can argue it is a genuine spoof or a 
roaming user using the domain address from some 3rd party service 
(i.e. hotel).  One can also say the roaming user is a thing of the 
pass as most users now have direct internet access to their main 
hosting service from anywhere in the world.

For the latter (broken), one can argue there was malicious intent but 
it could be some relay that innocently broke the integrity.

So the RFC 4871 promotion (or demotion depending on your POV) of 
Broken to no signature status hides intent.  This can become important 
if we are going to be looking at other evidence, headers, scoring or 
classification concept.

Anyway, my 2 pennies.

--
HLS


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

[ietf-dkim] Case for ADSP "dkim=except-mlist"

[Michael Deutschmann]

I'd like to more emphatically state the case for adding a
"dkim=except-mlist" policy to ADSP.  It will soon become a practical
issue for me, since my mailserver software (Exim) is going to support
DKIM in its next version.

Without it, I'd have to use "dkim=unknown", which is effectively no ADSP
at all.

To review, "dkim=except-mlist" would mean:

 I sign everything leaving my bailiwick, but may post to mailing lists
 that break the signature.  You are *on your own* in telling the
 difference between mailing list mail (which may be good despite a
 broken signature) and directly sent mail (that is always signed).  If
 you can't tell, then treat as dkim=unknown (ie: assume a message is
 ML traffic unless you know otherwise.).

(Incidentally, anyone have a better name for this policy?)

--

The determination of whether it is good to add a new policy to ADSP
should rest on three issues:

1. Is it backwards compatible?
2. Will senders ever deploy it?
3. Will receivers ever treat it differently than what the senders would
use if it were unavailable?

For #1, it is indeed compatible.  RFC 5617 explictly says that unknown
values are to be treated identically to "unknown".

Under Levine's interpretation of RFC 5617, "unknown" is clearly the best
approximation to "except-mlist".  Under the Thomas interpetation, it is
a small step back, but enough people endorse the Levine interpretation
that it would be foolish to count on sites treating "all" as
"except-mlist".

For #2, do I even need to argue?  Any site that passes all outgoing mail
through a DKIM-aware smarthost qualifies for "except-mlist", but not for
"all" if there are any mailing list subscribers.

#3 is the weakest point, but I can offer my personal testimony that I
have all my mailing lists whitelisted, and could thus only improve my
bad-mail determination accuracy if this extra information was available
in the ADSP records of purported senders.


(By the way, it might be a good idea to pre-reserve a family of policy
names, which would have the property of devolving to "except-mlist"
instead of "unknown" when the validator does not know them specifically.
This would allow 100% backwards-compatible later deployment of schemes
that provide for easier detection of desired mailing list traffic.)

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

Re: [ietf-dkim] Issue: Deployment Guide Section 6.1/6.5 (ADSP/Forwader) conflict

[Charles Lindsey]

On Fri, 16 Oct 2009 00:27:57 +0100, hector   
wrote:

> Charles Lindsey wrote:
>
>> There is no SHOULD|MUST about what recipients do
>
>
> I agree, but at some point implementators will need to transform the
> functional specification into a technical one.  i.e. Software logic
> with options etc.

At which point some accepted Common Practice would come in handy.

>> It might say that all invalid DISCARDABLE email "SHOULD" be marked as  
>> such
>> and sent on.
>
>
> Currently the specification says to discard.  I personally think it
> would rubber against the specs if an implementor added an option:
>
>   [X] Do not discard invalid DISCARDABLE mail. Mark it only.

All the standard says is that you have the full permission of the sender  
if you decide to Discard. At the most, it is a MAY Discard.

>> It might say that Listadmins "SHOULD", as a special case, take actions
>> different from other recipients (whether by adding A-R records, or
>> something else).

The case in question is where there is a valid signature when it arrives  
at the Listadmin. So he has no reason to Discard.

> I agree with your overall notes, but I do think that the exception is
> that there is a clear MUST Discard for invalid discardable mail that
> is independent from any anything else.  The main reason of course is
> that it must cover legacy transactions (mail without any additional
> and related DKIM DNA)

But the case we are talking about is where there WAS a valid signature,  
which has since been broken. But there is evidence from the listadmin  
(whom you might choose to trust) that it had been there. In that case, it  
is perfectly reasonable for a recipient to accept the message on the  
grounds that he has credible evidence that there WAS a valid signature.  
and hence that it indeed came from the purported Author.

-- 
Charles H. Lindsey -At Home, doing my own thing
Tel: +44 161 436 6131   
   Web: http://www.cs.man.ac.uk/~chl
Email: ...@clerew.man.ac.uk  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

Re: [ietf-dkim] brand protection, was Is anyone using ADSP?

[Charles Lindsey]

On Thu, 15 Oct 2009 16:19:36 +0100, John Levine  wrote:

>>> No, ADSP adds the ability for senders to make unverified assertions
>>> about their signing practices.  Unless you already have some
>>> knowledge about the domain, you have no idea whether it would be
>>> useful to believe it.
>
>> On the contrary, it adds the ability for domain owners to make those
>> asertions. Assuming that the domain owner has control of his own DNS
>> records, those assertions are as reliable as the reputation of the
>> relevant Domain Registrar (you can argue about how reliable that is,
>> if you wish).
>
> Huh?  Maybe things are different where you live, but in this part of
> the world, registrars like Godaddy have millions of customers and know
> nothing more about them than that their credit card charge for $8 was
> approved.  It's hard to imagine how anyone could think that a
> registrar would know anything at all about its customers mailing
> practices.

I think you have missed the point. A malicious registrar might add/change  
an ADSP record, contrary to the instructions of the domain owner who is  
paying him.

But I doubt Godaddy is that malicious. Generally speaking, if you see an  
ADSP resord, you can be 99.9% sure that it is there on the instructions of  
the domain owner, and therefore does not require further verification.

-- 
Charles H. Lindsey -At Home, doing my own thing
Tel: +44 161 436 6131   
   Web: http://www.cs.man.ac.uk/~chl
Email: ...@clerew.man.ac.uk  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

Re: [ietf-dkim] brand protection, was Is anyone using ADSP?

[Ian Eiloart]

--On 14 October 2009 15:39:12 -0400 hector  
wrote:

> Doug Otis wrote:
>
>> On 10/14/09 10:51 AM, Dave CROCKER wrote:
>
>
>>> All of which begs the basic question of why this thread is being
>>> pursued?  The questions and answers aren't new.
>>
>> Good question.
>>
>> While email reputation has managed to retain a semblance of email
>> functionality, this often results in more than 90% of the email stream
>> being refused.  These refusals are often based upon the reputation of
>> the IP address used by SMTP clients.
>>
>> DKIM offers an opportunity to leverage names as a mechanism for
>> acceptance and to authorize third-party domains that might act on behalf
>> of the Author Domain without formal arrangements.  The authorization
>> could be done in a safe and economical manner to allow Author Domains a
>> means to benefit from the other domains reputation and services, and to
>> better ensure messages are accepted.
>
> +1.

+2

> However, I think the answer is Dave is seeking is evidence of problems
> which in his mind because RFC 5617 is only a standard by name and not
> supported by anyone, there is no problem.   I guess that is only
> possible if indeed RFC 5617 will never be used by anyone.

It may never be. But, it's relatively new, so it doesn't surprise me that 
it's not in use. However, It's also not surprising that people who may use 
the RFCs wish to understand the implications, and explore the problems 
before implementing.

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



-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Issue: Deployment Guide Section 6.1/6.5 (ADSP/Forwader) conflict

[Ian Eiloart]

--On 14 October 2009 09:39:42 -0700 Steve Atkins  
wrote:

>
> The whole point of "discardable" is that the final recipient should not
> see it in that case. It's for things like transactional mail, bank
> statements, that sort of thing - which should never go to mailing lists 
anyway as
> the sender believes it should be sent directly to the final recipient,
> or not at all.
>
> (If you disagree with my characterization of the sort of email that
> might use discardable that's fine, but lets be specific about the 
operational
> details, like what classes of email we're talking about. Discussing it
> solely in the abstract protects the discussion from common sense.)

That seems sensible to me. So lists should not forward email that they're 
about to render 'discardable' by breaking the signature. Instead, they 
should reject (5xx) or bounce (DSN) the message. Presumably, a bank wants 
to know if it has a bad email address for a customer. Of course, if you 
aren't going to break the signature, or are rewriting the From: address, 
then it's OK to forward the email. Oh, and if the list sees incoming mail 
already has a broken signature, or none at all, then it should be discarded 
by the list software (or its MTA).

If a list does nevertheless forward an email, after rendering it 
'discardable', of course RFC 5617 says that it should be discarded by the 
MDA. It also occurs to me that 'discardable' means that you can deploy 
per-recipient policies after seeing the message body - by passing the 
message to some recipients, but not others. That's not usually possible.

The treatment of email with authors in a domain with 'dkim=discardable' 
policy seems absolutely straightforward. What's more complicated is the 
treatment of email with authors in a domain with 'dkim=all' policy. There's 
no guidance about handling such mail.

List operators need to be advised that breaking signatures in such domains 
may result in the message becoming undeliverable, even though the inbound 
message carried a valid signature. There are several actions that a list 
could take, to mitigate consequential problems:

1. Not apply VERP bounce policies to messages that are consequently 
rejected. This risks eroding the value of VERP if 'dkim=all' becomes widely 
deployed among domains used by the list's members. Eventually, VERP could 
become unusable if it didn't adapt. Oh, but the lists would become unusable 
first, if people are rejecting messages from dkim=all domains. Is there any 
sense in such domains applying lightweight signatures that are less likely 
to be broken by lists? Can such a thing be done without making the 
signatures reuable? Is it possible to sign the From: header, + the subject 
*after* a list prefix, and the body *before* a list footer? Or would these 
just be newly exploitable holes?

2. Make sure they sign their messages, so that recipients have some 
confidence that this isn't a spammer spoofing a trusted list. And, as has 
been suggested, make clear that they've assessed the signature before 
breaking it. OF course, this is spoofable, OF course it relies on a trust 
relationship between the recipient and the list. But, the recipient 
(ideally) knows which lists s/he's subscribed to, and with DKIM can tell 
whether to trust the list. Some MDA or MUA assistance would be really 
useful here.

You know, I'm not sure I'm averse to a world in which a spammer can only 
deliver mail by adding list-id headers for lists that I'm not subscribed 
to! One where most domains publish 'dkim=all', and all my legitimate mail 
has carries a dkim signature, and broken signatures only come mailing lists 
that I've either subscribed to or not.

3. Some fancy munging of the From: header (like VERP, perhaps), in such a 
way that replies could be routed to the sender? Ugh!




> A more interesting case to consider is acm.org style forwarders,
> where the forwarder is, in many ways, the final destination, and where
> the address at the forwarder is "owned" by the final recipient, and
> where they will likely ask for transactional mail of the sort that
> senders might consider discardable be sent.
>
> Cheers,
>   Steve



-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] brand protection, was Is anyone using ADSP?

[Ian Eiloart]

--On 14 October 2009 10:51:10 -0700 Dave CROCKER  wrote:

>
>
>> You're trying very hard to infer something that was not stated or
>> implied in either what Dave said above or in the specs themselves.
>>
>> In general, people are trying very hard to infer something from DKIM
>> signatures and from ADSP that simply can't be safely inferred from the
>> protocols as they have been defined so far.
> ...
>>
>> Some constructive work would be really helpful here rather than all this
>> fist-pounding
>
>
> All of which begs the basic question of why this thread is being pursued?
> The  questions and answers aren't new.
>
> d/

I'll guess that it's because the conversation helps its participants to 
understand the issues. If I've come across as fist-pounding, or repetitive, 
then I apologise. I do, however, have a better understanding of the issues 
than when I started, and I hope that others do, too.





-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] brand protection, was Is anyone using ADSP?

[Ian Eiloart]

--On 15 October 2009 15:19:36 + John Levine  wrote:

>>> No, ADSP adds the ability for senders to make unverified assertions
>>> about their signing practices.  Unless you already have some
>>> knowledge about the domain, you have no idea whether it would be
>>> useful to believe it.
>
>> On the contrary, it adds the ability for domain owners to make those
>> asertions. Assuming that the domain owner has control of his own DNS
>> records, those assertions are as reliable as the reputation of the
>> relevant Domain Registrar (you can argue about how reliable that is,
>> if you wish).
>
> Huh?  Maybe things are different where you live, but in this part of
> the world, registrars like Godaddy have millions of customers and know
> nothing more about them than that their credit card charge for $8 was
> approved.  It's hard to imagine how anyone could think that a
> registrar would know anything at all about its customers mailing
> practices.
>
> To put it concretely, your registrar is JANET, which is a fairly
> reputable organization.  Are you claiming that means that ADSP
> published by random ac.uk subdomains are all going to be accurate and
> useful?

Mine's JANET, too. Sure, they won't all be accurate, but if they're 
inaccurate then I know how to get hold of someone to fix the problem. 
Anyway, the person who cares most about the accuracy is the domain owner 
(or their customers).

As an admin, I'd like to be able to reject mail for lacking a DKIM 
signature. Without a supporting ADSP, I risk the ire of my users. With a 
supporting ADSP, I can point the finger at the publisher of the policy.

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



-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html