Subject: Re: [spfbis] Proposed Section 7 update

From: Alessandro Vesely <[email-masked]>
Date: Sat, 01 Sep 2012 18:16:44 +0200

On Fri 31/Aug/2012 20:51:30 +0200 Scott Kitterman wrote:
> On Friday, August 31, 2012 10:39:19 AM Murray S. Kucherawy wrote:
>> For example:
>> 
>> <Scott's example of A-R use here>
> 
> I think (with the RECOMMENDED change already discussed upstream) this is 
> pretty good.  Can we squeeze the suggestion to use the SPF-Received key-value-
> list to add details to A-R into here?  I don't think it needs to be more than 
> 'here's a reasonable way to do it', but I'd like to at least suggest something 
> if people want to go down this path (and it helps support the example, which 
> does exactly that).

I dislike suggesting a kludge as 'a reasonable way to do it'.  I know
that examples are not normative, but that one is likely the single one
example of A-R usage that we are going to give, hence its value is
almost that of a SHOULD, RFC 2119 notwithstanding.  *Standardizing
kludges is evil*.  If the forensics data that Received-SPF: conveys is
what is wanted, then use that field, period.

For the security aspect, I already mentioned the solution of renaming
existing fields to Old-Received-SPF before adding new ones:
http://www.ietf.org/mail-archive/web/spfbis/current/msg01029.html
The package implementing that is in multiple Linux distributions, so
it can be considered widespread, no?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 2 Sep 2012 11:50:08 -0700

On Sat, Sep 1, 2012 at 9:16 AM, Alessandro Vesely <[email-masked]> wrote:
> almost that of a SHOULD, RFC 2119 notwithstanding.

I don't agree with that claim at all.  However, I'm not going to
object if we were to dump the example of how to shoe-horn Received-SPF
into Authentication-Results.

> If the forensics data that Received-SPF: conveys is

We do say that.

> it can be considered widespread, no?

Maybe, but isn't it easier to refer to published security text rather
than introduce yet another "to solve problem X, you could do something
like Y"?

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 03 Sep 2012 01:32:13 -0400

On Saturday, September 01, 2012 06:16:44 PM Alessandro Vesely wrote:
> > pretty good.  Can we squeeze the suggestion to use the SPF-Received
> > key-value- list to add details to A-R into here?  I don't think it needs
> > to be more than 'here's a reasonable way to do it', but I'd like to at
> > least suggest something if people want to go down this path (and it helps
> > support the example, which does exactly that).
> 

What kludge?  A-R has optional fields and room for comments, so I don't see 
anything kludgy about suggesting a way to fill them out.

> it can be considered widespread, no?

What package?

Generally, I think if you trust the header you should leave it untouched and 
if you don't you should probably remove it.  I don't see value in leaving 
untrusted content.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 03 Sep 2012 11:06:59 +0200

> than introduce yet another "to solve problem X, you could do something

RFC 5451 not only has Section 7.1, it also relies on Section 5.  I see
two difficulties in transporting that semantics as-is:

The first one is formal, as the spec there does not provide a general
algorithm for ensuring authenticity of any trace field, but is
specific to A-R.  Simply saying "do with Received-SPF: the same that
RFC 5451 specifies for Authentication-Results:" is rather vague.

The second difficulty is backward compatibility.  Existing verifiers
may not bother setting a "receiver" tag at all in the Recaived-SPF:
they generate, or they may set it to a value not compatible with the
trustworthiness determination specified by Section 5 of RFC 5451.

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 03 Sep 2012 11:07:04 +0200

> anything kludgy about suggesting a way to fill them out.

Just recall the history of stuffing data into Received:.

If you still don't see it, consider:

   MIME-Version: 1.0
   X-AV-Checked: ClamAV using ClamSMTP
   Subject: Re: [spfbis] Proposed Section 7 update
   X-BeenThere: [email-masked]
   X-Mailman-Version: 2.1.12
   Precedence: list
   List-Id: SPFbis discussion list <spfbis.ietf.org>
   List-Unsubscribe: <https://www.ietf.org/mailman/options/spfbis>,
      <mailto:[email-masked]?subject=unsubscribe>
   List-Archive: <http://www.ietf.org/mail-archive/web/spfbis>
   List-Post: <mailto:[email-masked]>
   List-Help: <mailto:[email-masked]?subject=help>
   List-Subscribe: <https://www.ietf.org/mailman/listinfo/spfbis>,
      <mailto:[email-masked]?subject=subscribe>

How about stuffing that into an A-R instead of using each header field
for the value(s) that belong to it?  E.g. like so:

   MIME-Version: 1.0
   X-AV-Checked: ClamAV using ClamSMTP
   Subject: Re: [spfbis] Proposed Section 7 update
   Authentication-Results: some.host.example;
      auth=none reason="X-BeenThere:[email-masked]<CRLF>X-Mailma
      n-Version:2.1.12<CRLF>Precedence:list<CRLF>List-Id:SPFbis d
      iscussion list<spfbis.ietf.org><CRLF>List-Unsubscribe:<http
      s://www.ietf.org/mailman/options/spfbis>,<CRLF><mailto:spfb
      [email-masked]?subject=unsubscribe><CRLF>List-Archive:
      <http://www.ietf.org/mail-archive/web/spfbis><CRLF>List-Pos
      t:<mailto:[email-masked]><CRLF>List-Help: <mailto:spfbis-r
      [email-masked]?subject=help>List-Subscribe: <https://www.i
      etf.org/mailman/listinfo/spfbis>,<CRLF><mailto:spfbis-reque
      [email-masked]?subject=subscribe>"

>> it can be considered widespread, no?

Courier-MTA.  How do other packages tackle that problem?

> if you don't you should probably remove it.  I don't see value in leaving 

More precisely, you should trust your border MTAs only.  However, the
SPF results obtained by a non-suspect external host can be handy if
you happen to manually inspect the header of a forwarded message.

---

From: Hector Santos <[email-masked]>
Date: Mon, 03 Sep 2012 08:08:01 -0400

It seems there is too drama regarding A-R and trying to add it. It 
drastically alter scope of SPF with ACCEPT+MARK mode of receiver 
behavior, it created new security issues and conflicts of major 
opinion almost surely to raise WGLC issues.

SUGGESTION:  Remove A-R from 4408BIS and all related changes due to it 
and if we someone believes it is still useful for SPF, then write a 
I-D for it, perhaps with a title

               Reporting SPF with Authentication-Results

and this I-D can go into extensive concepts of not only how to write 
it, but perhaps also how to combine it with other A-R marking for 
receiver evaluations, etc.

Alessandro Vesely wrote:
> _______________________________________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis
> 
> 

-- 
HLS

---

From: "John Levine" <[email-masked]>
Date: 4 Sep 2012 10:44:38 -0000

>anything kludgy about suggesting a way to fill them out.

Haven't we been through this already?  The point of a standard is to
let people write software that interoperates.  When RFC 5451 says
something is a comment, that means that software that implements 5451
doesn't interpret it.  Trying to hide stuff in an uninterpreted field
is a kludge.

Updating 5451 to add more fields to report the stuff that's in
Received-SPF is a reasonable idea, but this is neither the place nor
the method to do it.

Editorial nit: sec 7.2 says SPF-Received where it should say Received-SPF.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 4 Sep 2012 11:52:28 -0700

On Mon, Sep 3, 2012 at 5:08 AM, Hector Santos <[email-masked]> wrote:
> drastically alter scope of SPF with ACCEPT+MARK mode of receiver behavior,
> it created new security issues and conflicts of major opinion almost surely
> to raise WGLC issues.

Since Received-SPF does effectively the same thing, adding references
to A-R is neither an alteration in scope nor "drastic".

On the contrary, it would be prudent for the IESG to ask why we're
ignoring a message annotation that's already a proposed standard
specifically geared toward this kind of work.  Failing to at least
acknowledge the existence of A-R would be suspect if I were the one
evaluating it.

> SUGGESTION:  Remove A-R from 4408BIS and all related changes due to it and
> if we someone believes it is still useful for SPF, then write a I-D for it,
> perhaps with a title
>
> and this I-D can go into extensive concepts of not only how to write it, but
> perhaps also how to combine it with other A-R marking for receiver
> evaluations, etc.

RFC5451 already did all of that.

-1 to this suggestion.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Thu, 06 Sep 2012 05:07:29 -0400

> acknowledge the existence of A-R would be suspect if I were the one

Thats all possible.  But it does drastically alter the scope of SPF 
when A-R is considered. I can verify because we are going thru it now 
with the SPFBIS updating code reviews and I have new reservations 
about it until it can be completely be scoped out.  Its not would not 
be PnP (plug and play) update

I should note I fundamentally agree with you, and thus why I supported 
the A-R consideration but only as a migration with local processing 
semantics. I will always support single sourcing concepts such as this 
especially when similar applications are begun.  In this case, 
DKIM/ADSP was officially added/completed into the production code and 
released few years ago.

But SPF is a 5321 technology, not a payload technology like DKIM/ADSP. 
  So one of the first thing you need to internally consider is the 
integration such as SPF now being the first time the A-R is added and 
now changes to the DKIM/ADSP code has to be done to make sure it 
aggregates it (i.e. append/prepend concepts with other transaction 
mail protocol stuff going on).

Also, and extremely important IMO is issue #33.  Products not 
currently designed around mark-on-fail and perhaps now wish to update 
with SPFBIS and now with the synergism behind DKIM/ADSP, add support 
for delayed reporting/rejections/filtering with Mark-On-Fail are in 
for a rude surprise - its not going to be very easy to do this.

So as I stated, there new emphasis to add A-R does bring with it a new 
scope of considerations, such as issue 33 and just getting the 
integration right with other things.

It is easily now because Received-SPF only has one specific purpose 
and applicability.  No other method   or technology deals with it.

IMO, its not that simple of a replacement and I believe the IESG will 
take this engineering implementation issues into account. Its not a 
PnP suggestion to replace Received-SPF with A-R.

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 6 Sep 2012 07:13:32 -0700

On Thu, Sep 6, 2012 at 2:07 AM, Hector Santos <[email-masked]> wrote:
> IMO, its not that simple of a replacement and I believe the IESG will take
> this engineering implementation issues into account. Its not a PnP
> suggestion to replace Received-SPF with A-R.

There is nothing in the new Section 7 text that proposes replacing
Received-SPF with A-R.  A-R is being presented as an alternative.
Implementers can use one or the other, or both, or neither, or
something else entirely.  The new Section 7 only says it's RECOMMENDED
that you not choose the "neither" option, which is what it said all
along.  That means you, as someone who prefers Received-SPF, don't
need to change a thing.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 06 Sep 2012 10:16:37 -0400

> along.  That means you, as someone who prefers Received-SPF, don't

That's correct.  Also, since RFC 5451 exists and documents reporting SPF 
results in A-R, no matter what we do in 4408bis, it's there and implementers 
have to decide how to deal with it, if at all.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Thu, 06 Sep 2012 12:32:27 -0400

> along.  That means you, as someone who prefers Received-SPF, don't

I have no issues with A-R support. As I had stated, from a SE 
standpoint, single sourcing is a very strong SE premise with us. We 
are a systems, apps level tools developer as well and its not just 
site deployment.  SPF is part an of API for stock components and for 
operator and ISV programmability.

I am pointing out what are some implementation issues which IMV are 
underestimated, however I believe as long the entire scope is reviewed 
then we can not minimize the impact of this SPFBIS "new enhancement" 
feature, help promote its usage and also provide equal weight to 
providing Mark-On-Fail operations rather than Reject-On-Failure.

I am not convince that Reject-On-Fail is not a high mode of operation. 
  It all depends on the site - does it serve the public user market or 
is it a private user enterprise?

There are a few little things here and I should probably offer text to 
illustrate the implementation points. To outline some of the insights:

   - Adding both Received-SPF and A-R for maximum consumer support.
      - Disable Receiver-SPF by default with option to enable again.

   - Combining meta A-R SPF results with any current or pending meta 
A-R headers
     generation for a final single prepending to the stored message.

     - the main point is to avoid the propensity to create multiple 
A-R for
       the same hop.

   - Add/Change examples using "fail" results  to others like 
softfail, etc
     to help illustrate and show where A-R can have an benefit with 
augmented
     aggregated A-R factors in an advanced MFA (Mail Filtering Agent).

     - Using "Fail" results for examples should include engineering 
insights
       the A-R result made not be possible to exist since the transaction
       can (and may) be rejected outright per section 2.5.4.

     - Insights towards the issue #33 security note when A-R fail results
       are recorded.

The above is off the top of my head.

-- 
HLS

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 07 Sep 2012 09:48:28 +0200

On Thu 06/Sep/2012 16:13:32 +0200 Murray S. Kucherawy wrote:
> something else entirely.

+1, that is a clean, plain view.  It supports all the implementation
points that Hector illustrated.

> The new Section 7 only says it's RECOMMENDED that you not choose
> the "neither" option, which is what it said all along.  That means
> you, as someone who prefers Received-SPF, don't need to change a
> thing.

RFC 5451, Section 2.4.2 in particular, fully describes how to use A-R
fields for SPF.  Hence, issue #51 can be closed.  The only one reason
why 4408bis needs to mention A-R at all is the above normative point.
 That is, an implementation that sets A-R only can be said to follow
that 4408bis recommendation.

I propose the following clarification attempt, if it can be useful for
-07:

   Implementations are expected to add either any of these header
   fields or both depending on the requirements of the downstream
   message processors that they support.  Such choice could possibly
   depend also on the result itself, because reporting "none" is
   somewhat less interesting than reporting "pass" or "fail".  Note
   that errors, as well as the negative results can also be reported
   to the publishing domain, according to [RFC6652].