At 04:08 09/12/2005, Lucy E. Lynch wrote:
On Fri, 9 Dec 2005, JFC (Jefsey) Morfin wrote:
snip
NB1: I fully understand that people from the darkwing are jealous
from those living on the brightside. :-)
channeling Lord Vader ... The force is with you young Skywalker, but
you are not a Jedi yet.
On Fri, 9 Dec 2005, Pekka Savola wrote:
Basically the IESG decided that accurate documentation of the running code
is more important than documenting something that does not exist, and maybe
never will exist.
That's certainly an understandable tradeoff to make, and it gets back to the
more
I think that further tweaking with this document is not going to
make it much better I think its more than good enough now - so lets
sign it and get it behind us
Scott
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pekka Savola wrote:
There seem to be three options going forward:
1) make no changes to the spec. The spec (assumably) documents the
existing behaviour, even if it is conflicting.
2) make the spec to disallow that. The
Julian Mehnle writes:
As my appeal[1] pointed out, at the time draft-lyon-senderid-core-00 was
submitted for experimental status, there was no running code that
actually interpreted v=spf1 as spf2.0/mfrom,pra.
Perhaps you shouldn't have said that. Sendmail's sid-milter has used
v=spf1
Eliot == Eliot Lear [EMAIL PROTECTED] writes:
Eliot Obviously what you're suggesting isn't hard to do, and I
Eliot agree with you that in many cases use of port 22 would be
Eliot safe (and it would certainly be true for the VAST majority
Eliot of cases when connecting to network
In [EMAIL PROTECTED] Julian Mehnle [EMAIL PROTECTED] writes:
Pekka Savola wrote:
Basically the IESG decided that accurate documentation of the running
code is more important than documenting something that does not exist,
and maybe never will exist.
As my appeal[1] pointed out, at the time
In [EMAIL PROTECTED] william(at)elan.net [EMAIL PROTECTED] writes:
However SID drafts are going for EXPERIMENTAL status and are NOT purely
documentation of running code but rather IETF sanctioned internet-wide
experiment with possible intention to move to standard if experiment
is successful.
In [EMAIL PROTECTED] Dick St.Peters [EMAIL PROTECTED] writes:
Julian Mehnle writes:
As my appeal[1] pointed out, at the time draft-lyon-senderid-core-00 was
submitted for experimental status, there was no running code that
actually interpreted v=spf1 as spf2.0/mfrom,pra.
Perhaps you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dick St.Peters wrote:
Julian Mehnle writes:
As my appeal[1] pointed out, at the time draft-lyon-senderid-core-00
was submitted for experimental status, there was no running code
that actually interpreted v=spf1 as spf2.0/mfrom,pra.
Perhaps
In [EMAIL PROTECTED] Dick St.Peters [EMAIL PROTECTED] writes:
Julian Mehnle writes:
As my appeal[1] pointed out, at the time draft-lyon-senderid-core-00 was
submitted for experimental status, there was no running code that
actually interpreted v=spf1 as spf2.0/mfrom,pra.
Perhaps you
wayne writes:
In [EMAIL PROTECTED] Dick St.Peters [EMAIL PROTECTED] writes:
Julian Mehnle writes:
As my appeal[1] pointed out, at the time draft-lyon-senderid-core-00 was
submitted for experimental status, there was no running code that
actually interpreted v=spf1 as spf2.0/mfrom,pra.
Pekka Savola wrote:
1) make no changes to the spec. The spec (assumably)
documents the existing behaviour, even if it is
conflicting.
SPF (both v=spf1 and spf2.0, there is no v=pf2.0) allows
to log DNS queries. That's documented in the v=spf1 draft:
With SPF's exists:-mechanism it's
On Fri, 9 Dec 2005, Dick St.Peters wrote:
Do you know if Sendmail Inc. is committed to conforming to the RFCs
and will change if the RFCs change?
You'll have to ask them. However, I suspect it's safe to say that
they will conform to any RFCs that become standards.
SPF SID document if
In [EMAIL PROTECTED] Frank Ellermann [EMAIL PROTECTED] writes:
Result of this experiment (last state that I've heard of):
Absolutely nobody evaluates spf2.0/pra.
fyi;
There have been a couple of people who have run stats on the usage of
spf2.0/pra vs SPF. It *is* being used, but no where
wayne == wayne [EMAIL PROTECTED] writes:
wayne Isn't the time to fix the problem now? Before the
wayne experiment is run?
Can you convince the sender ID authors to do so and to change their
implementations?
I don't think the IETF or IESG could accomplish that. If you can then
I
In [EMAIL PROTECTED] Dick St.Peters [EMAIL PROTECTED] writes:
wayne writes:
In [EMAIL PROTECTED] Dick St.Peters [EMAIL PROTECTED] writes:
Julian Mehnle writes:
As my appeal[1] pointed out, at the time draft-lyon-senderid-core-00 was
submitted for experimental status, there was no
On Fri, 9 Dec 2005, Sam Hartman wrote:
wayne == wayne [EMAIL PROTECTED] writes:
wayne Isn't the time to fix the problem now? Before the
wayne experiment is run?
Can you convince the sender ID authors to do so and to change their
implementations?
I don't think the IETF or IESG could
wayne wrote:
For example, the SenderID I-D talks about DNS zone cuts and
such, which were in earlier drafts of the SPF spec, but were
removed from the final draft
Their May 2005 draft still references your December 2004 state:
| If the PRA version of the test is being performed and no
|
wayne wrote:
There have been a couple of people who have run stats on the
usage of spf2.0/pra vs SPF. It *is* being used, but no where
near as much as SPF.
I was referring to your article in spf-discuss some months ago,
where you found that a dummy spf2.0/pra opt out is apparently
not
This thread has contained several suggestions that publication of
an RFC in the Experimental category constitutes an IETF experiment.
I cannot find any evidence from RFC 2026 that there is any such thing
as an IETF experiment or IETF-sanctioned experiment. Section 4.2.1
of RFC 2026 explains what
I cannot find any evidence from RFC 2026 that there is any such
thing as an IETF experiment or IETF-sanctioned experiment.
Me neither. Since neither the SPF nor the Sender-ID crowds appear to
have any interest in modifying their specs, that doesn't sound like an
experiment to me, IETF or
I'd suggest the most sensible thing to do is to reclassify both of them
as Informational, to document what you might find in some TXT records,
publish them, and be done with it.
Yes. This seems like exactly the right choice, since it is what is
typically done for documenting
existing
All -
First, I want to thank everyone who took the time to comment on the
IETF Trust document during the Consensus Call. After reviewing the
comments the IAOC has taken the following actions:
1] The parties to the IETF Trust have agreed to amend Section 9.5 of
the founding document in order to
Bob Braden wrote:
I cannot find any evidence from RFC 2026 that there is any
such thing as an IETF experiment or IETF-sanctioned
experiment.
Yes, that's tricky. Some folks including me were surprised
that there's no IETF last call for experimental RFCs, unless
they are the product of an IETF
In [EMAIL PROTECTED] John Levine [EMAIL PROTECTED] writes:
I cannot find any evidence from RFC 2026 that there is any such
thing as an IETF experiment or IETF-sanctioned experiment.
Me neither. Since neither the SPF nor the Sender-ID crowds appear to
have any interest in modifying their
In [EMAIL PROTECTED] Bob Braden [EMAIL PROTECTED] writes:
This thread has contained several suggestions that publication of
an RFC in the Experimental category constitutes an IETF experiment.
This is, in part, due to the directions of the IESG. For example, the
IESG note that will be placed
What exactly do you think needs to be changed with the SPF draft?
If you want to document what people do with SPF now, nothing other
than making it Informational.
If you actually want to do experiments, change the record format so it
won't be confused with Sender-ID or anything else and you can
28 matches
Mail list logo
