Dave Crocker wrote:
So effectively the issue has changed from whether 30 days notice
really is required to whether what is really only 3 is somehow
acceptable. (RFC2418, Section 3.1
And no, this isn't about being a stickler about the rules.
It's about being inclusive.
Yep...given the
Dear Chairs Dave,
Actually, you originally said January 3. Then we heard nothing about
the matter for a month. That was the last note I see posted on this
matter from your or Steve, with no resolution as to schedule:
I tend to agree with Dave on this one. To start with there was a lot
Back on December 11, Stephen Farrell wrote:
We're looking at scheduling 1 hour calls each Thursday
in Jan (i.e. 3rd, 10th, 17th, 24th and 31st) at 1700 UTC.
Dave Crocker wrote:
So effectively the issue has changed from whether 30 days notice
really is required to whether what is really
Jim Fenton wrote:
I penciled in the meetings when they were originally proposed, not
sure why this is a surprise to people. January
3 and 10 got cancelled for various reasons (proximity to the holidays
and lack of 30-day notice, I
think) but the rest are still there.
Could you recap the
Jim Fenton wrote:
Dave Crocker wrote:
So effectively the issue has changed from whether 30 days notice
really is required to whether what is really only 3 is somehow
acceptable. (RFC2418, Section 3.1
I penciled in the meetings when they were originally proposed, not sure
why this is a
Stephen Farrell said...
Sorry about the delay with this, Barry and I had problems syncing
up over the holiday and have only now gotten this done.
Stephen is being too kind. He had nothing to do with the delay; that's
down to me. And thanks, Stephen, for getting the list posted to the list.
Barry Leiba wrote:
Eliot has set us up for a conference call this Thursday, 17 Jan, as we'd
originally scheduled back in December (actually, we'd planned to start
on 10 Jan, but we didn't make that; see delay above). It'll go along
with a jabber meeting, for which we'll use the normal DKIM
On 2007-06-02 20:35, Dave Crocker wrote:
Eliot Lear wrote:
What I am more concerned about is the amount of
complexity in the system. Going through both TXT *and* SSP records
seems like a recipe for synchronization problems and other nasties that
we could best do without. And I could
On Jun 5, 2007, at 8:27 AM, J.D. Falk wrote:
On 2007-06-02 20:35, Dave Crocker wrote:
Eliot Lear wrote:
What I am more concerned about is the amount of
complexity in the system. Going through both TXT *and* SSP
records seems like a recipe for synchronization problems and
other
Jim Fenton wrote:
Hallam-Baker, Phillip wrote:
From: Jim Fenton [mailto:[EMAIL PROTECTED]
I'm not clear on what only do TXT means in this context --
do you mean a directly referenced TXT record or one retrieved
via an XPTR lookup or both?
The policy record is only expressed
Steve Atkins wrote:
I think that deploying a new RR isn't as trivial as has been claimed,
but having TXT and something else just won't work well.
Steve,
I see your point and concern.
If the WG is wanting a new RR, then my vote for a RR/TXT lookup order
was just the most logical strategy,
I don't see how I would end up in a situation where I attach a wildcard to a
policy that says all mail is signed. Since NOMAIL is out of scope it is
entirely acceptable to present the following options:
1) You can deploy DKIM policy for specific domain records using your existing
DNS server.
Hallam-Baker, Phillip wrote:
From: Jim Fenton [mailto:[EMAIL PROTECTED]
I'm not clear on what only do TXT means in this context --
do you mean a directly referenced TXT record or one retrieved
via an XPTR lookup or both?
The policy record is only expressed using TXT
The
On Jun 4, 2007, at 3:43 PM, Jim Fenton wrote:
Hallam-Baker, Phillip wrote:
The policy record is only expressed using TXT. The discovery
process being first look for TXT, if that is not find look for an
XPTR and if found a TXT of the XPTR node.
This is apparently the central issue
On Jun 1, 2007, at 7:30 PM, Arvel Hathcock wrote:
(2) SSP record type (TXT vs. something new). Only 4 messages in
discussion, mostly saying if you support TXT, don't bother with
anything else. Again, no clear consensus.
If a new RR can solve the wildcard issue and we feel that this is a
Steve Atkins wrote:
On Jun 1, 2007, at 7:30 PM, Arvel Hathcock wrote:
(2) SSP record type (TXT vs. something new). Only 4 messages in
discussion, mostly saying if you support TXT, don't bother with
anything else. Again, no clear consensus.
If a new RR can solve the wildcard issue and we
Greetings Arvel,
(2) SSP record type (TXT vs. something new). Only 4 messages in
discussion, mostly saying if you support TXT, don't bother with
anything else. Again, no clear consensus.
If a new RR can solve the wildcard issue and we feel that this is a
significant issue worth solving (or
Eliot Lear wrote:
Greetings Arvel,
(2) SSP record type (TXT vs. something new). Only 4 messages in
discussion, mostly saying if you support TXT, don't bother with
anything else. Again, no clear consensus.
If a new RR can solve the wildcard issue and we feel that this is a
significant issue
On Friday 01 June 2007 22:30, Arvel Hathcock wrote:
(2) SSP record type (TXT vs. something new). Only 4
messages in discussion, mostly saying if you support
TXT, don't bother with anything else. Again, no
clear consensus.
If a new RR can solve the wildcard issue and we feel that this is
On Jun 2, 2007, at 1:04 AM, Hector Santos wrote:
Steve Atkins wrote:
On Jun 1, 2007, at 7:30 PM, Arvel Hathcock wrote:
(2) SSP record type (TXT vs. something new). Only 4 messages in
discussion, mostly saying if you support TXT, don't bother with
anything else. Again, no clear consensus.
On Saturday 02 June 2007 12:27, Steve Atkins wrote:
So if the spec states SSP clients must query for new RR first, then
TXT you wouldn't expect most receivers to comply with that?
Eventually, if the new RR type gets some deployment.
Scott K
___
NOTE
On Sat, 2007-06-02 at 12:40 -0400, Scott Kitterman wrote:
On Saturday 02 June 2007 12:27, Steve Atkins wrote:
So if the spec states SSP clients must query for new RR first, then
TXT you wouldn't expect most receivers to comply with that?
Eventually, if the new RR type gets some
On Jun 2, 2007, at 9:40 AM, Scott Kitterman wrote:
On Saturday 02 June 2007 12:27, Steve Atkins wrote:
So if the spec states SSP clients must query for new RR first, then
TXT you wouldn't expect most receivers to comply with that?
Eventually, if the new RR type gets some deployment.
The
On Saturday 02 June 2007 12:54, Douglas Otis wrote:
On Sat, 2007-06-02 at 12:40 -0400, Scott Kitterman wrote:
On Saturday 02 June 2007 12:27, Steve Atkins wrote:
So if the spec states SSP clients must query for new RR first, then
TXT you wouldn't expect most receivers to comply with that?
On Saturday 02 June 2007 13:02, Steve Atkins wrote:
On Jun 2, 2007, at 9:40 AM, Scott Kitterman wrote:
On Saturday 02 June 2007 12:27, Steve Atkins wrote:
So if the spec states SSP clients must query for new RR first, then
TXT you wouldn't expect most receivers to comply with that?
On Jun 2, 2007, at 10:31 AM, Scott Kitterman wrote:
On Saturday 02 June 2007 13:02, Steve Atkins wrote:
On Jun 2, 2007, at 9:40 AM, Scott Kitterman wrote:
On Saturday 02 June 2007 12:27, Steve Atkins wrote:
So if the spec states SSP clients must query for new RR first,
then
TXT you
Eliot Lear wrote:
What I am more concerned about is the amount of
complexity in the system. Going through both TXT *and* SSP records
seems like a recipe for synchronization problems and other nasties that
we could best do without. And I could easily be convinced by Peter Koch
that
On Jun 2, 2007, at 2:37 PM, John Levine wrote:
As an aside, I don't believe there's anything that prevents use
of TXT records, as currently specced, with wildcards, other than
lack of support in the more widely used nameservers.
It depends on what your plan for using TXT records is. If
On Sat, 2007-06-02 at 14:51 -0700, Steve Atkins wrote:
On Jun 2, 2007, at 2:37 PM, John Levine wrote:
We've gone around this enough times that I think that if there were a
reasonable way to do wildcards with TXT records, we'd have stumbled
across it by now.
If you exclude fix the
From: Jim Fenton [mailto:[EMAIL PROTECTED]
Hallam-Baker, Phillip wrote:
[mailto:[EMAIL PROTECTED] On Behalf Of Jim Fenton
(2) SSP record type (TXT vs. something new). Only 4 messages in
discussion, mostly saying if you support TXT, don't bother with
anything else. Again, no
Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Arvel Hathcock
Sent: Friday, June 01, 2007 10:30 PM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] SSP issues
(2) SSP record type (TXT vs. something new). Only 4 messages in
discussion, mostly saying if you
PROTECTED] On Behalf Of Eliot Lear
Sent: Saturday, June 02, 2007 9:51 AM
To: Hector Santos
Cc: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] SSP issues
Hi Hector,
How will my Mr. Koch assure the world that new RR record
queries will
be reliable? that all new RR queries
Hi Jim,
Barry and I would like us to do the following:
Continue the discussion on the list for a few more days since
not all the usual suspects have reacted yet (please do!) and
the context is slightly different (with XPTR anyway) from the
(many;-) other times we've discussed these topics in
Works for me. Actually, due to vacation schedules, I need to accelerate
that a bit and get the draft submitted by June 15.
So, WG participants (especially the 'usual suspects'), let's hear from you.
-Jim
Stephen Farrell wrote:
Hi Jim,
Barry and I would like us to do the following:
(2) SSP record type (TXT vs. something new). Only 4
messages in discussion, mostly saying if you support
TXT, don't bother with anything else. Again, no
clear consensus.
If a new RR can solve the wildcard issue and we feel that this is a significant
issue worth solving (or at least
Arvel Hathcock wrote:
(2) SSP record type (TXT vs. something new). Only 4 messages in
discussion, mostly saying if you support TXT, don't bother with
anything else. Again, no clear consensus.
If a new RR can solve the wildcard issue and we feel that this is a
significant issue worth solving
Douglas Otis [EMAIL PROTECTED] writes:
The concept is to provide a text file in some standardized format
listing the domain to be avoided. An announcement might be made that
a change occurred to prompt administrators to update their
configurations based upon this list. I would not expect
[mailto:[EMAIL PROTECTED] On Behalf Of Jim Fenton
What we had hoped to do in the next revision of the
allman-ssp draft was to unify it as much as possible with
Phill Hallam-Baker's draft. I opened three new issues on
April 16 that I think need to be resolved in order to do that.
(1)
william(at)elan.net wrote:
On Wed, 30 May 2007, Jim Fenton wrote:
(3) Upward query vs. wildcard publication. 27 messages in discussion
from 15 people. Most of the discussion was a rehash of the idea of
associating semantics with DNS zone-cuts, which we had already
discussed and rejected.
Hallam-Baker, Phillip wrote:
[mailto:[EMAIL PROTECTED] On Behalf Of Jim Fenton
(2) SSP record type (TXT vs. something new). Only 4 messages
in discussion, mostly saying if you support TXT, don't
bother with anything else. Again, no clear consensus.
I see no value in an SSP
WG
Subject: Re: [ietf-dkim] SSP issues
Hallam-Baker, Phillip wrote:
[mailto:[EMAIL PROTECTED] On Behalf Of Jim Fenton
(2) SSP record type (TXT vs. something new). Only 4 messages
in discussion, mostly saying if you support TXT, don't
bother with anything else. Again, no clear consensus
Fenton
Sent: Thursday, May 31, 2007 10:26 AM
To: Hallam-Baker, Phillip
Cc: IETF DKIM WG
Subject: Re: [ietf-dkim] SSP issues
Hallam-Baker, Phillip wrote:
[mailto:[EMAIL PROTECTED] On Behalf Of Jim Fenton
(2) SSP record type (TXT vs. something new). Only 4 messages
in discussion
PROTECTED]
Sent: Thursday, May 31, 2007 1:35 PM
To: Oxley, Bill (CCI-Atlanta)
Cc: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] SSP issues
The problem is that the default needs to be I do send mail, and I
don't sign everything, since that is the current situation. In other
words, the lack of an SSP
Scott Kitterman wrote:
On Wednesday 30 May 2007 18:22, Jim Fenton wrote:
(2) SSP record type (TXT vs. something new). Only 4 messages in discussion,
mostly saying if you support TXT, don't bother with anything else.
Again, no clear consensus.
Agreed. There is also a view that if you go
On Wed, 30 May 2007, Jim Fenton wrote:
What we had hoped to do in the next revision of the allman-ssp draft was to
unify it as much as possible with Phill Hallam-Baker's draft. I opened three
new issues on April 16 that I think need to be resolved in order to do that.
(1) Use of XPTR
On May 30, 2007, at 4:54 PM, william(at)elan.net wrote:
(3) Upward query vs. wildcard publication. 27 messages in
discussion from 15 people. Most of the discussion was a rehash of
the idea of associating semantics with DNS zone-cuts, which we had
already discussed and rejected. I
On Wed, 30 May 2007 15:52:17 -0700 Michael Thomas [EMAIL PROTECTED] wrote:
Scott Kitterman wrote:
On Wednesday 30 May 2007 18:22, Jim Fenton wrote:
(2) SSP record type (TXT vs. something new). Only 4 messages in
discussion,
mostly saying if you support TXT, don't bother with anything else.
On Wed, 30 May 2007, Douglas Otis wrote:
On May 30, 2007, at 4:54 PM, william(at)elan.net wrote:
(3) Upward query vs. wildcard publication. 27 messages in discussion
from 15 people. Most of the discussion was a rehash of the idea of
associating semantics with DNS zone-cuts, which we had
Scott Kitterman wrote:
On Wed, 30 May 2007 15:52:17 -0700 Michael Thomas [EMAIL PROTECTED] wrote:
I have a lot of sympathy for this point of view, but something
also to consider here is that there is a relatively small, but
motivated set up of people who would like to use SSP as early
adopters.
On May 30, 2007, at 5:25 PM, william(at)elan.net wrote:
On Wed, 30 May 2007, Douglas Otis wrote:
I would be happy to help co-author a draft that establishes a list
of current domains levels used by registries which should be
excluded from queries for DKIM related records.
That's not the
Scott Kitterman wrote:
On Wednesday 30 May 2007 18:22, Jim Fenton wrote:
(2) SSP record type (TXT vs. something new). Only 4 messages in discussion,
mostly saying if you support TXT, don't bother with anything else.
Again, no clear consensus.
Agreed. There is also a view that if you go
On May 30, 2007, at 6:16 PM, Hector Santos wrote:
Scott Kitterman wrote:
On Wednesday 30 May 2007 18:22, Jim Fenton wrote:
(2) SSP record type (TXT vs. something new). Only 4 messages in
discussion,
mostly saying if you support TXT, don't bother with anything
else. Again, no clear
Super dumb question: Can we change the model around from a default does
send to a default does not send?
Just as you have an MX to indicate you do accept mail (modulo the historical
A mess), perhaps you have an SSP to say you do send authenticated mail with
the default being unauthenticated
You're questioning the transition issues. I'm asking where do we want to end
up. I'm suggesting that SSP should be designed for our end-goal.
This is the Internet -- the transition will never be over, so something
that only works after the transition won't happen.
My strawman is that our
54 matches
Mail list logo