On May 27, 2008, at 8:09 AM, Frank Ellermann wrote:
> While we're busy renaming ADSP results, could anybody here explain
> the idea of "all" vs. "discardable" ? I don't see the difference.
The otis-dkim-adsp draft modified the terms from
unknown/all/discardable
to
OPEN/CLOSED/LOCKED
"unkn
On May 27, 2008, at 11:20 AM, Eliot Lear wrote:
> Dave Crocker wrote:
>> ... New insight, changed conditions, or the like.
>> What has changed, Eliot?
>
> John (and others - to be fair) have repeatedly mischaracterized as a
> tree walk a parent lookup. The two are very different.
Inducing tr
Dave Crocker wrote:
> ... New insight, changed conditions, or the like.
>
> What has changed, Eliot?
>
> d/
>
John (and others - to be fair) have repeatedly mischaracterized as a
tree walk a parent lookup. The two are very different. It is clear to
me that confusion has ensued over precisely
Steve Atkins wrote:
> On May 27, 2008, at 2:16 AM, Eliot Lear wrote:
>
>
>> - sorry - subject line error on my part (that's the only change).
>>
>> Eliot Lear wrote:
>>
>>> In order for ADSP to be of use, it must be easily deployable by
>>> enterprises and service providers. Otherwise, the
On May 27, 2008, at 6:01 AM, <[EMAIL PROTECTED]> wrote:
> I am imperfectly signing messages with DKIM that I am sending via my
> home machine on a dhcp address purported to be from
> bill.oxley.home.com a vanity non existent domain. According to DKIM
> that message is to be treated as unsig
I am imperfectly signing messages with DKIM that I am sending via my home
machine on a dhcp address purported to be from bill.oxley.home.com a vanity non
existent domain. According to DKIM that message is to be treated as unsigned,
why do you wish to drop it?
Thanks,
Bill Oxley
-Original Me
On May 27, 2008, at 2:16 AM, Eliot Lear wrote:
> - sorry - subject line error on my part (that's the only change).
>
> Eliot Lear wrote:
>> In order for ADSP to be of use, it must be easily deployable by
>> enterprises and service providers. Otherwise, there is no point in
>> bothering to check
Tony Finch wrote:
>> It's also the definition of result "nxdomain" in Murray's draft,
>> if you want "nomailfqdn" (or a similar name), where NXDOMAIN is
>> only a proper subset, it's okay.
> What's the filename of that draft?
http://tools.ietf.org/html/draft-kucherawy-sender-auth-header-14#sect
Eliot Lear wrote:
> John Levine wrote:
>> In any event, the tree walk is gone. We voted, your side lost.
>> Enough already.
>
> We voted on a misconception you perpetuated. We never had a tree walk.
> The "vote" leaves the protocol undeployable.
Eliot,
This is both ad hominem and disrup
On Tue, May 27, 2008 at 10:36 AM, Dave Crocker <[EMAIL PROTECTED]> wrote:
>
>
> Eliot Lear wrote:
>> The problem is when there are hundreds or thousands of hosts beneath
>> example.com. How many commercial DNS management systems can handle that
>> from a provisioning point of view?
>
>
> All.
>
>
On Tue, 27 May 2008, Frank Ellermann wrote:
>
> It's also the definition of result "nxdomain" in Murray's draft,
> if you want "nomailfqdn" (or a similar name), where NXDOMAIN is
> only a proper subset, it's okay.
What's the filename of that draft?
None of the drafts I have read defines symbolic
Frank Ellermann wrote:
> There was a poll about this recently, and while I don't believe
> in voting for technical standards (outside of IESG ballots) I do
> believe in "closed issue until new arguments are posted".
>
>
The result of that poll has opened up a dependency against DNS
managemen
Dave Crocker wrote:
>
> All.
>
> How else did they register those names and populate them with records?
>
They got there with commercial DNS management systems. Those systems
are incredibly slow to change. Go read
draft-iab-protocol-success-03.txt Section 2.1.1 bullet 2. While some
DNS manag
John Levine wrote:
> In any event, the tree walk is gone. We voted, your side lost.
> Enough already.
We voted on a misconception you perpetuated. We never had a tree walk.
The "vote" leaves the protocol undeployable.
Eliot
___
NOTE WELL: This lis
Eliot Lear wrote:
> It's [EMAIL PROTECTED] - where
> "your-representative" is actually your representative. We can
> and should protect from that.
We can't because it won't work for s/bank.com/co.uk/ and similar
cases, where the parent domain is a different zone. Read "zone"
where John wrote "
Eliot Lear wrote:
> The problem is when there are hundreds or thousands of hosts beneath
> example.com. How many commercial DNS management systems can handle that
> from a provisioning point of view?
All.
How else did they register those names and populate them with records?
d/
--
Dav
>> You're just reasserting the same implausible claim. This is part of the
>> lookalike problem, and no amount of ADSP will solve that.
>
> And you're arguing that ADSP should solve everything,
It's not helpful to attribute statements to people that they didn't say.
What I did say is that ADSP
John Levine wrote:
> Man, this horse still isn't dead.
>
>> First of all, this is a gross mischaracterization of what was in the
>> document. It was NEVER a tree walk
>
> It was a one level tree walk, but it's gone now, never to return, so
> that hardly matters.
>
>>> Although I believe that the
Man, this horse still isn't dead.
> First of all, this is a gross mischaracterization of what was in the
> document. It was NEVER a tree walk
It was a one level tree walk, but it's gone now, never to return, so that
hardly matters.
>> Although I believe that there is at least one large vendor
Tony Finch wrote:
>> Why not simply reject "bogusmx", and don't bother to check ADSP ?
> You seem to be arguing that if an implementer thinks the NXDOMAIN
> check is too weak, then they should use whatever validity check
> they think is suitable.
Yes, but of course ADSP implementations should
Frank Ellermann wrote:
> After excluding rare wildcard / implicit MX cases what's left might be
> hundreds or thousands of hosts with MX records. Somehow they got the
> MX records, and a similar tool can add ADSP records to non-wildcard MX
> records.
That itself is a dependency. The dependency
John Levine wrote:
>
> a) Even if you believe this is a serious issue (which I don't, see
> point 2 below), the tree walk wouldn't be a solution.
First of all, this is a gross mischaracterization of what was in the
document. It was NEVER a tree walk, and I have said this before. I
would like
> The absence of a parent label check will mean that enterprises must
> list an ADSP record for each and every DNS entry they have.
Man, this horse just won't stay dead.
a) Even if you believe this is a serious issue (which I don't, see
point 2 below), the tree walk wouldn't be a solution. Altho
On Tue, 27 May 2008, Frank Ellermann wrote:
>
> I'm not sure about your statement. Of course receivers can check
> whatever they like. They just have no business to say "nxdomain"
> when they got "nullmx", "SPF FAIL", or anything else that is not
> the same as "nxdomain".
>
> > I am talking about
Eliot Lear wrote:
> The problem is when there are hundreds or thousands of hosts beneath
> example.com. How many commercial DNS management systems can handle
> that from a provisioning point of view?
After excluding rare wildcard / implicit MX cases what's left might be
hundreds or thousands of
Tony Finch wrote:
> You seem to be repeating my point that if the spec requires an
> NXDOMAIN check then an implementation cannot be stricter if it
> wishes.
I'm not sure about your statement. Of course receivers can check
whatever they like. They just have no business to say "nxdomain"
when th
Frank Ellermann wrote:
> Eliot Lear wrote:
>
>
>> an author domain administrator cannot adequately or easily express
>> the simple notion that only certain hosts are authorized to send
>> from a domain. We have thus missed the mark on what we are doing.
>>
>
> IMO "we" (TINW) are *not* rei
Eliot Lear wrote:
> an author domain administrator cannot adequately or easily express
> the simple notion that only certain hosts are authorized to send
> from a domain. We have thus missed the mark on what we are doing.
IMO "we" (TINW) are *not* reinventing SPF (or PRA a.k.a. Sender ID).
The
Frank Ellermann wrote:
> Eliot Lear wrote:
>
>
>> The absence of a parent label check will mean that enterprises
>> must list an ADSP record for each and every DNS entry they have.
>>
>
> If they wish to publish "signing practises" they can focus on
> domains actually used as "author doma
On Tue, 27 May 2008, Frank Ellermann wrote:
> Tony Finch wrote:
>
> > I think the specification should not prevent implementations
> > from using more thorough verification if they choose
>
> For an ADSP result "nxdomain" they can't do whatever they like
> better, e.g., "call back verification" mig
Eliot Lear wrote:
> The absence of a parent label check will mean that enterprises
> must list an ADSP record for each and every DNS entry they have.
If they wish to publish "signing practises" they can focus on
domains actually used as "author domain", for a stupid example,
they likely don't ne
- sorry - subject line error on my part (that's the only change).
Eliot Lear wrote:
> In order for ADSP to be of use, it must be easily deployable by
> enterprises and service providers. Otherwise, there is no point in
> bothering to check for answers. The absence of a parent label check
> wi
In order for ADSP to be of use, it must be easily deployable by
enterprises and service providers. Otherwise, there is no point in
bothering to check for answers. The absence of a parent label check
will mean that enterprises must list an ADSP record for each and every
DNS entry they have.
Tony Finch wrote:
> I think the specification should not prevent implementations
> from using more thorough verification if they choose
For an ADSP result "nxdomain" they can't do whatever they like
better, e.g., "call back verification" might work, but it's not
the same as "nxdomain".
> usin
On May 26, 2008, at 3:26 AM, Charles Lindsey wrote:
> On Sun, 25 May 2008 21:53:11 +0100, Douglas Otis <[EMAIL PROTECTED]
> abuse.org>
> wrote:
>
>> Such testing is not mission creep. The test is simply based upon
>> SMTP being the focus of ADSP assertions.
>
> But SMTP IS NOT, and CANNOT BE
On May 26, 2008, at 3:18 AM, Charles Lindsey wrote:
> On Sat, 24 May 2008 22:26:34 +0100, Douglas Otis <[EMAIL PROTECTED]
> abuse.org>
> wrote:
>
>> This draft also avoids restrictions on the DKIM identity
>> parameters, since the _only_ relevant issue is whether a message
>> should be signe
36 matches
Mail list logo
