Folks,
Gentlemen don't disclose private correspondence.
Rather than make a huge fuss, I will simply point out that
the correspondence posted below by Wayne to this public
list was sent by me to a private mailing list which is not
publicly archived to which the parties agreed to keep the
discussions in confidence.
The note had in the subject line:
|CONFIDENTIAL.
At the bottom of the note it had:
|This email contains confidential information. You may not
|disclose the contents to anyone else without my consent.
Wayne broke his word. I am certain that the Microsoft
representatives who read this list will be eternally
grateful to Wayne for his exuberance in informing them of
the flaw in the Sender ID: Email Authentication draft and
will now take immediate steps to rectify the matter.
John
P.S. I wish all of you good luck in your future endeavours.
John Glube
Toronto, Canada
-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com] On Behalf Of wayne
Sent: November 12, 2004 1:37 AM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: [spf-discuss] AOL testing.
In <01dd01c4c7c2$c7c473a0$6c62fea9(_at_)ibmrkydk2ufvdd> "John Glube"
<john(_at_)trusted-email-sender(_dot_)com> writes:
The AOL Tests
AOL has agreed to do dry tests on Mail From authentication,
a form of PRA authentication and EHELO/HELO authentication
based on using SPF records.
Actually, IIRC, Carl said that they *weren't* using the PRA, but
rather, they care checking only the From: header against the SPF
record. I suspect that they are doing something similar to my
draft-schlitt-marid-spf-from-hdr I-D.
* Can we use v=spf1 records for EHELO/HELO authentication
based on the CSV specification;
SPF-classic has always done HELO checking in some cases and has
long
had it as option. I don't see how what AOL is doing is "based on
the
CSV specification".
I am most grateful that AOL has decided to run these tests.
ME TOO! </aol>
Once the SPF Community Council is formed, one of the first
points which needs to be raised is whether the Council
wants to revisit Meng's signing off on the sender id draft
for core.
We can't stop Meng from authoring other I-Ds.
If it is determined he was acting on his own, it may be
appropriate to remove Meng and appoint a new editor.
We can't remove Meng as an editor, all we can do is submit a
competing
I-D, and that has problems.
Should this step be taken, I believe the next step is to
formally inform the IETF RFC editor that Mr. Wong did not
have authority from the SPF community to agree to the
Sender ID draft.
The IETF won't do anything because authors don't need to be
authorized
by anyone.
Furthermore the Sender ID draft is not in compliance with
the directive from the MARID working group chairs that any
draft submitted for consideration should not reference
Sender ID and therefore needs to be rejected.
That we can take up with the IESG during the SenderID last call.
Also, Andy asked the IETF legal folks about using the term
"sender id"
and was told that it shouldn't be used. I'm almost certain that
the
IESG will require MS/Meng to remove all references to SenderID in
their I-D before advancing it.
-wayne
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
http://www.InboxEvent.com/?s=d --- Inbox Event Nov 17-19 in
Atlanta features SPF and Sender ID.
To unsubscribe, change your address, or temporarily deactivate
your subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.789 / Virus Database: 534 - Release Date: 07/11/2004
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.789 / Virus Database: 534 - Release Date: 07/11/2004