Steve Atkins wrote:
> On Apr 29, 2008, at 3:30 AM, Eliot Lear wrote:
>
>
>>
>> Really? How about Section 1 of RFC 5016?
>>
>>
>
> It doesn't contain any operational justification or goal for
> SSP. It describes what (one person) wants from SSP, it
> does not explain why, and it definitely
Hi Dave,
Dave Crocker wrote:
>
> Jim Fenton wrote:
>> Dave Crocker wrote:
>>> I keep waiting for proponents of this 'feature' to solicit technical
>>> review from independent DNS and security experts, for assessing the
>>> likely benefit as balanced against the likely cost.
>> I have been soli
Eliot Lear wrote:
>
> and that which legitimately not be signed.
huh?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Steve Atkins wrote:
> And what's the actual operational goal for this?
>
> If you can't give me the general goal, a concrete example or
> two would be a good start.
>
The general goal is to discern that which isn't signed and should be
signed and that which legitimately not be signed. I think
Jim Fenton wrote:
> Dave Crocker wrote:
>> I keep waiting for proponents of this 'feature' to solicit technical
>> review from independent DNS and security experts, for assessing the
>> likely benefit as balanced against the likely cost.
>
> I have been soliciting technical review from the DNS
On Apr 29, 2008, at 8:36 AM, Eliot Lear wrote:
> Steve Atkins wrote:
>> It doesn't contain any operational justification or goal for
>> SSP. It describes what (one person) wants from SSP, it
>> does not explain why, and it definitely doesn't provide the
>> operational problem that SSP is intended
Steve Atkins wrote:
> It doesn't contain any operational justification or goal for
> SSP. It describes what (one person) wants from SSP, it
> does not explain why, and it definitely doesn't provide the
> operational problem that SSP is intended to mitigate.
>
Well, I really don't know where to
On Apr 29, 2008, at 3:30 AM, Eliot Lear wrote:
> Steve,
>> The answer to that depends on what the operational goal
>> of ADSP is. And that's never been clearly stated, really,
>> certainly not to the level of there being any consensus on it.
>>
>
> Really? How about Section 1 of RFC 5016?
>
It
Steve,
> The answer to that depends on what the operational goal
> of ADSP is. And that's never been clearly stated, really,
> certainly not to the level of there being any consensus on it.
>
Really? How about Section 1 of RFC 5016?
Eliot
___
NOTE
Al Iverson wrote:
>
> I don't grasp the technical bits to provide a coherent explanation of
> how to do what I want. But I have to say, without any sort of domain
> blanket/coverage option, it seems like something is really missing
> here. Without any sort of assumption or ability to limit what's
>
On Apr 28, 2008, at 10:48 AM, Al Iverson wrote:
> On Mon, Apr 28, 2008 at 12:02 PM, J D Falk <[EMAIL PROTECTED]>
> wrote:
>
>
>>> If I'm understanding the issues at hand. The thread is a bit
>>> difficult
>>> to follow.
>>
>> Yeah, I don't think there's much point in following it closely
>>
On Mon, Apr 28, 2008 at 12:02 PM, J D Falk <[EMAIL PROTECTED]> wrote:
> > If I'm understanding the issues at hand. The thread is a bit difficult
> > to follow.
>
> Yeah, I don't think there's much point in following it closely anymore.
> The really really smart people appear intractable, and
On Apr 28, 2008, at 9:02 AM, J D Falk wrote:
> Al wrote:
>
>> Without any sort of assumption or ability to limit what's allowed
>> under spamresource.com, I think ADSP is much less useful. My
>> concern is that if I can't restrict or cause failures automatically
>> outside of a specific sub
Al wrote:
> Without any sort of assumption or ability to limit what's allowed
under
> spamresource.com, I think ADSP is much less useful. My concern is that
> if I can't restrict or cause failures automatically outside of a
> specific subdomain or host, it does me little good to sign on
> signed.s
Al,
Al Iverson wrote:
> My
> concern is that if I can't restrict or cause failures automatically
> outside of a specific subdomain or host, it does me little good to
> sign on signed.spamresource.com when a phisher can fake
> signed2.spamresource.com and not automatically be failed by checking
On Mon, Apr 28, 2008 at 12:53 AM, Jim Fenton <[EMAIL PROTECTED]> wrote:
> >> Similar concerns led the WG to the use of TXT records rather than a
> >> new RR.
> >
> > Not really. The infrastructure barrier to support of a new RR exists
> > with both those who create the record as well as those
On Sat, 26 Apr 2008 02:54:36 +0100, Dave Crocker <[EMAIL PROTECTED]> wrote:
>> There are a lot of DNS management tools
>> out there that would need to change in order to publish the necessary
>> ADSP records, and this would take considerable time.
>
> They already need to change, to support o
Dave Crocker wrote:
> I keep waiting for proponents of this 'feature' to solicit technical
> review from independent DNS and security experts, for assessing the
> likely benefit as balanced against the likely cost.
I have been soliciting technical review from the DNS folks, literally,
for years
Douglas Otis wrote:
>
> On Apr 25, 2008, at 4:21 PM, Jim Fenton wrote:
>
>> The requirement to publish large numbers of ADSP records is a barrier
>> to its widespread adoption, at least its adoption in a way that
>> provides broad coverage for domains. This can be addressed with
>> tools, but t
Jim,
Jim Fenton wrote:
> It isn't productive to dismiss DNS administrators who are resistant to
> adding many ADSP records as "lazy", "hostile", and/or "incompetent". It
> makes it sound like they aren't worthy of using ADSP. But they are, as
> far as this protocol is concerned, our customers
On Apr 25, 2008, at 4:21 PM, Jim Fenton wrote:
> The requirement to publish large numbers of ADSP records is a
> barrier to its widespread adoption, at least its adoption in a way
> that provides broad coverage for domains. This can be addressed
> with tools, but the requirement to add too
John Levine wrote:
>
> Just so I'm sure I understand you, you're claiming that DNS managers
> are without exception so hostile and/or incompetent that they can not
> set up ADSP records for the A records they manage. That's not "would
> prefer not to", it's "can not". As JD pointed out a few w
> DNS administrators ...
> But they are, as far as this protocol is concerned, our customers.
No, they're not. They one of many suppliers to our customers. Our
customers are people who send and recieve mail.
> The requirement to publish large numbers of ADSP records is a barrier to its
> wid
Doug,
I'm a simple guy. I only have a few brain cells left at this point. A
little too much LDS in the '70s. Please. Smaller simpler sentences to
address my question, which was:
Douglas Otis wrote:
>
> On Apr 25, 2008, at 12:22 AM, Eliot Lear wrote:
>
>> Here's the question I wonder about h
On Apr 25, 2008, at 12:22 AM, Eliot Lear wrote:
> Here's the question I wonder about here: how do we follow as best we
> can the principle of least astonishment in this case?
Bad-actors run an overwhelming majority of SMTP clients. Each SMTP
set-up expediency, even under a guise of least as
> What I would say is that there are several situations that must be
> considered. In some instances, it has absolutely nothing to do with level of
> expertise of the administrator but the tools that he or she is using, that
> will need to be changed.
Indeed. But the tools are going to have t
John,
> Just so I'm sure I understand you, you're claiming that DNS managers are
> without exception so hostile and/or incompetent that they can not set up
> ADSP records for the A records they manage.
>
I don't think that's what Jim was saying, but I'm sure he can answer for
himself.
What
On Apr 24, 2008, at 11:23 AM, John Levine wrote:
>>> Really? Can you provide some examples of domains that use so many
>>> subdomains for mail that it's impractical to cover the ones they
>>> use individually? (Not counting wildcards, we know that's a
>>> swamp.) For the domains I know,
>> Really? Can you provide some examples of domains that use so many
>> subdomains for mail that it's impractical to cover the ones they use
>> individually? (Not counting wildcards, we know that's a swamp.) For
>> the domains I know, the mail comes from one or a handful of fixed
>> subdomains,
John Levine wrote:
>> OTOH, the converse is likely to be relevant to quite a lot of domains,
>> even if it does not apply to aol.com.
>>
>
> Really? Can you provide some examples of domains that use so many
> subdomains for mail that it's impractical to cover the ones they use
> individuall
Wietse Venema wrote:
> Wietse Venema wrote:
>
>> Frank Ellermann:
>>
>>> <[EMAIL PROTECTED]> wrote:
>>>
>>>
Would it be better if "error" were a specifically defined
result in addition to "unknown" / "all" / "discardable"?
>>> The fourth bullet in chapter 3.2
On Apr 22, 2008, at 2:42 AM, Charles Lindsey wrote:
> On Mon, 21 Apr 2008, Douglas Otis <[EMAIL PROTECTED]> wrote:
>>
>> The current ADSP algorithm establishes DKIM signing compliance by
>> qualifying From header email-address domains. This qualification
>> process ensures NXDOMAIN are not r
On Mon, 21 Apr 2008 18:45:53 +0100, Douglas Otis <[EMAIL PROTECTED]>
wrote:
> On Apr 19, 2008, at 11:36 AM, Charles Lindsey wrote:
>> DNS yes, but why SMTP? SMTP is not the problem. It is DNS that is
>> (possibly) a problem. DKIM already relies on DNS, so I see no reason
>> why ADSP should differ
On Apr 19, 2008, at 11:36 AM, Charles Lindsey wrote:
> On Thu, 17 Apr 2008 17:55:52 +0100, Douglas Otis <[EMAIL PROTECTED]
> abuse.org>
> wrote:
>>
>> A proprietary scheme is not recommended, but it is not be
>> unthinkable open source schemes might offer similar features, and
>> perhaps ove
On Thu, 17 Apr 2008 17:55:52 +0100, Douglas Otis <[EMAIL PROTECTED]>
wrote:
>
> A proprietary scheme is not recommended, but it is not be unthinkable
> open source schemes might offer similar features, and perhaps overcome
> some of DNS's security issues as well. Discussing naming service
> agil
On Apr 16, 2008, at 7:58 PM, Frank Ellermann wrote:
> Douglas Otis wrote:
>
>> RFC2822 specifies "Internet Domain".
>
> Yeah, good enough for ADSP. There is a note in 2822upd-06:
>
> | A liberal syntax for the domain portion of addr-spec is
> | given here. However, the domain portion contains a
Douglas Otis wrote:
> RFC2822 specifies "Internet Domain".
Yeah, good enough for ADSP. There is a note in 2822upd-06:
| A liberal syntax for the domain portion of addr-spec is
| given here. However, the domain portion contains addressing
| information specified by and used in other protocols (
On Apr 15, 2008, at 7:33 PM, Frank Ellermann wrote:
> Douglas Otis wrote:
>
>> This is still assuming use of DNS in conjunction with some future
>> transport.
>
> Yes, ADSP is published using DNS, and it's about "mail", the
> abstract says. ADSP flags in Fido nodelists for the purposes of
> Hi Ned,
> [EMAIL PROTECTED] wrote:
> > That said, I do have a data point to offer here.
> Interesting cases. Two questions - a lot of that sounds
> like stuff they did for intra-enterprise purposes that
> might not be visible in the external DNS or in emails
> that got sent "outside" - is that
> > Now, I have no idea what limits were placed on this capability by
> > provisioning
> > systems. What I do know is that several customers used this feature to
> > create
> > very large numbers of subdomains. (I know this because this particular usage
> > exposed several bugs.)
> >
> > Another
>departmental mail exchangers, but I doubt the admins for that domain will
>relish the task of creating ADSP reecords for each of them (machines can
>be added and removed on an almost daily basis).
I wouldn't relish it either, but I don't see why the preferences of
lazy DNS admins should be a
On Tue, 15 Apr 2008 19:07:53 +0100, John Levine <[EMAIL PROTECTED]> wrote:
> Really? Can you provide some examples of domains that use so many
> subdomains for mail that it's impractical to cover the ones they use
> individually? (Not counting wildcards, we know that's a swamp.) For
> the domai
Hi Ned,
[EMAIL PROTECTED] wrote:
> That said, I do have a data point to offer here.
Interesting cases. Two questions - a lot of that sounds
like stuff they did for intra-enterprise purposes that
might not be visible in the external DNS or in emails
that got sent "outside" - is that right or wro
> > OTOH, the converse is likely to be relevant to quite a lot of domains,
> > even if it does not apply to aol.com.
> Really? Can you provide some examples of domains that use so many
> subdomains for mail that it's impractical to cover the ones they use
> individually? (Not counting wildcards,
> Now, I have no idea what limits were placed on this capability by provisioning
> systems. What I do know is that several customers used this feature to create
> very large numbers of subdomains. (I know this because this particular usage
> exposed several bugs.)
>
> Another thing that's surprisin
This discussion about how to handle non existent domains should be relabeled
Schroedinger's ADSP
-Original Message-
From: [EMAIL PROTECTED] on behalf of Frank Ellermann
Sent: Tue 4/15/2008 6:36 PM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] protecting domains that don&#x
Douglas Otis wrote:
> This is still assuming use of DNS in conjunction with some
> future transport.
Yes, ADSP is published using DNS, and it's about "mail", the
abstract says. ADSP flags in Fido nodelists for the purposes
of Fidomail is not discussed in RFC 5016 (sorry, couldn't
resist after y
On Apr 15, 2008, at 3:36 PM, Frank Ellermann wrote:
> Douglas Otis wrote:
>
>> ADSP must either assume email-addresses within the From header are
>> suitable for use with SMTP, and then check for SMTP specific DNS
>> resource records, or require each domain to publish policy resource
>> rec
Douglas Otis wrote:
> ADSP must either assume email-addresses within the From header are
> suitable for use with SMTP, and then check for SMTP specific DNS
> resource records, or require each domain to publish policy resource
> records.
Don't think so, "domain does not exist" is general eno
On Apr 15, 2008, at 4:09 AM, Charles Lindsey wrote:
> On Mon, 14 Apr 2008 19:06:05 +0100, Douglas Otis <[EMAIL PROTECTED]
> abuse.org>
> wrote:
>
>> RFC 2822 does not depend upon SMTP as being the message exchange
>> protocol. In addition, future message exchange protocols may
>> depend upo
>OTOH, the converse is likely to be relevant to quite a lot of domains,
>even if it does not apply to aol.com.
Really? Can you provide some examples of domains that use so many
subdomains for mail that it's impractical to cover the ones they use
individually? (Not counting wildcards, we know t
On Mon, 14 Apr 2008 19:06:05 +0100, Douglas Otis <[EMAIL PROTECTED]>
wrote:
> RFC 2822 does not depend upon SMTP as being the message exchange
> protocol. In addition, future message exchange protocols may depend
> upon different address resolution protocols, such as PRNP. PPNP
> avoids any re
On Mon, 14 Apr 2008 21:52:43 +0100, John Levine <[EMAIL PROTECTED]> wrote:
> Two more observations: One is the assumption that mail from subdomains
> is somehow automatically equivalent to mail from the enclosing domain.
> I don't see any reason for this to be true. I have one opinion about
> mai
On Mon, 14 Apr 2008 18:58:19 +0100, <[EMAIL PROTECTED]> wrote:
>
>> To: ietf-dkim@mipassoc.org
>> Date: Mon, 14 Apr 2008 09:53:28 -0400
>> From: [EMAIL PROTECTED]
>> Subject: Re: [ietf-dkim] protecting domains that don't exist
>>
>> John Levine:
Wietse Venema wrote:
> Frank Ellermann:
>> <[EMAIL PROTECTED]> wrote:
>>
>>> Would it be better if "error" were a specifically defined
>>> result in addition to "unknown" / "all" / "discardable"?
>> The fourth bullet in chapter 3.2 "ASP results" offers "the
>> domain does not exist" after "unknown"
Dave Crocker wrote:
> I now can't tell whether the focus is on an NXDomain for the
> _adsp. string that is queried for ADSP, or the
> name to which it is associated.
For dom.example following draft-ietf-dkim-ssp-03#section-4.2.2:
1: dig -ttxt _adsp._domainkey.dom.example. : NXDOMAIN => try 2 +
>You're confusing "commercial" concerns about [anti-]spoofing with
>"engineering" concerns about what the DNS infrastructure can do.
Not really. I'm talking about what a DNS based system like ADSP can
do rather than what some other hypothetical super duper anti-badness
system might do.
>- Anothe
Sorry for being confused, but I now can't tell whether the focus is on an
NXDomain for the _adsp. string that is queried for ADSP, or the
name to which it is associated.
These are separate queries.
d/
Wietse Venema wrote:
> Frank Ellermann:
>> <[EMAIL PROTECTED]> wrote:
>>
>>> Would it be be
Frank Ellermann:
> <[EMAIL PROTECTED]> wrote:
>
> > Would it be better if "error" were a specifically defined
> > result in addition to "unknown" / "all" / "discardable"?
>
> The fourth bullet in chapter 3.2 "ASP results" offers "the
> domain does not exist" after "unknown"/"all"/"discardable".
>
On Apr 14, 2008, at 6:53 AM, Wietse Venema wrote:
> John Levine:
>>> As someone pointed out, you can interchange steps 1 and 2 in the
>>> specification, putting the existence check first. And then, of
>>> course, you can decide that the existence check is done outside
>>> ADSP. If the exi
<[EMAIL PROTECTED]> wrote:
> Would it be better if "error" were a specifically defined
> result in addition to "unknown" / "all" / "discardable"?
The fourth bullet in chapter 3.2 "ASP results" offers "the
domain does not exist" after "unknown"/"all"/"discardable".
I-D.kucherawy-sender-auth-heade
> To: ietf-dkim@mipassoc.org
> Date: Mon, 14 Apr 2008 09:53:28 -0400
> From: [EMAIL PROTECTED]
> Subject: Re: [ietf-dkim] protecting domains that don't exist
>
> John Levine:
> > > As someone pointed out, you can interchange steps 1 and 2 in the
> > > s
Wietse wrote:
> John Levine:
>>> As someone pointed out, you can interchange steps 1 and 2 in the
>>> specification, putting the existence check first. And then, of
>>> course, you can decide that the existence check is done outside
ADSP.
>>> If the existence check is removed, I would advocate p
John Levine:
> > As someone pointed out, you can interchange steps 1 and 2 in the
> > specification, putting the existence check first. And then, of course, you
> > can decide that the existence check is done outside ADSP. If the existence
> > check is removed, I would advocate putting in lang
John Levine wrote:
> That seems reasonable. My objection (and I think also Dave's) is not that
> it's a bad idea, but that it's not part of DKIM or ADSP.
>
Once upon a time in this organization we had no problem reiterating such
practices with a mind toward not having to keep the reader boun
On Fri, 2008-04-11 at 04:50 +, John Levine wrote:
> >that any reasonable "outsider" will look at a spec that doesn't allow
> >him to specify in one step (rather than hopefully-correctly attached to
> >every single zone entry now and through all future changes) "Acme Corp's
> >email is ALL sign
On Fri, 2008-04-11 at 23:42 -0400, John Levine wrote:
> The current optimization is useful IF you have a lot of first level
> subdomains AND you don't have any lower level subdomains AND you have
> hostile DNS managers who won't automate the process of creating the ADSP
> records. While I don'
At 09:10 12-04-2008, John Levine wrote:
>So the intention is clearly that the domains in addresses are supposed
>to exist, but I don't see it in a MUST sentence. I'll ask whether
>that's deliberate, or it was so obvious that they didn't think it was
>worth mentioning.
There is a presumption that
Jim Fenton wrote:
>> If ADSP can depend on a well-specified requirement for
>> checking for the existence of the domain, please indicate
>> where this is specified.
The current 2821bis draft says in sec 5:
Only resolvable, fully-qualified, domain names (FQDNs) are permitted
when domain name
Jim Fenton wrote:
> If ADSP can depend on a well-specified requirement for
> checking for the existence of the domain, please indicate
> where this is specified.
There is no requirement to check the existence of domains
in originator addresses. I *think* that 2822upd or 2821bis
require that ori
John Levine wrote:
> I said:
>>> The current version of ADSP has a one level tree walk that modestly
>>> decreases the number of records you have to add, in exchange for
>>> making every ADSP lookup more complicated.
>
> Jim said:
>> ... Whether the decrease in the number of records you have is m
John Levine wrote:
>> As someone pointed out, you can interchange steps 1 and 2 in the
>> specification, putting the existence check first. And then, of course, you
>> can decide that the existence check is done outside ADSP. If the existence
>> check is removed, I would advocate putting in
I said:
>> The current version of ADSP has a one level tree walk that modestly
>> decreases the number of records you have to add, in exchange for making
>> every ADSP lookup more complicated.
Jim said:
> ... Whether the decrease in the number of records you have is modest or
> not depends a lo
> It's called feature creep.
Hooey.
Really.
> It is also entirely outside the scope of this working group.
Substantiate this incredible claim or please stop making it. It's just
plain false.
> Really. It has nothing to do with DKIM and nothing to do with Author
> Domain *signing*.
We're t
Dave Crocker wrote:
>
>
> Jim Fenton wrote:
>> Arvel Hathcock wrote:
>>> > So what's the point of importing it into ADSP?
>>>
>>> The point is so we can make certain that those who aren't currently
>>> employing the practice will do so and to make sure that the practice
>>> gets itself into a st
Jim Fenton wrote:
> Arvel Hathcock wrote:
>> > So what's the point of importing it into ADSP?
>>
>> The point is so we can make certain that those who aren't currently
>> employing the practice will do so and to make sure that the practice
>> gets itself into a standards document from this bod
Arvel Hathcock wrote:
> > So what's the point of importing it into ADSP?
>
> The point is so we can make certain that those who aren't currently
> employing the practice will do so and to make sure that the practice
> gets itself into a standards document from this body so that we don't
> have
Dave Crocker wrote:
John Levine wrote:
Huh? The DNS doesn't provide any way to do anything to an entire zone
other than AXFR.
>
The only way to cover an entire zone with ADSP is to create an ADSP
tree parallel to all of the names in the zone, i.e. for every
John Levine wrote:
>
> The only way to cover an entire zone with ADSP is to create an ADSP
> tree parallel to all of the names in the zone, i.e. for every
> foo.bar.example.com put in a _adsp._domainkey.foo.bar.example.com. If
> the existing tree has any wildcards, you can't do it. The current
>
> The question that I haven't seen addressed directly
> is why it's so important to provide ADSP for domains
> that don't exist.
Eric explained it pretty well I thought. We need the NXDOMAIN check so
that use of arbitrarily selected host name don't immediately defeat ADSP.
> Mail filters o
Jim Fenton wrote:
> Before we get all wrapped up in a discussion about zones again, let me
> point out that the ADSP specification does not rely on zones at all,
> which I think you will agree is the proper treatment.
not in the current spec. right.
i took this sequence as some bud-nipping.
John Levine wrote:
> Huh? The DNS doesn't provide any way to do anything to an entire zone
> other than AXFR.
>
> The only way to cover an entire zone with ADSP is to create an ADSP
> tree parallel to all of the names in the zone, i.e. for every
Just to press this point about the DNS:
z
>that any reasonable "outsider" will look at a spec that doesn't allow
>him to specify in one step (rather than hopefully-correctly attached to
>every single zone entry now and through all future changes) "Acme Corp's
>email is ALL signed, or it's not ours" and wonder what the spec authors
>were th
83 matches
Mail list logo
