As threatened, here's an I-D that says how one would publish a list of
domains for which it makes sense to discard unsigned mail.
Since I'm a big fan of running code, you can find such a list at
drop.services.net of domains that (in my opinion at least) sign all their
mail with DK or DKIM, and
dig txt paypal.com._drop.services.net
does not give me anything...
- Original Message -
From: "John R. Levine"
To: "DKIM List"
Sent: Tuesday, 22 June, 2010 7:00:15 AM
Subject: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd)
As threatened, here&#x
List"
> Sent: Tuesday, 22 June, 2010 7:00:15 AM
> Subject: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd)
>
> As threatened, here's an I-D that says how one would publish a list of
> domains for which it makes sense to discard unsigned mai
On 6/21/10 12:00 PM, John R. Levine wrote:
> As threatened, here's an I-D that says how one would publish a list
> of domains for which it makes sense to discard unsigned mail.
>
> Since I'm a big fan of running code, you can find such a list at
> drop.services.net of domains that (in my opinio
On Jun 21, 2010, at 1:00 PM, John R. Levine wrote:
> As threatened, here's an I-D that says how one would publish a list of
> domains for which it makes sense to discard unsigned mail.
Looks like a good start, and almost shockingly simple. Any MTA/MFA support
yet? *grin*
--
J.D. Falk
Return
On Jun 22, 2010, at 11:28 AM, Michael Thomas wrote:
> On 06/22/2010 09:46 AM, J.D. Falk wrote:
>> On Jun 21, 2010, at 1:00 PM, John R. Levine wrote:
>>
>>> As threatened, here's an I-D that says how one would publish a list of
>>> domains for which it makes sense to discard unsigned mail.
>>
>>
On 06/22/2010 09:46 AM, J.D. Falk wrote:
> On Jun 21, 2010, at 1:00 PM, John R. Levine wrote:
>
>> As threatened, here's an I-D that says how one would publish a list of
>> domains for which it makes sense to discard unsigned mail.
>
> Looks like a good start, and almost shockingly simple. Any MTA
On 06/22/2010 11:07 AM, J.D. Falk wrote:
> On Jun 22, 2010, at 11:28 AM, Michael Thomas wrote:
>
>> On 06/22/2010 09:46 AM, J.D. Falk wrote:
>>> On Jun 21, 2010, at 1:00 PM, John R. Levine wrote:
>>>
As threatened, here's an I-D that says how one would publish a list of
domains for which
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of Michael Thomas
> Sent: Tuesday, June 22, 2010 10:28 AM
> To: J.D. Falk
> Cc: DKIM List
> Subject: Re: [ietf-dkim] New Version Notification for draft-
On 6/22/10 9:46 AM, J.D. Falk wrote:
> On Jun 21, 2010, at 1:00 PM, John R. Levine wrote:
>
>
>> As threatened, here's an I-D that says how one would publish a list of
>> domains for which it makes sense to discard unsigned mail.
>>
> Looks like a good start, and almost shockingly simple.
adsp is an assertion by a sender. John's list is a reputation of the sender's
adsp assertions (WAG)
On Jun 22, 2010, at 2:29 PM, Michael Thomas wrote:
> On 06/22/2010 11:07 AM, J.D. Falk wrote:
>> On Jun 22, 2010, at 11:28 AM, Michael Thomas wrote:
>>
>>> On 06/22/2010 09:46 AM, J.D. Falk wrote:
>> As threatened, here's an I-D that says how one would publish a list of
>> domains for which it makes sense to discard unsigned mail.
>
>Looks like a good start, and almost shockingly simple. Any MTA/MFA support
>yet? *grin*
Give me another week.
R's,
John
__
> You can choose to trust his assertions (by querying his list on
> verification failures) or ignore them (by not querying him in the
> first place). At least that's the theory, I believe.
Exactly. This is a scalability issue. You can afford to spend a fair
amount of effort investigating the re
In article you write:
>adsp is an assertion by a sender. John's list is a reputation of the sender's
>adsp assertions (WAG)
Not quite, it's a third party's assertions that are somewhat but not really
like ADSP
As far as I know Amazon doesn't make any ADSP assertions, but it is my
impression tha
On 6/22/10 11:40 AM, bill.ox...@cox.com wrote:
> adsp is an assertion by a sender. John's list is a reputation of the sender's
> adsp assertions (WAG)
> On Jun 22, 2010, at 2:29 PM, Michael Thomas wrote:
>
The vbr scheme will not help to mitigate a phishing problem, since it
allows the "authe
On 6/22/10 5:07 PM, John Levine wrote:
> Not quite, it's a third party's assertions that are somewhat but not really
> like ADSP
>
> As far as I know Amazon doesn't make any ADSP assertions, but it is my
> impression that they sign all their transactions with DK or DKIM, and
> they're certainly a p
-boun...@mipassoc.org
Date: Tue, 22 Jun 2010 17:37:26
To:
Subject: Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00
(fwd)
On 6/22/10 5:07 PM, John Levine wrote:
> Not quite, it's a third party's assertions that are somewhat but not really
> like ADSP
>
> As f
ry
>
> -Original Message-
> From: Douglas Otis
> Sender: ietf-dkim-boun...@mipassoc.org
> Date: Tue, 22 Jun 2010 17:37:26
> To:
> Subject: Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00
> (fwd)
>
> On 6/22/10 5:07 PM, John Levine wrote:
>>
In article <147cede9c1299e4aa...@lewes.staff.uscs.susx.ac.uk> you write:
>
>
>--On 23 June 2010 13:09:30 + deepvo...@gmail.com wrote:
>
>> Since Amazon set it up in the first place, wouldn't they be keenly aware
>> of the service signing issues?
>
>Well, if they're using ADSP, then they hav
On 06/24/2010 07:49 AM, John Levine wrote:
Are you making the assumption that all third party lists would be equally
> credible? That's no more likely than all DNSBLs being equally credible.
>
> In both cases, the good ones will make sure their data is correct,
> maybe by backchannels to the und
On Jun 24, 2010, at 8:21 AM, Michael Thomas wrote:
> On 06/24/2010 07:49 AM, John Levine wrote:
> Are you making the assumption that all third party lists would be equally
>> credible? That's no more likely than all DNSBLs being equally credible.
>>
>> In both cases, the good ones will make su
> So why does a domain that performs that painful audit and
> remediation need to then tell John's drop list that it's OK to
> drop unsigned mail? It doesn't. It can just publish an ADSP
> record and be done with it. No need to count on some unreliable,
> unaccountable point of failure to mediate t
On Jun 24, 2010, at 9:21 AM, Michael Thomas wrote:
> Any service that doesn't have an *explicit* guarantee from the mail
> domain itself that it signs all mail is worse than incompetent,
> it's harmful. A third party can *never* prove the negative that the
> domain in question doesn't have sources
On Jun 24, 2010, at 8:45 AM, Martijn Grooten wrote:
>> So why does a domain that performs that painful audit and
>> remediation need to then tell John's drop list that it's OK to
>> drop unsigned mail? It doesn't. It can just publish an ADSP
>> record and be done with it. No need to count on some
On 06/24/2010 08:43 AM, Steve Atkins wrote:
>
> On Jun 24, 2010, at 8:21 AM, Michael Thomas wrote:
>
>> On 06/24/2010 07:49 AM, John Levine wrote:
>> Are you making the assumption that all third party lists would be equally
>>> credible? That's no more likely than all DNSBLs being equally credib
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
> boun...@mipassoc.org] On Behalf Of Steve Atkins
> Sent: Thursday, June 24, 2010 8:43 AM
> To: DKIM List
> Subject: Re: [ietf-dkim] New Version Notification for draft-levine-dbr-
> 00(fwd
On 06/24/2010 08:45 AM, Martijn Grooten wrote:
>> So why does a domain that performs that painful audit and
>> remediation need to then tell John's drop list that it's OK to
>> drop unsigned mail? It doesn't. It can just publish an ADSP
>> record and be done with it. No need to count on some unreli
Subject: Re: [ietf-dkim] New Version Notification for draft-levine-dbr-
>> 00(fwd)
>>
>> The problem is that it's not possible to distinguish based solely on
>> self-published data the domain that's done all that work, and actually
>> understands the implications fro
On 06/24/2010 09:28 AM, J.D. Falk wrote:
> On Jun 24, 2010, at 9:21 AM, Michael Thomas wrote:
>
>> Any service that doesn't have an *explicit* guarantee from the mail
>> domain itself that it signs all mail is worse than incompetent,
>> it's harmful. A third party can *never* prove the negative tha
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
> boun...@mipassoc.org] On Behalf Of Michael Thomas
> Sent: Thursday, June 24, 2010 12:53 PM
> To: Martijn Grooten
> Cc: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim]New Version N
On Jun 24, 2010, at 10:03 AM, MH Michael Hammer (5304) wrote:
> If an organization doesn't understand the implications of publishing
> ADSP (or doing anything else for that matter) then the basic damage done
> is to themselves and their users. Their domain, their problem.
... and the problem of
> So my view of the service being discussed here isn't one where some
> guy in upstate NY claims to have full knowledge of which domains
> DKIM-sign all their outbound email. Rather, it's a service where the
> manager of the service uses claims made by the sender about whether
> they sign all of th
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
> boun...@mipassoc.org] On Behalf Of Steve Atkins
> Sent: Thursday, June 24, 2010 2:00 PM
> To: DKIM List
> Subject: Re: [ietf-dkim]New Version Notification for draft-levine-dbr-
> 00(f
On 06/24/2010 10:10 AM, Mark Delany wrote:
Conceivably "at risk" domains would first submit themselves to such a
> service and ask it to discover and publish (and/or feedback) counter
> examples.
>
> Since all you need is one counter example, getting 20 or 30 large,
> trusted mail providers to pa
>Maybe we need an ADSP flag that says "I think I sign all my outbound
>mail, and if a trusted third party vouches that I'm not entirely
>clueless about DKIM then you should trust them and treat this as
>"dkim=discardable", but otherwise don't pay too much attention to
>this and treat it as "dkim=un
> If an organization doesn't understand the implications of publishing
> ADSP (or doing anything else for that matter) then the basic damage
> done is to themselves and their users. Their domain, their problem.
I think that if you talk to ISPs whose customers call and ask why they
didn't get the m
>Nothing in the ADSP spec says that the ISP has to silently drop the
>mail.
Actually, it does. Read it again.
>For all you know the ISP may choose to automatically send a notice to
>the intended recipient indicating that they dropped mail from
>example.com based on the published request from exa
> -Original Message-
> From: John Levine [mailto:jo...@iecc.com]
> Sent: Thursday, June 24, 2010 6:24 PM
> To: ietf-dkim@mipassoc.org
> Cc: MH Michael Hammer (5304)
> Subject: Re: [ietf-dkim] New Version Notification for
draft-levine-dbr-
> 00(fwd)
>
> >
> Help me out here John, where exactly is that "silently drop" section? I
> see the discarding part but the "drop silently" part seems to be a bit
> silent.
Sheesh, Mike. Discard is an ordinary English word which I used in its
ordinary English sense. I suppose there might be people who say
"At
On 06/25/2010 08:44 AM, John R. Levine wrote:
>> Help me out here John, where exactly is that "silently drop" section? I
>> see the discarding part but the "drop silently" part seems to be a bit
>> silent.
>
> Sheesh, Mike. Discard is an ordinary English word which I used in its
> ordinary English
> -Original Message-
> From: John R. Levine [mailto:jo...@iecc.com]
> Sent: Friday, June 25, 2010 11:44 AM
> To: MH Michael Hammer (5304)
> Cc: ietf-dkim@mipassoc.org
> Subject: RE: [ietf-dkim] New Version Notification for
draft-levine-dbr-
> 00(fwd)
>
> >
> We seem to agree that discard means "throw away".
Evidently. But I do have the advantage of knowing what I meant when I
wrote the section we're arguing about.
> Now I'm really getting confused John. On the one hand you argue that
> there are hordes of panting implementers anxiously awaiting t
> -Original Message-
> From: John R. Levine [mailto:jo...@iecc.com]
> Sent: Friday, June 25, 2010 2:39 PM
> To: MH Michael Hammer (5304)
> Cc: ietf-dkim@mipassoc.org
> Subject: RE: [ietf-dkim] New Version Notification for
draft-levine-dbr-
> 00(fwd)
>
> >
On Jun 25, 2010, at 11:39 AM, John R. Levine wrote:
>> We seem to agree that discard means "throw away".
>
> Evidently. But I do have the advantage of knowing what I meant when I
> wrote the section we're arguing about.
This is, I think, the third or fourth time we've been through the "what d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> All messages from this domain are signed with an Author Domain
> Signature and are discardable, i.e., if a message arrives without
> a valid Author Domain Signature, the domain encourages the
> recipient(s) to discard it.
My interpret
> I don't recollect you proposing wording that included "silently" so it
> isn't even possible for a person going back and look at the discussions
> to know what you meant.
>
> We are therefore left with what you wrote and which the working group
> came to a consensus on.
Whatever. I find it hard
Hi Mike,
At 11:44 25-06-10, MH Michael Hammer (5304) wrote:
>And the rest of the world has the disadvantage of only knowing what is
>written in the RFC.
There is thread about the word at
http://mipassoc.org/pipermail/ietf-dkim/2008q1/009572.html
The authoritative answer is in Section 4.2.1 of RF
> -Original Message-
> From: John R. Levine [mailto:jo...@iecc.com]
> Sent: Friday, June 25, 2010 4:21 PM
> To: MH Michael Hammer (5304)
> Cc: ietf-dkim@mipassoc.org
> Subject: RE: [ietf-dkim] New Version Notification for
draft-levine-dbr-
> 00(fwd)
>
> > I
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
> boun...@mipassoc.org] On Behalf Of Jon Callas
> Sent: Friday, June 25, 2010 12:21 PM
> To: MH Michael Hammer
> Cc: IETF DKIM WG
> Subject: Re: [ietf-dkim] New Version Notification for d
>+1. OpenDKIM actually implements a reject (55x error) with the
>intent of giving the sender/victim an opportunity to detect a
>problem, an idea for which there is some obvious demand, though I
>imagine we should make that configurable and maybe even default it to
>an actual accept-but-throw-away
To: ietf-dkim@mipassoc.org
Sent: Saturday, 26 June, 2010 1:58:42 PM
Subject: Re: [ietf-dkim] New Version Notification for
draft-levine-dbr-00(fwd)
>+1. OpenDKIM actually implements a reject (55x error) with the
>intent of giving the sender/victim an opportunity to detec
Hi Franck,
At 19:49 25-06-10, Franck Martin wrote:
>Can openDKIM issue a 4xx code if not a single valid DKIM signature is found?
I suggest discussing about that on the OpenDKIM mailing
list. Opendkim supports fine-grained policy control (see
http://www.opendkim.org/opendkim-lua.3.html ).
Regar
--On 26 June 2010 01:58:42 + John Levine wrote:
>> +1. OpenDKIM actually implements a reject (55x error) with the
>> intent of giving the sender/victim an opportunity to detect a
>> problem, an idea for which there is some obvious demand, though I
>> imagine we should make that configurabl
--On 25 June 2010 14:39:04 -0400 "John R. Levine" wrote:
>> We seem to agree that discard means "throw away".
>
> Evidently. But I do have the advantage of knowing what I meant when I
> wrote the section we're arguing about.
Right, but knowing what you meant isn't the point. You're arguing ab
--On 25 June 2010 16:21:00 -0400 "John R. Levine" wrote:
>> I don't recollect you proposing wording that included "silently" so it
>> isn't even possible for a person going back and look at the discussions
>> to know what you meant.
>>
>> We are therefore left with what you wrote and which the
(More review of old chatter...)
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
> boun...@mipassoc.org] On Behalf Of J.D. Falk
> Sent: Tuesday, June 22, 2010 11:07 AM
> To: DKIM List
> Subject: Re: [ietf-dkim] New Version Notification fo
>I'm finally beginning to buy that something akin to DBR may be
>necessary, but it's still weird to me that the point is that the
>average sysadmin can't be trusted to do ADSP right. But then why,
>for example, can he/she be trusted to do DNS or SMTP or even TCP/IP
>right without some sort of vouc
On 7/25/10 5:48 PM, John Levine wrote:
> > I'm finally beginning to buy that something akin to DBR may be
> > necessary, but it's still weird to me that the point is that the
> > average sysadmin can't be trusted to do ADSP right. But then why,
> > for example, can he/she be trusted to do DNS or S
> As we all know, admins can and do screw up anything, but with most
> mistakes, the damage directly affects them. If you screw up your MX,
> your own incoming mail won't work. If you screw up your ADSP, your
> mail will work fine, while other people's mail systems will
> mysteriously lose mail.
On Jul 25, 2010, at 11:36 AM, Murray S. Kucherawy wrote:
> I've engaged some of you off-list trying to understand why ADSP is
> fundamentally different than the private agreements known to exist between
> PayPal and some large email service providers. I get the philosophical
> arguments, but f
On 7/26/10 6:24 PM, J.D. Falk wrote:
> I think it's because, when you implement most protocols, if your end is
> broken then you can't even talk to the other end. With ADSP, if your end is
> broken then you can still talk SMTP and even sign with DKIM, but the other
> end may silently discard yo
On 07/26/2010 09:24 AM, J.D. Falk wrote:
> On Jul 25, 2010, at 11:36 AM, Murray S. Kucherawy wrote:
>
>> I've engaged some of you off-list trying to understand why ADSP is
>> fundamentally different than the private agreements known to exist between
>> PayPal and some large email service provider
On Jul 26, 2010, at 9:13 PM, Douglas Otis wrote:
> A vouching service is unlikely to offer a fix either. How would a
> vouching service know better than the Author Domain?
They wouldn't, so a smart vouching service would be working WITH the author
domain to get it right. But that's a business
On 7/27/10 9:36 AM, J.D. Falk wrote:
> On Jul 26, 2010, at 9:13 PM, Douglas Otis wrote:
> > A vouching service is unlikely to offer a fix either. How would a
> > vouching service know better than the Author Domain?
>
> They wouldn't, so a smart vouching service would be working WITH the
> auth
On Jul 27, 2010, at 10:33 AM, Douglas Otis wrote:
> Companies are good at shooting themselves in the foot in respect to
> helping bad actors phish. (blush) The other foot injury involves their
> email being rejected or discarded. Unfortunately, these two goals are
> in conflict when making AD
>Mailing lists are a separate issue. I don't think it's helpful for a
>3rd party to vouch that lists are lists, and that's not what John's
>draft does.
The goal of my draft was to provide a way publish lists of domains for
which there is a net benefit to the recipient from dropping unsigned
mail.
On 7/27/10 5:35 PM, John Levine wrote:
>> Mailing lists are a separate issue. I don't think it's helpful for a
>> 3rd party to vouch that lists are lists, and that's not what John's
>> draft does.
>>
> The goal of my draft was to provide a way publish lists of domains for
> which there is a
> Your spec limits the use of the DBR to Author Domains... is there a
> compelling reason to not just let it apply to any domain?
I don't see the point of using it on other domains. Nobody expects the
signature to match anything else.
R's,
John
>
> Ellen
>
> On Tue, Jul 27, 2010 at 11:35 AM,
--On 26 July 2010 18:24:34 +0200 "J.D. Falk"
wrote:
>
> I think it's because, when you implement most protocols, if your end is
> broken then you can't even talk to the other end. With ADSP, if your end
> is broken then you can still talk SMTP and even sign with DKIM, but the
> other end may
On Jul 29, 2010, at 5:09 PM, Ian Eiloart wrote:
> --On 26 July 2010 18:24:34 +0200 "J.D. Falk"
> wrote:
>
>> I think it's because, when you implement most protocols, if your end is
>> broken then you can't even talk to the other end. With ADSP, if your end
>> is broken then you can still talk
On Jul 29, 2010, at 11:53 AM, J.D. Falk wrote:
> On Jul 29, 2010, at 5:09 PM, Ian Eiloart wrote:
>
>> --On 26 July 2010 18:24:34 +0200 "J.D. Falk"
>> wrote:
>>
>>> I think it's because, when you implement most protocols, if your end is
>>> broken then you can't even talk to the other end. Wi
On 07/29/2010 11:53 AM, J.D. Falk wrote:
> On Jul 29, 2010, at 5:09 PM, Ian Eiloart wrote:
>
>> --On 26 July 2010 18:24:34 +0200 "J.D. Falk"
>> wrote:
>>
>>> I think it's because, when you implement most protocols, if your end is
>>> broken then you can't even talk to the other end. With ADSP, i
--On 29 July 2010 20:53:40 +0200 "J.D. Falk"
wrote:
> On Jul 29, 2010, at 5:09 PM, Ian Eiloart wrote:
>
>> --On 26 July 2010 18:24:34 +0200 "J.D. Falk"
>> wrote:
>>
>>> I think it's because, when you implement most protocols, if your end is
>>> broken then you can't even talk to the other end
73 matches
Mail list logo
