Dear SM,
See comments inline.
On Sep 16, 2013, at 9:00 AM, S Moonesamy sm+i...@elandsys.com wrote:
Hi Doug,
At 21:55 11-09-2013, Douglas Otis wrote:
Add to:
11.5.3. Macro Expansion
,---
It is not within SPF's purview whether IPv6 or DNSSEC is being used. IPv6
(RFC2460) increased the
Hi Doug,
At 21:55 11-09-2013, Douglas Otis wrote:
Add to:
11.5.3. Macro Expansion
,---
It is not within SPF's purview whether IPv6 or DNSSEC is being
used. IPv6 (RFC2460) increased the minimum MTU size to 1280
octets. DNSSEC is deployed with EDNS0 (RFC6891) to avoid TCP
fallback. EDNS0
Hi Doug,
At 21:55 11-09-2013, Douglas Otis wrote:
Recommended text is as follows:
Thanks for suggesting text. I'll take this up with the SPFBIS WG
after the (IESG) DISCUSSes have been addressed.
Here are some quick comments. Section 4.6.4 was reviewed again in
response to the DISCUSS
Recommended text is as follows:
4.6.4. DNS Lookup Limits
Was:
,--
SPF implementations MUST limit the total number of mechanisms and modifiers
(terms) that cause any DNS query to 10 during SPF evaluation. Specifically,
the include, a, mx, ptr, and exists mechanisms as well as the
redirect
On Sep 2, 2013, at 5:54 AM, Phillip Hallam-Baker hal...@gmail.com wrote:
On Thu, Aug 29, 2013 at 12:30 PM, Dan Schlitt schl...@theworld.com wrote:
As the manager of a modestly large network I found the TXT record as a useful
tool in management of the network. Such a use was even suggested by
Hello,
This is a rough summary of the comments which
have been made on the Last Call for
draft-ietf-spfbis-4408bis-19 since I emailed Pete Resnick [1].
There were comments about the RFC 5507 concerns
from Patrik Fältström [2], Dave Crocker [3], Mark
Andrews [4] and John Klensin [5].
On Thu, Aug 29, 2013 at 12:30 PM, Dan Schlitt schl...@theworld.com wrote:
As the manager of a modestly large network I found the TXT record as a
useful tool in management of the network. Such a use was even suggested by
other system managers. That was a time when the Internet was a friendlier
The engineering solution to this deployment problem is to generalize the
problem and use a new record for that.
Either that or figure out how to make it easy enough to deploy new
RRTYPEs that people are willing to do so.
The type number is 16 bits, after all. We're not in any danger of running
John,
Either that or figure out how to make it easy enough to deploy new
RRTYPEs that people are willing to do so.
The type number is 16 bits, after all. We're not in any danger of running
out.
We have been told on numerous occasions that one of the primary reasons for
continued use of
On Mon, Sep 2, 2013 at 9:56 AM, David Conrad d...@virtualized.org wrote:
John,
Either that or figure out how to make it easy enough to deploy new
RRTYPEs that people are willing to do so.
The type number is 16 bits, after all. We're not in any danger of
running out.
We have been
I did not participate in the original working group that developed SPF.
However I had a number of long phone conversations with one of the folks
who was active in the group. A good part of those conversations involved
the use of the TXT record. I objected to overloading that RR. In
response
--On Wednesday, August 28, 2013 07:21 -0700 Dave Crocker
d...@dcrocker.net wrote:
RFC 5507 primarily raises three concerns about TXT records:
RFC 5507 is irrelevant to consideration of the SPFbis draft.
Really.
RFC 5507 concerns approaches to design. However the SPFbis
draft is not
On 8/29/2013 9:31 AM, John C Klensin wrote:
I may be violating my promise to myself to stay out of
SPF-specific issues,
Probably not, since your note has little to do with the realities of the
SPFbis draft, which is a chartered working group product. You might
want to review its charter:
--On Thursday, August 29, 2013 12:28 -0700 Dave Crocker
d...@dcrocker.net wrote:
On 8/29/2013 9:31 AM, John C Klensin wrote:
I may be violating my promise to myself to stay out of
SPF-specific issues,
Probably not, since your note has little to do with the
realities of the SPFbis
On Thu, Aug 29, 2013 at 12:31 PM, John C Klensin john-i...@jck.com wrote:
--On Wednesday, August 28, 2013 07:21 -0700 Dave Crocker
d...@dcrocker.net wrote:
RFC 5507 primarily raises three concerns about TXT records:
RFC 5507 is irrelevant to consideration of the SPFbis draft.
Hello,
It's difficult, some might say impossible, to get agreement on
draft-ietf-spfbis-4408bis. I would like to ask each of you, and
anyone else, to provide your opinion about the following:
RFC 5507 primarily raises three concerns about TXT records:
1. The data in TXT is unstructured
On 28 aug 2013, at 14:24, S Moonesamy sm+i...@elandsys.com wrote:
It's difficult, some might say impossible, to get agreement on
draft-ietf-spfbis-4408bis. I would like to ask each of you, and anyone else,
to provide your opinion about the following:
RFC 5507 primarily raises three
On 8/28/2013 5:24 AM, S Moonesamy wrote:
It's difficult, some might say impossible, to get agreement on
draft-ietf-spfbis-4408bis. I would like to ask each of you, and anyone
else, to provide your opinion about the following:
RFC 5507 primarily raises three concerns about TXT records:
RFC
On Wednesday, August 28, 2013 07:21:13 Dave Crocker wrote:
On 8/28/2013 5:24 AM, S Moonesamy wrote:
It's difficult, some might say impossible, to get agreement on
draft-ietf-spfbis-4408bis. I would like to ask each of you, and anyone
else, to provide your opinion about the following:
In message 6.2.5.6.2.20130828044224.06ee3...@resistor.net, S Moonesamy writes
:
Hello,
It's difficult, some might say impossible, to get agreement on
draft-ietf-spfbis-4408bis. I would like to ask each of you, and
anyone else, to provide your opinion about the following:
RFC 5507
--On Monday, August 26, 2013 10:49 -0400 John R Levine
jo...@taugh.com wrote:
Sorry if that last one came across as dismissive.
Until such time, I'd personally prefer to see some explicit
notion that the odd history of the SPF TXT record should not
be seen as a precedent and best
On 2013-08-26, at 22:28, S Moonesamy sm+i...@elandsys.com wrote:
The permitted size of the UDP packet is NOT 512 octets. That is the
permitted size of the DNS Message. DNS Message is not the same thing as a
UDP packet.
Per RFC1035
Section 2.3.4. Size limits
UDP messages512 octets
Hi Joe,
At 08:59 27-08-2013, Joe Abley wrote:
The consistent word for this in 1035 is simply message. DNS
Message is in more common use today, I would say.
The text you quoted from 1035 is most usefully interpreted as a
contraction of messages sent over UDP; UDP message really
doesn't have a
I probably should have sent out this message over the weekend, but I was
hoping I would complete a bigger message soon. Since I'm still working
on that, a quick note to level set:
I have been reading all of the Last Call responses as they have come in.
I am in the process of reviewing the
On 08/23/2013 04:34 PM, John Levine wrote:
I don't know of any (at least ones that are used in the global dns
namespace), and I would like to still not know of any in 2033.
Since we agree that the issue you're worried about has not arisen even
once in the past decade, could you clarify
prevented, not solved. I would like to prevent someone from having to
submit a draft specifying that in the case of TXT, the (name, class,
type)-tuple should be extended with the first X octets from the RDATA
fields, somewhere in the future, because client-side demuxing is getting
too buggy and
On 08/26/2013 04:08 PM, John R Levine wrote:
Could you point to anyone, anywhere, who has ever said that the odd
history of the SPF TXT record means that it is perfectly fine to do
something similar in the future?
Three of the four points on the list that triggered my first message in
this
Sorry if that last one came across as dismissive.
Until such time, I'd personally prefer to see some explicit notion that
the odd history of the SPF TXT record should not be seen as a precedent
and best practice, rather than hope that this is implicit.
I'd have thought that the debate here
On 08/26/2013 04:49 PM, John R Levine wrote:
Sorry if that last one came across as dismissive.
Until such time, I'd personally prefer to see some explicit notion that
the odd history of the SPF TXT record should not be seen as a precedent
and best practice, rather than hope that this is
On 08/26/2013 04:55 PM, Jelte Jansen wrote:
I'd have thought that the debate here and elsewhere already documented
that. Since it's not specific to SPF, perhaps we could do a draft on
overloaded TXT considered harmful to get it into the RFC record.
That draft may not be a bad idea.
It
On Aug 24, 2013, at 3:16 AM, S Moonesamy sm+i...@elandsys.com wrote:
Hi Doug,
At 13:07 23-08-2013, Douglas Otis wrote:
The SPFbis document improperly conflates DNS terminology with identical
terms invented by this document. Examples are terms used to describe
mechanisms having the same
On Monday, August 26, 2013 15:42:41 Douglas Otis wrote:
Please also note that the PTR RR is not constrained in the current
specification and can create erratic results. It would be far safer to
Perm error when overflowing on the number of PTR records. There is no
upper limit as some
On Aug 26, 2013, at 3:48 PM, Scott Kitterman sc...@kitterman.com wrote:
On Monday, August 26, 2013 15:42:41 Douglas Otis wrote:
Please also note that the PTR RR is not constrained in the current
specification and can create erratic results. It would be far safer to
Perm error when
On Monday, August 26, 2013 16:28:03 Douglas Otis wrote:
On Aug 26, 2013, at 3:48 PM, Scott Kitterman sc...@kitterman.com wrote:
On Monday, August 26, 2013 15:42:41 Douglas Otis wrote:
Please also note that the PTR RR is not constrained in the current
specification and can create erratic
On Aug 26, 2013, at 4:29 PM, Scott Kitterman sc...@kitterman.com wrote:
On Monday, August 26, 2013 16:28:03 Douglas Otis wrote:
On Aug 26, 2013, at 3:48 PM, Scott Kitterman sc...@kitterman.com wrote:
On Monday, August 26, 2013 15:42:41 Douglas Otis wrote:
Please also note that the PTR RR is
Douglas Otis doug.mtv...@gmail.com wrote:
On Aug 26, 2013, at 4:29 PM, Scott Kitterman sc...@kitterman.com
wrote:
On Monday, August 26, 2013 16:28:03 Douglas Otis wrote:
On Aug 26, 2013, at 3:48 PM, Scott Kitterman sc...@kitterman.com
wrote:
On Monday, August 26, 2013 15:42:41 Douglas Otis
Hi Doug,
At 15:42 26-08-2013, Douglas Otis wrote:
When the SPF document refers to Sender Policy Framework (SPF)
records or SPF records this conflicts with DNS's record
definition. It is wrong to refer to these as records. RFC1034
defines resource records as TTL and RDATA that is selected by
I experienced rude respondings in IETF list and in one WG list, I don't
beleive that it is culture of IETF participants, but it seems that some
people should understand to be polite and reasonable in such organisation
business. Finally, the rude responding is not controled by the chair of
thoes
Hi Doug,
At 13:07 23-08-2013, Douglas Otis wrote:
The SPFbis document improperly conflates DNS terminology with
identical terms invented by this document. Examples are terms used
to describe mechanisms having the same identifier differentiated
between mechanisms and DNS resource records by
On 08/22/2013 07:18 PM, John Levine wrote:
In article 5215cd8d.3080...@sidn.nl you write:
So what makes you think the above 4 points will not be a problem for the
next protocol that comes along and needs (apex) RR data? And the one
after that?
SPF is ten years old now. It would be helpful
SPF is ten years old now. It would be helpful if you could give us a
list of other protocols that have had a similar issue with a TXT
record at the apex during the past decade.
I don't know of any (at least ones that are used in the global dns
namespace), and I would like to still not know of
Hello,
This message has a Bcc to an IETF participant.
In my write-up for the Responsible Area Director I mentioned that:
There was an intermediate conclusion about the topic of whether the SPF
protocol should use the SPF RRTYPE or the TXT resource record. It was
followed by an
The SPFbis document improperly conflates DNS terminology with identical terms
invented by this document. Examples are terms used to describe mechanisms
having the same identifier differentiated between mechanisms and DNS resource
records by using lower and upper case respectively. References
Subject: Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender
Policy?Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to
Proposed Standard Date: Thu, Aug 22, 2013 at 12:23:56AM -0400 Quoting Scott
Kitterman (scott@kitterma
On Thursday, August 22, 2013 00:26:35
On 08/21/2013 08:44 PM, Olafur Gudmundsson wrote:
Most of the recent arguments against SPF type have come down to the following
(as far as I can tell):
a) I can not add SPF RRtype via my provisioning system into my DNS
servers
b) My firewall doesl not let SPF Records through
On 8/21/13 4:40 PM, Dave Crocker wrote:
On 8/21/2013 12:46 PM, Pete Resnick wrote:
It is not your complaint about the imposition of new requirements that
is problematic, or your point that it is not useful to continue that
line of discussion. Talk about the utility of a comment all that you
On Aug 22, 2013, at 4:36 AM, Jelte Jansen jelte.jan...@sidn.nl wrote:
On 08/21/2013 08:44 PM, Olafur Gudmundsson wrote:
Most of the recent arguments against SPF type have come down to the
following (as far as I can tell):
a) I can not add SPF RRtype via my provisioning system into
On Thu, Aug 22, 2013 at 10:22 AM, Pete Resnick presn...@qti.qualcomm.comwrote:
Some folks have simply dismissively said, Go read the archive, without
pointers.
Pete, I like your position, but I believe go read the archive or the
equivalent will continue to be a standard response unless
Barry Leiba barryle...@computer.org writes:
The general point is that the new people whom we want
to draw in as productive participants will be watching how we treat
each other and deciding whether they want to wade into that pool.
It's not just new people watching and being turned off.
OK, direct question; I'll take the (short) time to give a direct answer.
On 8/22/13 9:53 AM, Scott Brim wrote:
Pete, I like your position, but I believe go read the archive or the
equivalent will continue to be a standard response unless someone is
responsible for giving a more thorough
On Thu, Aug 22, 2013 at 1:36 AM, Jelte Jansen jelte.jan...@sidn.nl wrote:
While I appreciate the argument 'this works now, and it is used'
(running code, and all that), I am very worried that we'll end up with
what is essentially a free-form blob containing data for several
protocols at the
In article 5215cd8d.3080...@sidn.nl you write:
So what makes you think the above 4 points will not be a problem for the
next protocol that comes along and needs (apex) RR data? And the one
after that?
SPF is ten years old now. It would be helpful if you could give us a
list of other protocols
Pete, I like your position, but I believe go read the archive or the
equivalent will continue to be a standard response unless someone is
responsible for giving a more thorough response. Who do you think that
should be?
If you've had the most fleeting look at this:
I can't myself think of a good justification for sarcasm, (well, maybe [1]:-)
good sarcasm is like good protocol design - many can recognise it, some can
appreciate it, few can truly understand its nuances, and even fewer can create
it.
You're just not one of them.
Lloyd Wood
On Aug 20, 2013, at 9:00 PM, Andrew Sullivan a...@anvilwalrusden.com wrote:
The WG had a hard time coming up with really good data about what validators
look for, ... If someone else with some busy nameservers wants to provide
different evidence now, it wouldn't hurt.
Out of morbid
Subject: Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender
Policy?Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to
Proposed Standard Date: Tue, Aug 20, 2013 at 10:30:41AM -0700 Quoting S
Moonesamy (sm+ietf@elandsys.c
My reading of the SPFBIS Charter is
On 21 aug 2013, at 09:17, David Conrad d...@virtualized.org wrote:
On Aug 20, 2013, at 9:00 PM, Andrew Sullivan a...@anvilwalrusden.com wrote:
The WG had a hard time coming up with really good data about what validators
look for, ... If someone else with some busy nameservers wants to
Patrik,
First, I appreciate that you and Dave are bringing data to the table.
However, in this case, it is not in dispute that queries are happening.
What *is* in dispute is whether there are answers. I must admit I am
having a difficult time understanding the logic, even so. The *hard*
part
So your point is that their conclusions that nobody has the record
installed is false?
Eliot
On 8/21/13 12:42 PM, Patrik Fältström wrote:
On 21 aug 2013, at 12:26, Eliot Lear l...@cisco.com wrote:
The easy part was supposed to be people actually using the SPF record, once
it was out there.
On Wednesday, August 21, 2013 12:00:56 Måns Nilsson wrote:
Subject: Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender
Policy?Framework (SPF) for Authorizing Use of Domains in Email, Version 1)
to Proposed Standard Date: Tue, Aug 20, 2013 at 10:30:41AM -0700 Quoting S
Moonesamy
I object to the removal of the SPF record.
Name servers already have access controls down to the granuality
of TYPE. If this draft proceeds as currently described it is forcing
name server vendors to access controls at the sub TYPE granuality.
With SPF lookup first I can specify the SPF policy
No hat
On Wed, Aug 21, 2013 at 12:26:51PM +0200, Eliot Lear wrote:
However, in this case, it is not in dispute that queries are happening.
Actually, that _was_ in question. Remember, part of the justification
for ditching TYPE99 is not only that publishers don't use it, but also
that if they
On 08/21/2013 03:44 PM, Andrew Sullivan wrote:
Speaking as the SPFBIS co-chair…
On Wed, Aug 21, 2013 at 04:55:33AM -0700, manning bill wrote:
to see if the trend has changed (modulo PAFs observations that not all TXT
== SPF). In the mean time, declare a suspension of
last call to gauge
On Tue 20/Aug/2013 07:27:12 +0200 David Conrad wrote:
On Aug 19, 2013, at 10:14 PM, Randy Bush ra...@psg.com wrote:
one lesson i might take from this is, if i want to deploy a new
hack which needs an rrtype, not to use txt in the interim.
Nor the same format, IMHO.
My personal belief is
On Aug 21, 2013, at 7:17 AM, Patrik Fältström p...@frobbit.se wrote:
My conclusion is that a statement that nobody queries for it is false.
I am curious if the folks who did the analysis of query rates know the answers
to the following questions:
1. Per unit of mail delivered (as opposed to
On Wednesday, August 21, 2013 09:39:28 Andrew Sullivan wrote:
...
* To what extent has that happened?
I'm not the shepherd, but it is undeniable that most current-era
shipping DNS servers support RRTYPE 99.
The operational issues I've encountered with actually trying to use RRTYPE99
in
On Wednesday, August 21, 2013 23:32:33 Mark Andrews wrote:
I object to the removal of the SPF record.
This is not a shock. You were in the rough when we discussed it in the WG
too.
Name servers already have access controls down to the granuality
of TYPE. If this draft proceeds as currently
Eliot Lear wrote:
Patrik,
First, I appreciate that you and Dave are bringing data to the table.
However, in this case, it is not in dispute that queries are happening.
What *is* in dispute is whether there are answers. I must admit I am
having a difficult time understanding the logic,
At 04:55 21-08-2013, manning bill wrote:
regarding adoption
it would be interesting to
take a second snapshot from each of these servers in about six months
to see if the trend has changed (modulo PAFs
observations that not all TXT == SPF). In the
mean time, declare a suspension of
last
Patrik,
On 8/21/2013 7:17 AM, Patrik Fältström wrote:
My conclusion is that a statement that nobody queries for it is
false.
Assuming that your conclusion is based on pragmatics and not
mathematical purity -- that is, that it is concerned with significant
operational effort, rather than a
On 21 aug 2013, at 19:31, Dave Crocker d...@dcrocker.net wrote:
Assuming that your conclusion is based on pragmatics and not
mathematical purity -- that is, that it is concerned with significant
operational effort, rather than a stray implementation here or there,
which counts as noise in any
On 8/21/2013 11:13 AM, Patrik Fältström wrote:
But we are not there. A proper migration strategy to SPF has not been published.
Oh. Now I understand.
You are trying to impose new requirements on the original work, many
years after the IETF approved it.
Thanks. Very helpful.
d/
--
Dave
On Aug 19, 2013, at 5:41 PM, Andrew Sullivan a...@anvilwalrusden.com wrote:
I'm not going to copy the spfbis WG list on this, because this is part
of the IETF last call. No hat.
On Mon, Aug 19, 2013 at 02:04:10PM -0700, Murray S. Kucherawy wrote:
On Mon, Aug 19, 2013 at 1:59 PM, Dave
On 21 aug 2013, at 20:29, Dave Crocker d...@dcrocker.net wrote:
On 8/21/2013 11:13 AM, Patrik Fältström wrote:
But we are not there. A proper migration strategy to SPF has not been
published.
Oh. Now I understand.
You are trying to impose new requirements on the original work, many
On Wednesday, August 21, 2013 14:44:41 Olafur Gudmundsson wrote:
On Aug 19, 2013, at 5:41 PM, Andrew Sullivan a...@anvilwalrusden.com wrote:
I'm not going to copy the spfbis WG list on this, because this is part
of the IETF last call. No hat.
On Mon, Aug 19, 2013 at 02:04:10PM -0700,
AD hat squarely on my head.
On 8/21/13 1:29 PM, Dave Crocker wrote:
Oh. Now I understand.
You are trying to impose new requirements on the original work, many
years after the IETF approved it.
Thanks. Very helpful.
That's not an appropriate response. It is certainly not helpful to me
On 8/21/2013 11:58 AM, Pete Resnick wrote:
AD hat squarely on my head.
On 8/21/13 1:29 PM, Dave Crocker wrote:
Oh. Now I understand.
You are trying to impose new requirements on the original work, many
years after the IETF approved it.
Thanks. Very helpful.
That's not an appropriate
On 8/21/13 2:17 PM, Dave Crocker wrote:
On 8/21/2013 11:58 AM, Pete Resnick wrote:
AD hat squarely on my head.
On 8/21/13 1:29 PM, Dave Crocker wrote:
Oh. Now I understand.
You are trying to impose new requirements on the original work, many
years after the IETF approved it.
Thanks. Very
Subject: Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender
Policy?Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to
Proposed Standard Date: Wed, Aug 21, 2013 at 08:51:31AM -0400 Quoting Scott
Kitterman (scott@kitterma
Apparently.
Translated:
RFC 4408
On Wednesday, August 21, 2013 22:05:37 Måns Nilsson wrote:
Subject: Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender
Policy?Framework (SPF) for Authorizing Use of Domains in Email, Version 1)
to Proposed Standard Date: Wed, Aug 21, 2013 at 08:51:31AM -0400 Quoting
Scott
On 8/21/2013 12:46 PM, Pete Resnick wrote:
It is not your complaint about the imposition of new requirements that
is problematic, or your point that it is not useful to continue that
line of discussion. Talk about the utility of a comment all that you
want. It is the sarcasm and the rudeness
In message 7917527.VmCQD3a6Q3@scott-latitude-e6320, Scott Kitterman writes:
On Wednesday, August 21, 2013 23:32:33 Mark Andrews wrote:
I object to the removal of the SPF record.
This is not a shock. You were in the rough when we discussed it in the WG
too.
Name servers already have
In this conversation between Pete and Dave, there's one point that's
come up which has come up often enough that I want to call it out
separately for comment:
the only purpose it seems to serve is to bully others into not
participating in the conversation.
You think I could bully Patrik?
On 08/21/2013 11:13 PM, Barry Leiba wrote:
The general point is that the new people whom we want
to draw in as productive participants will be watching how we treat
each other and deciding whether they want to wade into that pool.
Yes, that is a factor that merits attention.
But not the
In message 20130821214832.1c92538c0...@drugs.dv.isc.org, Mark Andrews writes:
It's primarily an issue for applications. To the DNS, it's exactly what it
is, a TXT record.
I can hand update of A and records to the machine.
I can hand update of MX records to the mail adminstrator.
I can
Subject: Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender
Policy?Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to
Proposed Standard Date: Wed, Aug 21, 2013 at 04:52:59PM -0400 Quoting Scott
Kitterman (scott@kitterma
On Wednesday, August 21, 2013 22:05:37
Hello,
Lars Eggert mentioned [1] the following:
cool off, take the intensity out of the discussion, and try
to provide data/facts for your different standpoints, so the
rest of us who are sitting on the sidelines watching the
fireworks can form an opinion.
Regards,
S. Moonesamy
1.
Mark Andrews ma...@isc.org wrote:
In message 20130821214832.1c92538c0...@drugs.dv.isc.org, Mark Andrews
writes:
It's primarily an issue for applications. To the DNS, it's exactly
what it
is, a TXT record.
I can hand update of A and records to the machine.
I can hand update of MX
Mark Andrews ma...@isc.org wrote:
In message 7917527.VmCQD3a6Q3@scott-latitude-e6320, Scott Kitterman
writes:
On Wednesday, August 21, 2013 23:32:33 Mark Andrews wrote:
I object to the removal of the SPF record.
This is not a shock. You were in the rough when we discussed it in
the WG
Hi Eliot,
At 03:26 21-08-2013, Eliot Lear wrote:
First, I appreciate that you and Dave are bringing data to the
table. However, in this case, it is not in dispute that queries are
happening. What *is* in dispute is whether there are answers. I
must admit I am having a difficult time
In message 0c3746c3-dac1-471f-bd07-8faf20481...@email.android.com, Scott
Kitterman writes:
Mark Andrews ma...@isc.org wrote:
In message 20130821214832.1c92538c0...@drugs.dv.isc.org, Mark Andrews
writes:
It's primarily an issue for applications. To the DNS, it's exactly
what it
Scott Kitterman wrote:
On Wednesday, August 21, 2013 14:44:41 Olafur Gudmundsson wrote:
What I want the IESG to add a note to the document is that says something
like the following: The retirement of SPF from specification is not to be
taken that new RRtypes can not be used by applications, the
Scott,
On Aug 21, 2013, at 4:07 PM, Scott Kitterman sc...@kitterman.com wrote:
You could publish:
example.com IN TXT v=spf1 redirect=_spf.example.com
_spf.example. com IN TXT v=spf1 [actual content here]
Then delegate _spf.example.com to the mail administrator. Problem solved.
Wouldn't
NB: I have read the rest of the thread; but this is what deserves a reply:
Dave Crocker d...@dcrocker.net wrote:
On 8/21/2013 11:58 AM, Pete Resnick wrote:
AD hat squarely on my head.
(There may have been a miscommunication here -- what particular AD
function Pete was speaking in; but to
On Thursday, August 22, 2013 09:31:03 Mark Andrews wrote:
In message 0c3746c3-dac1-471f-bd07-8faf20481...@email.android.com, Scott
Kitterman writes:
Mark Andrews ma...@isc.org wrote:
In message 20130821214832.1c92538c0...@drugs.dv.isc.org, Mark Andrews
writes:
It's primarily an
Hi John,
At 20:02 21-08-2013, John Leslie wrote:
If this is the sort of response given to somewhat-valid questions
raised about the draft being proposed, Pete will eventually have to
say there _is_ no consensus. :^(
An Area Director may say that. :-(
Regards,
S. Moonesamy
On Thursday, August 22, 2013 00:26:35 Måns Nilsson wrote:
...
SPF is a flagship case for the use a TXT record and continue to IPO
fast and sloppy crowd. It needs correcting. Badly.
Which IPO was that?
BTW, in 2003 the choice was use TXT or nothing. So it was a crowd that wanted
to accomplish
On 20 aug 2013, at 07:21, Dave Crocker d...@dcrocker.net wrote:
The first is that there now a number of other apps using TXT records,
with no problems, because they are stored under scoping nodes
(underscore-prefaced names). This approach might be aesthetically
displeasing, but it
On 8/19/2013 11:33 PM, Patrik Fältström wrote:
Reason for this is that the RR with an underscored prefix MIGHT end up in a
different zone than the record without.
Patrik,
Please clarify. I don't know what you mean by the 'with' and 'without'
references.
And as long as I'm asking for
On 20 aug 2013, at 09:14, Dave Crocker d...@dcrocker.net wrote:
On 8/19/2013 11:33 PM, Patrik Fältström wrote:
Reason for this is that the RR with an underscored prefix MIGHT end up in a
different zone than the record without.
Patrik,
Please clarify. I don't know what you mean by the
1 - 100 of 136 matches
Mail list logo
