FYI -- someone bounced my e-mail to a draft.all address based upon SPF.

Not sure if this is a problem with their MTA or the tools forwarding setup...

Cheers,



Begin forwarded message:

> From: Mail Delivery System <Mailer-Daemon@grenache.tools.ietf.org>
> Subject: Mail delivery failed: returning message to sender
> Date: 15 November 2012 6:44:25 PM AEDT
> To: mnot@mnot.net
> 
> This message was created automatically by mail delivery software.
> 
> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es) failed:
> 
>  peter@akayla.com
>    (generated from draft-ietf-pkix-est.all@tools.ietf.org)
>    SMTP error from remote mail server after DATA:
>    host smtp.secureserver.net [72.167.238.201]: 550 5.7.1 SPF unauthorized mail is prohibited.
>  kent@bbn.com
>    (generated from draft-ietf-pkix-est.all@tools.ietf.org)
>    SMTP error from remote mail server after end of data:
>    host dfw-gate.raytheon.com [199.46.199.195]: 550 5.7.1 Sender ID/SPF failed from IP 77.72.230.30 for PRA mnot@mnot.net, please forward to the email administrators for mnot.net or have them contact postmaster@raytheon.com
> 
> ------ This is a copy of the message, including all the headers. ------
> 
> Return-path: <mnot@mnot.net>
> Received: from mxout-08.mxes.net ([216.86.168.183]:19948)
> 	by grenache.tools.ietf.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
> 	(Exim 4.77)
> 	(envelope-from <mnot@mnot.net>)
> 	id 1TYu7O-00029N-Ap
> 	for draft-ietf-pkix-est.all@tools.ietf.org; Thu, 15 Nov 2012 08:44:11 +0100
> Received: from [192.168.1.64] (unknown [118.209.81.233])
> 	(using TLSv1 with cipher AES128-SHA (128/128 bits))
> 	(No client certificate requested)
> 	by smtp.mxes.net (Postfix) with ESMTPSA id 2618F509B5;
> 	Thu, 15 Nov 2012 02:44:04 -0500 (EST)
> From: Mark Nottingham <mnot@mnot.net>
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: quoted-printable
> Date: Thu, 15 Nov 2012 18:44:20 +1100
> Message-Id: <060AEB60-8E59-4AB2-A178-5874BE36AF71@mnot.net>
> Cc: Apps Discuss <discuss@apps.ietf.org>
> To: draft-ietf-pkix-est.all@tools.ietf.org
> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
> X-Mailer: Apple Mail (2.1499)
> X-SA-Exim-Connect-IP: 216.86.168.183
> X-SA-Exim-Rcpt-To: draft-ietf-pkix-est.all@tools.ietf.org
> X-SA-Exim-Mail-From: mnot@mnot.net
> X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on
> 	grenache.tools.ietf.org
> X-Spam-Level: 
> X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00,SPF_HELO_PASS,
> 	SPF_PASS autolearn=no version=3.3.2
> Subject: APPDIR review of draft-ietf-pkix-est-03
> X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
> X-SA-Exim-Scanned: Yes (on grenache.tools.ietf.org)
> Resent-To: dharkins@arubanetworks.com, kent@bbn.com,, peter@akayla.com, pritikin@cisco.com, stefan@aaa-sec.com
> 
> I have been selected as the Applications Area Directorate reviewer for =
> this draft (for background on appsdir, please see  =
> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate =
> ).
> 
> Document: draft-ietf-pkix-est-03
> Title: Enrollment over Secure Transport
> Reviewer: Mark Nottingham
> Review Date: 15-Nov-2012
> 
> Summary: This draft is not ready for publication as a Proposed Standard =
> and should be revised before publication.
> 
> Major Issues:=20
> 
> As written, this draft violates BCP56, "On the use of HTTP as a =
> Substrate:"
> 
>>   2. New protocols - including but not limited to those using HTTP -
>>      should not attempt to circumvent users' firewall policies,
>>      particularly by masquerading as existing protocols.
>>      "Substantially new services" should not reuse existing ports.
>> =20
>>   3. In general, new protocols or services should not reuse http: or
>>      other URL schemes.
> 
> 
> While there has been longstanding discussion about obsoleting BCP56, =
> because it's acknowledged that HTTP is useful for other protocols, that =
> document has not yet been published.=20
> 
> However, when it is, it's very likely to embody the intent behind =
> RFC5785 -- that the HTTP URI namespace of hosts is under their =
> individual control, and that standards ought not impinge upon it in any =
> way, except in the limited ways described by that document.
> 
> In other words, IETF standards should not define URIs or patterns of =
> URIs, because servers may wish to provide other services (implying the =
> possibility of collision), or deploy resources in an alternate way, for =
> implementation or operational reasons.=20
> 
> This is a fundamental concept in the Web architecture; see =
> <http://www.w3.org/TR/webarch/>.=20
> 
> Possible remedies include:
> 
> 1) Specifying a "home document" format that links (in the RFC5988 sense) =
> to the various resources as appropriate.=20
> 2) Specifying a well-known URI to root the interaction. Note that this =
> is suboptimal; while it avoids collisions, it does not allow alternate =
> deployments, or multiple deployments on the same host.
> 
> Regards,
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
> 
> 

--
Mark Nottingham   http://www.mnot.net/