On Thu, Aug 25, 2005 at 06:53:12PM -0700,
Stuart Cheshire [EMAIL PROTECTED] wrote
a message of 20 lines which said:
Please stop calling it proprietary.
A proprietary solution by any other name would still be proprietary
:-)
The mDNS specificiation is publicly available, and is the result
On Thu, 2005-08-25 at 18:20 -0400, Keith Moore wrote:
SNIP
Specifics: Mailman has a per-recipient setting called nodupes. The
effect of this setting is that any recipient address that has the
nodupes flag set, and which appears in a To or CC field of a message
sent to the list, will not
On Aug 26, 2005, at 9:20 AM, Stephane Bortzmeyer wrote:
The most important criteria is
the fact that the specification is NOT controlled by any given private
entity.
is that enought to show thats not proprietary ?
http://www.macdevcenter.com/pub/a/mac/2004/08/31/osx_java.html
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 26, 2005, at 03:14, Jeroen Massar wrote:
Indeed when some 'malicious' person would add Cc's/To's and would
instruct his SMTP to not forward to the additional addresses in the
Cc/To the users will effectively not receive the message.
But
On Fri, Aug 26, 2005 at 10:00:39AM +0200,
Marc Manthey [EMAIL PROTECTED] wrote
a message of 120 lines which said:
is that enought to show thats not proprietary ?
It has nothing to do with the criterium I expressed. You just said
that Bonjour / Rendez-vous has several free (as in free
Hi Jeroen,
I forwared your message - not replying to show your headder:
From: Jeroen Massar [EMAIL PROTECTED]
To: Keith Moore moore@cs.utk.edu
Cc: ietf@ietf.org
So you had sent to [EMAIL PROTECTED]
ietf@ietf.org received only a copy. Some people might have got nothing.
My own
Stephane Bortzmeyer [EMAIL PROTECTED] writes:
It is not sufficient to make it an open standard (by your criteria, Java
or PDF would be non-proprietary). The most important criteria is the
fact that the specification is NOT controlled by any given private
entity.
If you go look at the
On Fri, 2005-08-26 at 10:33 +0200, Peter Dambier wrote:
Hi Jeroen,
I forwared your message - not replying to show your headder:
From: Jeroen Massar [EMAIL PROTECTED]
To: Keith Moore moore@cs.utk.edu
Cc: ietf@ietf.org
offtopic title=what actually happens with mailman
Which causes my
Folks,
I realize that this is something that could happen. Interesting
attack! But I missed the part where its somehow news to
us that e-mail system can be tricked in various ways.
And: Most of the time in important discussions it does not matter
if some messages get lost. People have lengthy
On Aug 26, 2005, at 05:42, Jari Arkko wrote:
I realize that this is something that could happen. Interesting
attack! But I missed the part where its somehow news to
us that e-mail system can be tricked in various ways.
It's not. But that doesn't mean we need to add new ways, and enable
them
On Fri, 2005-08-26 at 03:56 -0400, Ken Raeburn wrote:
On Aug 26, 2005, at 03:14, Jeroen Massar wrote:
Indeed when some 'malicious' person would add Cc's/To's and would
instruct his SMTP to not forward to the additional addresses in the
Cc/To the users will effectively not receive the
JFC (Jefsey) Morfin wrote:
On 21:25 25/08/2005, Stephane Bortzmeyer said:
If the IESG were to refuse to publish the Sender-ID document as it is,
it would not police everything: anyone can still do what he wants on
the Internet.
The only thing than the IETF can do is to bless or not the
Peter,
Peter Koch wrote:
Brian E Carpenter wrote:
I read the relevant bits of 2026 a couple of times, and I am pretty
convinced that a BCP can only exist as a single RFC (which may or may not
section 5.1 of 2026 reads:
A specification, or group of specifications, that has, or have
Russ Allbery wrote:
...
I think your criteria doesn't survive logical scrutiny. If other people
have access to the standard, can implement the standard, and can build on
the standard to create a newer revision of it, I can't imagine what
definition of proprietary you're using that would apply.
At 13:08 26/08/2005, Brian E Carpenter wrote:
JFC (Jefsey) Morfin wrote:
just a remark here. In the RFC 3066bis Last Call case the IETF has
the capacity not only to police but to impose and force. This
is the case when a memo documents a IANA registry. In the case of a
standard track memo,
On Fri, Aug 26, 2005 at 08:47:17AM -0400,
Andrew Newton [EMAIL PROTECTED] wrote
a message of 21 lines which said:
If this is the source of the conflict, then BOTH experiments should
not use the v=spf1 records.
It is an absolutely incredible request since SPF uses these records
since its
On 8/25/05, Keith Moore moore@cs.utk.edu wrote:
Recent versions of mailman set nodupes by default. List participants
can change it if they know about it, but they might have no idea of how
this setting works and how it can be used to exclude them from
participation.
The workaround is to
On Aug 26, 2005, at 9:15 AM, Stephane Bortzmeyer wrote:
On Fri, Aug 26, 2005 at 08:47:17AM -0400,
Andrew Newton [EMAIL PROTECTED] wrote
a message of 21 lines which said:
If this is the source of the conflict, then BOTH experiments should
not use the v=spf1 records.
It is an absolutely
there is a fairly extensive history of multicast DNS...
in 1998/1999, along w/ this draft:
Woodcock, B., Manning, B., Multicast Domain Name Service,
draft-manning-dnsext-mdns-02.txt, August 2000. Revied twice now
Expired.
was this one:
Vixie, P., Manning, B., Supporting unicast replies to
Sorry to follow up to my own message; I discovered when setting up
rtg.ietf.org's mailman setup that putting
DEFAULT_NEW_MEMBER_OPTIONS = 0
in mm_cfg.py will turn off the nodupes option for new lists. It'll
still be on by default for existing lists, and existing subscriptions.
Bill
On Fri, 26 Aug 2005 06:54:57 -0700
Bill Manning [EMAIL PROTECTED] wrote:
there is a fairly extensive history of multicast DNS...
in 1998/1999, along w/ this draft:
snip
... so multicast DNS has been around, with various implementations over
the years.
the Apple mDNS spec is not an IETF
I am perhaps just being slow and dim-witted after minor surgery, but why
should a protocol that no-one will use be standards track ?
Why should we accept a few (mostly axe-grinding) peoples' assertions
that no-one will use it?
Keith
___
Ietf
JFC (Jefsey) Morfin wrote:
At 13:08 26/08/2005, Brian E Carpenter wrote:
JFC (Jefsey) Morfin wrote:
just a remark here. In the RFC 3066bis Last Call case the IETF has
the capacity not only to police but to impose and force. This
is the case when a memo documents a IANA registry. In the case
On Fri, 26 Aug 2005, Keith Moore wrote:
I think DKIM is fixable, but if it stays in its current form it will only
delay adoption of effective anti-phishing and anti-spam solutions by a few
more years.
Has anyone published a description of an effective anti-phishing and
anti-spam solution?
Brian E Carpenter writes (Re: Last Call: 'Linklocal Multicast Name Resolution
(LLMNR)' to Proposed Standard):
Russ Allbery wrote:
...
I think your criteria doesn't survive logical scrutiny. If other people
have access to the standard, can implement the standard, and can build on
the
On 26-aug-2005, at 10:33, Peter Dambier wrote:
Hi Jeroen,
I forwared your message - not replying to show your headder:
From: Jeroen Massar [EMAIL PROTECTED]
To: Keith Moore moore@cs.utk.edu
Cc: ietf@ietf.org
So you had sent to [EMAIL PROTECTED]
ietf@ietf.org received only a copy. Some
In [EMAIL PROTECTED] Keith Moore moore@cs.utk.edu writes:
I agree that getting authentication into the email protocols is a good
thing, but TLS does not achieve much more than SPF/Sender-ID in that
respect. DKIM is a much better platform.
Not clear. [a summary of the status of DKIM that I
From: Keith Moore [mailto:[EMAIL PROTECTED]
I agree that getting authentication into the email
protocols is a good
thing, but TLS does not achieve much more than
SPF/Sender-ID in that
respect. DKIM is a much better platform.
Not clear. As currently envisioned, DKIM doesn't
I don't necessarily see the two needing to be combined so closely.
Phishing exploits the web security model where the server authenticates
the client a lot more than the client the server. SPAM is one method
of delivery for a Phishing attack, but there are others.
Mark
On Aug 26, 2005, at
I agree that getting authentication into the email protocols is a good
thing, but TLS does not achieve much more than SPF/Sender-ID in that
respect. DKIM is a much better platform.
Not clear. As currently envisioned, DKIM doesn't address phishing
because it basically says I saw this message
Mark Baugher wrote:
I don't necessarily see the two needing to be combined so closely.
perhaps not, but if DKIM doesn't address either phishing, spam, or
viruses, and it doesn't authenticate content authorship, what good is it?
___
Ietf mailing
On Aug 26, 2005, at 9:38 AM, Keith Moore wrote:
Mark Baugher wrote:
I don't necessarily see the two needing to be combined so closely.
perhaps not, but if DKIM doesn't address either phishing, spam, or
viruses, and it doesn't authenticate content authorship, what good is
it?
I said that
Let me phrase it this way: the IESG should not sanction conflicting
experiments by publishing conflicting specifications,
I agree.
But I do not believe that SPF and Sender-ID conflict in any way
whatsoever and this was accepted by the WG right up to the point where
people started to complain
perhaps not, but if DKIM doesn't address either phishing, spam, or
viruses, and it doesn't authenticate content authorship, what good is it?
I said that I don't think phishing should be combined so closely with
the problem of spam. But you throw in viruses and claim that it doesn't
address
Ian Jackson [EMAIL PROTECTED] writes:
I'm finding this discussion quite disturbing.
You're not the only one, and I'm not even directly affected by this
decision.
It seems that the proposal is that the IETF should bless LLMNR because
LLMNR is on the Blessing Track.
Surely the reasons for
Behalf Of Andrew Newton
If this is the source of the conflict, then BOTH experiments should
not use the v=spf1 records.
Which would at the same time provide an opportunity to address the one
part of SPF/Sender-ID that does give me significant concern, the
exclusive appropriation of the TXT
On Aug 26, 2005, at 10:36, Russ Allbery wrote:
Presumably the DNS working group has some incredibly strong arguments
that
trump running code or they wouldn't have made the choices that they
have.
Let's see them, and furthermore, let's see them *in the document* or at
least in a supporting
In [EMAIL PROTECTED] Hallam-Baker, Phillip [EMAIL PROTECTED] writes:
I do not think that the IESG should block a proposal citing a conflict
when the real animus here is entirely due to the IPR issue.
There are certainly people who have problems with introducing
technology into a core Internet
In [EMAIL PROTECTED] Hallam-Baker, Phillip [EMAIL PROTECTED] writes:
[PHB brainstorms about a new protocol...]
The main objection to prefixed records is that they do not work with
wildcards. This is actually a failure of imagination rather than fact.
It is quite possible to develop a
wayne == wayne [EMAIL PROTECTED] writes:
wayne In [EMAIL PROTECTED] Andrew
wayne Newton [EMAIL PROTECTED] writes:
But since you brought this up: if you (the author of the
document) do not consider this to be an experiment, then
perhaps the IETF should not publish SPF as
Behalf Of wayne
The way to do this is to introduce a pointer record using CNAME as
follows:
_prefix.exists.example.comTXT Policy1
*.example.com CNAME _wildcard.example.com
_prefix._wildcard.example.com TXT Policy2
I don't believe this
All SPF does is provide a mechanism whereby sending parties can
describe their outgoing edge mail servers. The recipient has the
absolute right to interpret that data in any way they see
fit. That is
the entire point of a spam filtering scheme.
You have long advocated this
There are several known conflicts, as outlined in the appeal,
and they don't begin with the sender intends.
You appear to refer to:
http://www.mhonarc.org/archive/cgi-bin/mesg.cgi?a=ietfi=200508250045.27
704.julian%40mehnle.net
* Many mailing lists rewrite the MAIL FROM identity when
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Phillip Hallam-Baker wrote:
Let me phrase it this way: the IESG should not sanction conflicting
experiments by publishing conflicting specifications,
I agree.
But I do not believe that SPF and Sender-ID conflict in any way
whatsoever and this
All of this has been aired extensively among experts on at least two
public lists as well as many private ones. I have personally had a lot
to say on the matter but don't see the point of repeating it here.
Mark
On Aug 26, 2005, at 10:23 AM, Keith Moore wrote:
perhaps not, but if DKIM
In [EMAIL PROTECTED] Hallam-Baker, Phillip [EMAIL PROTECTED] writes:
All SPF does is provide a mechanism whereby sending parties can
describe their outgoing edge mail servers. The recipient has the
absolute right to interpret that data in any way they see
fit. That is
the entire
At Fri, 26 Aug 2005 11:28:44 -0700, Bill Manning wrote:
then there was the debate over if this was DNS or something else...
Stewart I took the stance, yes it was/is.
Yep, this was the original sticking point. In particular, there were
folks (myself among them) who felt strongly
In [EMAIL PROTECTED] Douglas Otis [EMAIL PROTECTED] writes:
If the goal of the SPF Classic draft was intended to capture a point
in time pre-dating semantic extensions related to RFC-2822 defined
content, then perhaps the draft should be on an historic track. ; )
RFC2026 says:
4.2.4
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Phillip Hallam-Baker wrote:
Since all these 'failures' are simply known properties of the PRA check
there is absolutely no value in changing the version string.
Of course there is. The fact alone that S-ID has different failure
modes than SPF
On 17:23 26/08/2005, Brian E Carpenter said:
JFC (Jefsey) Morfin wrote:
At 13:08 26/08/2005, Brian E Carpenter wrote:
JFC (Jefsey) Morfin wrote:
just a remark here. In the RFC 3066bis Last Call case the IETF
has the capacity not only to police but to impose and
force. This is the case when
Behalf Of wayne
At some point there is a boundary between infrastructure the sender
has control of and where he does not. That boundary is very clearly
defined in my universe but even if it was ambiguous it would still
exist.
The problem is that for different identities, this
hopefully convalesce Marshall Eubanks wrote following important lines
why should a protocol that no-one will use be standards track ?
This discussion is beginning to remind me of the scientific
standards processes involving the Soviet
bloc that I was involved with during the Cold War. That
Hallam-Baker, Phillip wrote:
But I do not believe that SPF and Sender-ID conflict in any
way whatsoever and this was accepted by the WG
What you believe is your business, but this was never accepted
by the WG, because it's plain wrong, see also reference [12]
in the appeal:
Hallam-Baker, Phillip wrote:
Once that boundary is defined the definition is fair game for
any party to use to interpret it to meet their operational
needs.
The boundaries are different and incompatible for spf2.0/mfrom
(roughly te same as v=spf1) and spf2.0/pra. That's the point
of the
Brian == Brian E Carpenter [EMAIL PROTECTED] writes:
Brian JFC (Jefsey) Morfin wrote:
At 13:08 26/08/2005, Brian E Carpenter wrote:
JFC (Jefsey) Morfin wrote:
just a remark here. In the RFC 3066bis Last Call case the
IETF has the capacity not only to police but to impose
Iljitsch van Beijnum wrote:
On 26-aug-2005, at 10:33, Peter Dambier wrote:
Hi Jeroen,
I forwared your message - not replying to show your headder:
From: Jeroen Massar [EMAIL PROTECTED]
To: Keith Moore moore@cs.utk.edu
Cc: ietf@ietf.org
So you had sent to [EMAIL PROTECTED]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andrew Newton wrote:
Wayne Schlitt wrote:
Andrew Newton wrote:
If this is the source of the conflict, then BOTH experiments should
not use the v=spf1 records.
The stated goal of draft-schlitt-spf-classic is to document SPF,
basically as
Behalf Of Sam Hartman
Fundamentally, though,
it is their desire to have interoperability that drives them
to work with the IETF. That is the only power we have.
Ergo the attempt to force Sender-ID to use v=2.0 in order to create an
unnecessary interoperability failure is utterly doomed to
As has recently been pointed out on the namedroppers list, the dual
track RR and TXT approach does not work. It leads to ambiguities when
the records do not match - which they will inevitably dur to the DNS
protocol.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Hallam-Baker, Phillip wrote:
I do not think that the IESG should block a proposal citing a
conflict when the real animus here is entirely due to the IPR
issue.
Hogwash, I've proposed a way to fix PRA to avoid at least
the worst incompatibility (a default Sender derived from
the Return-Path in
On Fri, 26 Aug 2005, Hallam-Baker, Phillip wrote:
As has recently been pointed out on the namedroppers list, the dual
track RR and TXT approach does not work. It leads to ambiguities when
the records do not match - which they will inevitably dur to the DNS
protocol.
Actually what has been
Dear Sam,
thank you for this analysis. This is exactly my concern. There are in
addition a few points:
1. the WG-ltru involves employees of the industry dominant actors. I
feel they will not want to make a costly error for their corporation
and for them. But Layer 8 strategy errors are
Dotzero wrote:
Writing a standard which subverts the intent of individuals
publishing to a different and existing standard is simply
unethical and wrong.
+1
What happened was essentially a political move because people
chose not to publish SPF2 records for PRA. So, the response
was to
On 8/26/05 at 5:59 PM -0400, Steven M. Bellovin wrote:
What I find amusing is so many people asking the IESG to overrule a
WG's judgment, given how many people have complained about the
IESG's power to do exactly that. I haven't checked for overlap
between the two groups...
I have never
What I find amusing is so many people asking the IESG to overrule a
WG's judgment, given how many people have complained about the IESG's
power to do exactly that. I haven't checked for overlap between the
two groups...
This is much less of a contradiction than you imagine. To exercise
Andrew Newton wrote:
I stated that the SPF and Sender ID experiments should not
use the v=spf1 records to avoid conflict.
Yes, you are a prominent part of this embrace and extend
strategy also known as steal or destroy.
if you (the author of the document) do not consider this to
be an
wayne wrote:
Informational might also be appropriate.
Not from my POV, I wanted this beast under IETF control.
That's why I pushed for an RfC, and later after reading
the fine print 2026 for standards track.
Informational is something the authors could update
whenever it pleases them. There
In [EMAIL PROTECTED] Douglas Otis [EMAIL PROTECTED] writes:
On Aug 26, 2005, at 12:56 PM, wayne wrote:
SPF Classic has not achieved the goal of capturing a pristine version
of pre-MARID semantics. With some semantic changes introduced by the
SPF Classic draft itself, [...]
There isn't a
I really hate lists with reply-to pointing to the list.
I know when I want to reply to the list, and when I want to reply
individually to the sender. When reply-to points to the list, it is
extremely difficult with most mailers to send a reply to the originator.
Yours,
Joel
At 11:49 AM
Stephane Bortzmeyer wrote:
It is an absolutely incredible request since SPF uses these
records since its beginning (a long time before Sender-ID
existed) and since there is (unlike SenderID) actual
deployment, which can not be called back.
SPF is also older than Caller-ID, a patented
Spencer Dawkins wrote:
of course, the idea of the IESG policing anything that
happens on the Internet has to be kind of silly, given that
two consenting endpoints can send just about anything to
each other, especially above the IP layer, and our obvious
lack of any enforcement mechanism.
.. Original Message ...
On Fri, 26 Aug 2005 23:15:32 -0400 John Glube [EMAIL PROTECTED]
wrote:
The conflict apparently is that the Schlitt draft
recommends against use of spfv1 records for use with PRA
authentication, while the Lyon draft says that receivers
can use the spfv1 records for
72 matches
Mail list logo
