Subject: [spfbis] Fwd: New Version Notification for draft-ietf-spfbis-4408bis-09.txt

From: Scott Kitterman <[email-masked]>
Date: Tue, 15 Jan 2013 22:51:13 -0500

This is the joint reorg draft that Murray and I were supposed to do based on 
the last meeting (as confirmed on the list).  I stuck to his outline and kept 
the text changes to either editorial changes or the text needed to glue 
different parts together in the new organization.

There are two things I didn't do from Murray's draft that I'd propose for -10 
and will do unless anyone objects:

Combine Appendix H and Appendix I.

Add this security consideration:

11.7.  Delivering Mail Producing a 'Fail' Result	 		
 		
   Operators that choose to deliver mail for which SPF produces a "fail"	 		
   result need to understand that they are admitting content that is	 		
   explicitly not authorized by the purported sender.  While there are	 		
   known failure modes that can be considered "false negatives", the	 		
   distincg choice to admit those messages increases end-user exposure	 		
   to likely harm.  This is especially true for domains belonging to	 		
   known good actors that are typically well-behaved; unauthorized mail	 		
   from those sources might well be subjected to much higher skepticism	 		
   and content analysis.	 		
 		
   SPF does not, however, include the capacity for identifying good	 		
   actors from bad ones, nor does it handle the concept of known actors	 		
   versus unknown ones.  Those notions are out of scope for this	 		
   specification.

Then it's back to the regularly scheduled work on open issues:

http://trac.tools.ietf.org/wg/spfbis/trac/report/1

Scott K
----------  Forwarded Message  ----------

Subject: New Version Notification for draft-ietf-spfbis-4408bis-09.txt
Date: Tuesday, January 15, 2013, 07:44:36 PM
From: [email-masked]

A new version of I-D, draft-ietf-spfbis-4408bis-09.txt
has been successfully submitted by Scott Kitterman and posted to the
IETF repository.

Filename:	 draft-ietf-spfbis-4408bis
Revision:	 09
Title:		 Sender Policy Framework (SPF) for Authorizing Use of Domains in 
Email, Version 1
Creation date:	 2013-01-15
WG ID:		 spfbis
Number of pages: 73
URL:             http://www.ietf.org/internet-drafts/draft-ietf-
spfbis-4408bis-09.txt
Status:          http://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis
Htmlized:        http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-09
Diff:            http://www.ietf.org/rfcdiff?url2=draft-ietf-spfbis-4408bis-09

Abstract:
   Email on the Internet can be forged in a number of ways.  In
   particular, existing protocols place no restriction on what a sending
   host can use as the "MAIL FROM" of a message or the domain given on
   the SMTP HELO/EHLO commands.  This document describes version 1 of
   the Sender Policy Framework (SPF) protocol, whereby an ADMD can
   explicitly authorize the hosts that are allowed to use its domain
   names, and a receiving host can check such authorization.

   This document obsoletes RFC4408.

The IETF Secretariat

-----------------------------------------

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 15 Jan 2013 23:11:30 -0500

Dear colleagues,

> and will do unless anyone objects:

[…]

Please register any such objections in the next few days, so that we
can proceed with the WG effort.  It's hard to see what would be
objectionable about those proposals, so we do not want to waste a lot
of time on waiting.  We'd like to resume the earlier pace that the WG
achieved, and finish up the document in good time.

Best regards,

Andrew (as chair/goad)

-- 
Andrew Sullivan
[email-masked]

---

From: John Leslie <[email-masked]>
Date: Wed, 16 Jan 2013 07:12:09 -0500

>    versus unknown ones.  Those notions are out of scope for this

   This seems to blame operators too much, IMHO, for a practice their
customers demand. A possible re-working:
"
" Many operators have found that email for which SPF produces a "fail"
" result is nonetheless email which end-users depend upon receiving,
" and deliver it despite the "fail" result. This practice is permitted.
" There are things the end-user can do which will distinguish SPF
" "fail" email which they do want from SPF "fail" email they don't
" want.
" 
" Nonetheless, there are SPF publishers that really want an SPF "fail"
" to prevent delivery. SPF does not and cannot promise that. However,
" both operators and end-users should clearly understand that most
" SPF "fail" emails deserve to be rejected, and a significant number
" of them can cause harm. SPF "fail" emails from senders which are
" typically well-behaved probably deserve much higher skepticism
" and automated content-analysis.

   (I don't feel especially strongly about this. Use as you see fit.)

--
John Leslie <[email-masked]>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 16 Jan 2013 15:06:05 -0800

Operators are ultimately the ones that implement local policy, so I think
it's reasonable to place the focus there.  It's unlikely that end users
will read this and/or try to understand it.  That said, I don't have a
problem with the alternative text proposed by John.

I think the point in the last paragraph of the proposed 11.7 needs to
remain, however.

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 17 Jan 2013 11:35:49 +0100

On Wed 16/Jan/2013 13:12:09 +0100 John Leslie wrote:
>>    explicitly not authorized by the purported sender.

Good. I'd s/purported sender/identified ADMD/.

>>    While there are
>>    to likely harm.

Usually, a false positive is a false alarm, whereas a failure to
notice a malicious attempt would be called a false negative.  We may
point out that for SPF that is reversed, since failed authorizations
are marked with a negative sign...  But can't we avoid such parlance
and be specific?  For example:

   While there are known transfer modes, such as forwarding, whereby
   legitimate mail can get a "fail" result, indiscriminately admitting
   non-authorized messages increases end-user exposure to likely harm.

>>    This is especially true for domains belonging to

Fluffy...

>>    versus unknown ones.  Those notions are out of scope for this

Right.  But reversing that argument makes it constructive.  Consider:

   In such cases, the ability to discern good actors from bad ones
   has to be found in tools different from SPF.

> " and deliver it despite the "fail" result. This practice is permitted.

That sounds like "don't be fooled into rejecting messages just because
they got a fail".  I don't think such advice is necessary.

The purpose of this security consideration is to warn operators that
by delivering such messages they place themselves on the side of the
actual sender, so they had better make sure it is a good actor before
doing so.

> " of them can cause harm.

That seems correct, possibly except numerical considerations.  But
then end-users don't happen to notice SPF results...

> " SPF "fail" emails from senders which are

"Senders" is ambiguous in that context.  You mean the identified ADMD,
not the actual sender, don't you?