Subject: [Tools-discuss] Fwd: Mail delivery failed: returning message to sender

From: Mark Nottingham <[email-masked]>
Date: Thu, 15 Nov 2012 18:46:30 +1100

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 <[email-masked]>
> Subject: Mail delivery failed: returning message to sender
> Date: 15 November 2012 6:44:25 PM AEDT
> To: [email-masked]
> 
> 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:
> 
>  [email-masked]
>    (generated from [email-masked])
>    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.
>  [email-masked]
>    (generated from [email-masked])
>    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 [email-masked], please forward to the email administrators for mnot.net or have them contact [email-masked]
> 
> ------ This is a copy of the message, including all the headers. ------
> 
> Return-path: <[email-masked]>
> 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 <[email-masked]>)
> 	id 1TYu7O-00029N-Ap
> 	for [email-masked]; 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 <[email-masked]>
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: quoted-printable
> Date: Thu, 15 Nov 2012 18:44:20 +1100
> Message-Id: <[email-masked]>
> Cc: Apps Discuss <[email-masked]>
> To: [email-masked]
> 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: [email-masked]
> X-SA-Exim-Mail-From: [email-masked]
> 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: [email-masked], [email-masked],, [email-masked], [email-masked], [email-masked]
> 
> 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/

---

From: SM <[email-masked]>
Date: Thu, 15 Nov 2012 02:48:57 -0800

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

This is the SPF record for mnot.net:

  v=spf1 a:cloud.mnot.net a:mail.internode.on.net 
include:customer-spf.mxes.net -all

mnot.net is telling the raytheon.com that mail from mnot.net will 
only come from the hosts mentioned above.  The problem is the SPF 
record for mnot.net does not expect its messages from that domain to 
go through forwarders.

The alternatives are:

  (i)   Change the "-all"

  (ii)  Add entries to allow messages from that email address to come from
        the tools.ietf.org SMTP server

  (iii)  Do nothing as the person who requested the review has been notified
         that it has been performed

Regards,
-sm

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 15 Nov 2012 21:55:25 +1100

It appears that the mailing list isn't rewriting Return-Path -- this is AIUI good practice and necessary (for the reasons we see here, among others).

Cheers,

On 15/11/2012, at 9:48 PM, SM <[email-masked]> wrote:

> v=spf1 a:cloud.mnot.net a:mail.internode.on.net include:customer-spf.mxes.net -all
> 
> mnot.net is telling the raytheon.com that mail from mnot.net will only come from the hosts mentioned above.  The problem is the SPF record for mnot.net does not expect its messages from that domain to go through forwarders.
> 
> The alternatives are:
> 
> (i)   Change the "-all"
>

---

From: SM <[email-masked]>
Date: Thu, 15 Nov 2012 03:47:27 -0800

Hi Mark,
At 02:55 15-11-2012, Mark Nottingham wrote:
>It appears that the mailing list isn't rewriting Return-Path -- this 
>is AIUI good practice and necessary (for the reasons we see here, 
>among others).

The issue has been discussed in the SPFBIS WG (see Issue #12).  It is 
mentioned in the minutes ( 
http://tools.ietf.org/wg/spfbis/minutes?item=minutes-83-spfbis.html 
).   There was also discussion on the mailing list ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg02207.html 
).  Discussions about the practice tend to be controversial.

Regards,
-sm

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 15 Nov 2012 22:56:59 +1100

Well, it appears to be a requirement of RFC4408, section 9.2, unless that's been superseded. Are we not bothering to follow our own advice?

On 15/11/2012, at 10:47 PM, SM <[email-masked]> wrote:

> The issue has been discussed in the SPFBIS WG (see Issue #12).  It is mentioned in the minutes ( http://tools.ietf.org/wg/spfbis/minutes?item=minutes-83-spfbis.html ).   There was also discussion on the mailing list ( http://www.ietf.org/mail-archive/web/spfbis/current/msg02207.html ).  Discussions about the practice tend to be controversial.
> 
> Regards,
> -sm

---

From: SM <[email-masked]>
Date: Thu, 15 Nov 2012 07:56:56 -0800

Hi Mark,
At 03:56 15-11-2012, Mark Nottingham wrote:
>Well, it appears to be a requirement of RFC4408, section 9.2, unless 
>that's been superseded. Are we not bothering to follow our own advice?

As mention in the IESG Note RFC 4408 did not go through IETF 
review.  Section 9 of that RFC is labelled as non-normative.  There 
are diverging opinions about draft-ietf-spfbis-4408bis and some of 
the advice in it.

Regards,
-sm

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 16 Nov 2012 08:17:16 +1100

Well, consider this to be technical input -- the mailing list breaks when you don't do Return-Path rewriting. 

People can have all of the opinions they want :)

On 16/11/2012, at 2:56 AM, SM <[email-masked]> wrote:

> As mention in the IESG Note RFC 4408 did not go through IETF review.  Section 9 of that RFC is labelled as non-normative.  There are diverging opinions about draft-ietf-spfbis-4408bis and some of the advice in it.
> 
> Regards,
> -sm

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 16 Nov 2012 13:51:20 +0100

Hi Mark,

I've turned on envelope-from rewriting.  I've had this set up for quite
some time, but got bogged down in getting it announced.  Now it seems to
me that delaying it has a larger downside than the surprises that may
result from turning it on.

Best regards,

	Henrik

On 2012-11-15 22:17 Mark Nottingham said:
> _______________________________________________
> Tools-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-discuss
>

---

From: Dave Crocker <[email-masked]>
Date: Fri, 16 Nov 2012 06:58:07 -0800

> People can have all of the opinions they want :)

Let me get this straight:

      YOUR organization sets the -all value to SPF, which has a 
particular meaning that is extremely well-known to break when a message 
goes through a mailing list.  By 'well-known' I mean that it's at the 
core of SPF's design limitation, which is why SPF is typically referred 
to as a path-based mechanism.  Simply put, your sending through a 
mailing list explicitly violates the semantics of -all.

      However you are asserting that it is the responsible of a 
well-behaved intermediary to change, rather than your own organization's 
configuration, which is the configuration that is actually causing the 
failure?

This is all quite typical of email's history, of course, with operations 
down the handling sequence being expected to change for misbehaviors at 
the source.

It's going to be interesting to see what you demand when your 
organization publishes a similarly inappropriate DMARC record, which 
requires alignment between the rfc5322.From field and SPF and/or DKIM 
records.  Will you require that the From: field now be falsified?

      For the specific problem cited in this thread, you need
      to change your SPF configuration.

That said, the rfc5321.MailFrom field is typically best set to the 
latest posting agent, so that error messages go to the operator most 
likely to be able to do something about them. (Mailing lists post a new 
message.

The fact that it looks quite similar to a message that was "delivered" 
to it -- sufficiently similar to permit replying back to the original 
poster -- is convenient.  But in terms of email handling. the list takes 
final delivery of a message -- the one with the SPF record, for example 
-- and posts a new one.

d/

ps. SM is, of course, correct that the currently-published version of 
SPF is listed as experimental, not standards track.  But the problem 
cited in this thread does not get better, worse or different when SPFbis 
is published:  Mark's organization is configured wrong.  To be explicit 
and repetition:  That's not "opinion"; it's at the core of SPF semantics.

-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

---

From: SM <[email-masked]>
Date: Fri, 16 Nov 2012 08:17:05 -0800

Hi Dave,
At 06:58 16-11-2012, Dave Crocker wrote:
>ps. SM is, of course, correct that the currently-published version 
>of SPF is listed as experimental, not standards track.  But the 
>problem cited in this thread does not get better, worse or different 
>when SPFbis is published:  Mark's organization is configured

I made a mistake which I did not try to correct; the rejection 
message mentioned "PRA".  I agree that the the problem won't be 
better or worse.  I would have commented more if there wasn't a 
working group discussing about the specification.

Regards,
-sm

---

From: Dave Crocker <[email-masked]>
Date: Fri, 16 Nov 2012 08:26:37 -0800

On 11/16/2012 8:17 AM, SM wrote:
>But the problem
>> cited in this thread does not get better, worse or different when
>> SPFbis is published:  Mark's organization is configured
>
> I made a mistake which I did not try to correct; the rejection message
> mentioned "PRA".  I agree that the the problem won't be better or
> worse.  I would have commented more if there wasn't a working group
> discussing about the specification.

I cannot emphasize enough that I think the status of the document and 
the existence of the working group are actually irrelevant to the 
reported problem.  The technical and operational point at issue here is 
fundamental to the design and semantic of SPF.  No status change or 
working group topic under consideration has or will have any effect on 
the problem.  To alter the basic problem would require fundamentally 
changing SPF.

A sending site is using SPF.  The sending site is publishing a record 
that does not work for the scenario being created by the sending site. 
All of the problem is with and by the sending site.

Get rid of the -all.

d/

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 17 Nov 2012 23:08:05 +1100

No need to get snippy, Dave - I was just reporting something that didn't work.  I don't have the time, energy or inclination to get in the middle of e-mail standardisation fights, as much as others may enjoy them.

Regards,

On 17/11/2012, at 1:58 AM, Dave Crocker <[email-masked]> wrote:

>     YOUR organization sets the -all value to SPF, which has a particular meaning that is extremely well-known to break when a message goes through a mailing list.  By 'well-known' I mean that it's at the core of SPF's design limitation, which is why SPF is typically referred to as a path-based mechanism.  Simply put, your sending through a mailing list explicitly violates the semantics of -all.
> 
>     However you are asserting that it is the responsible of a well-behaved intermediary to change, rather than your own organization's configuration, which is the configuration that is actually causing the failure?
> 
> 
> This is all quite typical of email's history, of course, with operations down the handling sequence being expected to change for misbehaviors at the source.
> 
> It's going to be interesting to see what you demand when your organization publishes a similarly inappropriate DMARC record, which requires alignment between the rfc5322.From field and SPF and/or DKIM records.  Will you require that the From: field now be falsified?
> 
> That said, the rfc5321.MailFrom field is typically best set to the latest posting agent, so that error messages go to the operator most likely to be able to do something about them. (Mailing lists post a new message.
> 
> The fact that it looks quite similar to a message that was "delivered" to it -- sufficiently similar to permit replying back to the original poster -- is convenient.  But in terms of email handling. the list takes final delivery of a message -- the one with the SPF record, for example -- and posts a new one.
> 
> d/
> 
> ps. SM is, of course, correct that the currently-published version of SPF is listed as experimental, not standards track.  But the problem cited in this thread does not get better, worse or different when SPFbis is published:  Mark's organization is configured wrong.  To be explicit and repetition:  That's not "opinion"; it's at the core of SPF semantics.
> 
> -- 
> Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Sun, 18 Nov 2012 07:18:45 -0800

On 11/17/2012 4:08 AM, Mark Nottingham wrote:
> No need to get snippy, Dave - I was just reporting something that
> didn't work.  I don't have the time, energy or inclination to get in
> the middle of e-mail standardisation fights, as much as others may
> enjoy them.

Sure there is.  You did not 'just report' a problem.  Your series of
notes claimed a diagnosis and cure, citing a purportedly controlling spec.

However is an unreviewed Experimental spec which purports to have an SPF 
publisher dictate behaviors on typically unsuspecting intermediaries -- 
they can't be expected to know or care about SPF, nevermind conform to 
its random dictates.  In other words, the normative
bit you cited in RFC4408 is simply silly.  It's silly in a pretty
classic way, by virtue of misunderstanding what its scope of control is,
but that merely increases the silliness, IMO.

For reference, the current IETF working group to revise that spec has
eliminated such arrogance from the spec.  But that spec, too, isn't
approved yet.

The more interesting citation is RFC 5321 which attempts to dictate the
rfc5321.MailFrom modification, for the same reason I cited in my snippy 
note:  to make it more likely that a responsible agent will get informed 
of a problem.  However also as I observed in my snippy note, the 
underlying operational philosophy that is represented by the thread 
doesn't scale:  for example, the same diagnostic and repair model will 
not work when applied to a sender's misuse of DMARC.

Concerning this portion of RFC5321, there is a basic problem:
Operationally, plenty of mailing lists do not change the
rfc5321.MailFrom.  When there is sufficiently widespread non-conformance
to a long-standing standard, the problem is with the standard, not the
non-conformance.

d/

ps.  As snippiness goes, mine was pretty mild here. We've both been
around the IETF long enough to have experience with what less mild looks 
like...