Subject: [spfbis] IETF83 SPFBIS minutes - Version 0.1

From: S Moonesamy <[email-masked]>
Date: Sun, 22 Apr 2012 16:21:31 -0700

The SPFBIS WG held a meeting at IETF83.  This is Version 0.1 of the 
minutes.  Please email me if there are any changes.

SPF Update Working Group Minutes

Meeting : IETF83, Friday 30 March, 2012
Location: Paris, 09:00 to 11:00
Chairs  : Andrew Sullivan <[email-masked]>
Minutes : John Levine
	     Version 0.1

AGENDA

  A. Meeting Administrivia
     Note well
     Agenda bashing
  B. RFC 4408 issues
  C. SPF RR Type and TXT RR (issue #9)
  D. DNS amplification attacks
  E. Is a deployment document needed
  F. Path authorization/updating SMTP
  G. Adoption of
       draft-kucherawy-spfbis-experiment-03
       describing the SPF/Sender-ID experiment
       and discussion
  H. Any Other Business

A. Meeting Administrivia

Andrew Sullivan chaired the IETF83 SPFBIS Working Group meeting in 
Paris, France.  John Levine was the scribe and Murray S. Kucherawy 
and Tony Hansen were the Jabber scribes.  There were 20 people in the room.

The Chair brought the Note Well to the attention of the meeting 
participants, asked them to sign the blue sheets, bashed the agenda.

B. RFC 4408 issues

RFC 4408 issues are listed at 
http://trac.tools.ietf.org/wg/spfbis/trac/report/1

Issue #5 is about some ambiguities in the specification.

Issue #7, #8 and #16 are there to be tracked. The working group will 
work on text once it has adopted a draft.  Issue #15 is about MAIL 
FROM.  Some of the issues have not been opened for discussion on the list yet.

Issue #18 is about adding a SMTP code.  It is not clear whether it is 
within the charter.

The Chair mentioned that SERVFAIL is not an error in DNS.

Scott Kitterman asked via Jabber how can we know whether we are done 
if there is no text to agree on.  The Chair explained that the basic 
idea is that once substantive discussion is done, what needs to be 
done is to agree on text.  Arguing on the details of the text is 
easier once the working group agrees on what it wants to say.

The Chair mentioned that errata have to be addressed in a bis 
document and that it is straight-forward.

Issue #4 was ruled as out of scope.  There wasn't any objection.

The Chair asked the floor for opinions about Issue #10 which is about 
replacing the Received-SPF: header.  Scott Kitterman commented that 
it cannot be deprecated as there are still people using them.  Tony 
Hansen explained that deprecation means not to use it in future 
implementations as it will go away at some point, it does not mean 
that it is no longer supported in the specification.  There were two 
people in the Jabber room in favor of deprecating and using the 
Authentication-Results: header.  Doug Otis commented on having the IP 
address in Authentication-Results: like Received-SPF: does.

The Chair called for a hum for:

  (i)  Received-SPF is deprecated

  (ii) Not to do anything about Received-SPF:

The hum favored deprecation.  As somebody was not in favor of 
deprecation, the Chair asked for the person to explain 
why.  Alessandro Vesely considered that deprecation is the wrong 
word.  The Chair clarified that if people believe that the header is 
useful,it should stay, otherwise, it should go away.  Alessandro 
Vesely stated thyat it should go away but it should be deprecated for 
servers and not for clients.  Scott Kitterman mentioned that things 
can be deprecated for a long time before they actually get removed; 
the working group could state a preference.  S. Moonesamy, as an 
individual, commented that deprecation can be done by clients not 
sending it but receivers supporting it, meaning that things will 
continue parsing the header for some time.

The Chair pointed out that there were three possibilities on the table:

  (i)  Servers complain but clients continue to use it

  (ii) Clients keep sending it but servers do not say anything when 
they get one

  (iii) We just deprecate it and maybe people get warnings

Pete Resnick, as Area Director, asked for comments about the 
interoperability problem if people continued to use Received-SPF; 
i.e. what the problem with keeping it around is.  He asked that if 
there wasn't a problem with generating them, what's the use of 
deprecating them.  The idea was about long-term simplification.  John 
Levine mentioned that if you were allowed to generate both headers, 
they could disagree.

The Chair suggested that someone send their best arguments to the 
mailing list for deprecating and someone else sends arguments for 
deprecating.  The Chair also suggested that Doug Otis makes the 
argument for "do not deprecate, leave it alone" on the mailing list 
and Doug agreed.

Murray Kucherawy  commented on Issue #11 saying that check_host() 
looks awfully lot like an API whereas the IETF does not define 
APIs.  Pete Resnick, as Area Director, preferred to see the 
specification to be written in terms of semantics of the protocol 
elements rather than processing.  Murray Kucherawy volunteered to 
write a paragraph to mention that it is merely an illustration.

The discussion on the mailing list about Issue #13 was 
inconclusive.  The Chair asked whether Best -Guess SPF was in scope 
at all and if so what does the working group want to say about it, 
with the default being not to say anything.  Scott Kitterman pointed 
out that it was not left out of RFC 4408 by accident.  Murray 
Kucherawy argued that as there are places such as gmail.com which 
makes use of this, it would help to have some clarifying text about it.

Murray Kucherawy asked whether the IESG has an opinion about widely 
deployed or whether it only wants to see whetehr the working group 
did its homework.  The Chair commented that "widely deployed" can be 
done on a case by case basis and based on the Conclusions that the 
working group draws.  There wasn't any objections.

The Chair commented that he did not completely understand what the 
issue was with Issue #14.  Nobody argued that the working group must 
deprecate local-part macros.  The Chair closed the issue with "won't 
fix".  The Chair will reconsider the issue if there is text to go in 
the Security considerations section of the document.  John Levine 
pointed out that as there is only one person in favor of the 
argument, it should be closed.  The Chair stated that if there is a 
legitimate argument, it should go into the security considerations 
section.  John Levine revised a previous comment he made by pointing 
out that there are a vast number other of ways to generate an 
attack.  The Chair pointed out that SPF sucks does not belong in the 
document.

Pete Resnick, as Area Director, explained what he understood from the 
discussion of Issue #14: the working group sufficiently considered 
the issue and agreed not to deprecate the feature; it can add 
clarification in the Security Considerations section.  The Chair 
stated that the issue will be closed with "won't fix" and a new issue 
can be added saying that the working group will add text in the 
security considerations section.

Alessandro Vesely asked a clarifying question about whether a domain 
using local-part macros is badly administered.  Scott Kitterman 
objected to adding text about this issue in the Security 
Considerations section.  Pete Resnick, as Area Director, mentioned 
that he can object to the new issue and provide reasons for why the 
text should not be added.  Eliot Lear pointed out that the discussion 
was about two sentences which were non-normative where the risk does 
not even have to be characterized.

The Chair asked whether anyone would like to argue about Issue #16, 
in favor of relaxing the syntax checking.  As there were no 
arguments, the issue was closed with "won't fix".

Issue #16 is about the PTR mechanism.  There was support on the 
mailing list for adding "SHOULD NOT" text about this.  The issue was 
closed pending the new document.

C. SPF RR Type and TXT RR (issue #9)

The were people on the mailing list in favor of using the TXT RR 
appeared to be a modest majority and there were people who argued for 
SPF RR Type on the grounds of DNS hygiene.  The Chair explained that 
it appears as an empirical matter, overwhelmingly, the TXT RR is used 
but RRTYPE 99 does not qualify under the unused provision of the 
SPFBIS charter.  Dave Crocker mentioned that we have not had 
consensus about the definition of "unused" and pointed about that the 
definition is hugely required in this case.  Dave Crocker agreed with 
the Chair that there was little adoption of RRTYPE 99 and mentioned 
that functionally, after this many years, it is serving as cruft, it 
is redundant and offers no benefit after this long.  He suggested 
this also as one definition of "unused".

Tony Hansen asked whether any sites publishing RRTYPE 99 were found 
in the surveys done.  Murray Kucherawy pointed out that if this was 
the case, the position stated by Dave Crocker would be false.  The 
Chair reminded the working group about a comment from Scott Kitterman 
stating that if people were publishing RRTYPE 99 only, it is an 
indication of them not knowing what they were doing anyway.  Peter 
Koch suggested changing some of the experimental components into 
production if the experiment was successful.  It pointed out the 
working group does not own the TXT RR or the zone apex and it should 
probably keep that in mind.  He reminded the working group that there 
has been this humongous argument about deployed base within the 
IETF.  He considered it ill-advised to make decisions which may have 
long term consequences based on the results of the experiment 
only.  The Chair mentioned that the evidence suggests that SPF is 
widely deployed, likely more widely deplyed than IPv6.  Scott 
Kitterman mentioned that there was an interoperability issue which 
would have to be clarified.

Pete Resnick, as Area Director, in response to Peter Koch's comments, 
mentioned that in the deal with the IESG, as a general statement, the 
working can removed what is unused and put in what is widely 
deployed.  He pointed out that saying that TXT RR is part of an 
experiment is contrary to the agreement made with the IESG.  His 
opinion is that either way, the proposal is stuck with TXT RR and 
that it is not an issue.  The only issue is whether the proposal can 
remove the SPF RRTYPE as unused.

Eliot Lear did not see the point of keeping the SPF RRTPE given the 
results of the survey.  He mentioned that he did not hear a 
compelling technical argument for keeping the RRTYPE.  Murray 
Kucherawy suggested adding an appendix to the conclusion document 
about the experience in developing the RRTYPE given recent 
discussions on other IETF mailing lists. He proposed that it would be 
better if it was done as an IESG statement.  Pete Resnick, as Area 
Director, did not think that an IESG statement is appropriate.

The conclusion reached by the Chair was that the document will say 
SHOULD NOT publish RRTYPE 99 and MUST NOT query RRTYPE 99.

In the experiment result document that 166 out of 251,000 domains 
surveyed published only RRTYPE 99.  On a procedural point, the Area 
Director stated that he would like the working group to document that 
fact.  The IESG consider that fact should it come up in an appeal.

Tony Hansen commented that when you write a protocol, there is 
definite harm if there is a choice in what you publish and what you 
look for.  He is of the view that there is a definite bug in RFC 4408.

D. DNS amplification attacks

The Chair proposed that the working group asks the DNS Directorate 
whether there is a serious issue (#24) here because there has been 
previous analysis of this issue.  Peter Koch stated as a member of 
the DNS Directorate his preference for the question to be more open 
or more to the point.  He would like a little less ambiguity in the 
question; adding that a straight yes or no answer should not be 
expected.  The Chair commented that he was not expecting a straight 
answer; he would never expect a straight yes or no answer from 
anybody with any question having to do with DNS.

E. Is a deployment document needed

The Chair mentioned that he does not think the the charter allows for 
a deployment document.

The Chair asked for a three-way hum:

  1. Don't do anything at all and let someone else produce deployment guide

  2. Add some deployment notes as an appendix in the bis document

  3. Separate document

There was a little bit for 1, a tiny noise for 2 and a medium noise for 3.

Hector Santos commented that a deployment document may be outside the 
scope of the working group.  Dave Crocker suggested writing the text 
and figuring out where it should go and the Chair agreed.

F. Path authorization/updating SMTP

The Chair explained that this is mainly about mail forwarding (Issue 
#12) and that the discussion on the mailing list was completely 
inconclusive.  Alessandro Vesely  commented on the important of 
having forwarding procedures devised.  They Chair asked whether that 
was protocol advice or deployment advice.  Alessandro Vesely pointed 
out that the specification is not in accordance with the SMTP 
specification which mentions that one can forward while keeping the 
Return-path unaltered.  John Levine commented that SMTP is designed 
to deliver mail over whichever path is supposed to work and it can be 
argued that SPF is broken by design; SPF takes the practical path by 
assuming that all mail is delievred over a predictable path.  The 
Chair stated that this issue is deployment advice.  Alessandro Vesely 
did not object to the statement.

G. Adoption of draft-kucherawy-spfbis-experiment-03

draft-kucherawy-spfbis-experiment-03 was adopted as a working group 
I-D.  Due to a technical glitch in the datatracker, the filename of 
the draft could not be changed.  The Chair pointed out that there has 
not been any alternative proposal.

Murray Kucherawy gave a presentation of the document describing the 
SPF/Sender-ID experiment.
http://www.ietf.org/proceedings/83/slides/slides-83-spfbis-0.ppt

He will shortly have extensive data on published SPF 
records.  Several people commented on other material that might be 
reported, e.g., how often to checks succeed or fail, and how well do 
SPF and Sender-ID describe legitimate mail flows.  He will add some 
text.  The Chair noted that people who want this to move ahead need 
to help finish the experiment report.  There was a comment to add 
some methodology.

[This part is not extensive due to an audio cut]

H. Any Other Business

The meeting was adjourned at 10:17 a.m.

Regards,
S. Moonesamy

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 23 Apr 2012 13:37:05 +0200

On Mon 23/Apr/2012 13:08:19 +0200 S Moonesamy wrote:
>
> As somebody was not in favor of deprecation, the Chair asked for
> the person to explain why. Alessandro Vesely considered that
> deprecation is the wrong word.  The Chair clarified that if people
> believe that the header is useful,it should stay, otherwise, it
> should go away.  Alessandro Vesely stated thyat it should go away
> but it should be deprecated for servers and not for clients.  Scott
> Kitterman mentioned that things can be deprecated for a long time
> before they actually get removed; the working group could state a
> preference.  S. Moonesamy, as an individual, commented that
> deprecation can be done by clients not sending it but receivers
> supporting it, meaning that things will continue parsing the header
> for some time.

What I meant to say is that it is the servers who should deprecate
Received-SPF, so that their clients stop checking it and check
Authentication-Results instead.  That is, 4408bis can recommend that
servers deprecate the old field while they add the new.

>  (ii) Clients keep sending it but servers do not say anything when

Is it me or "server" and "client" were meant w.r.t. the header field
usage, rather than SMTP?

> John Levine mentioned that if you were allowed to generate both
> headers, they could disagree.

Yup, there will have to be a "MUST agree at least on the results"
(could disagree on the authserv-id, though).

> deprecating.

There are no arguments for _not_ deprecating ;-)

---

From: S Moonesamy <[email-masked]>
Date: Mon, 23 Apr 2012 08:35:55 -0700

Hi Alessandro,
>servers deprecate the old field while they add the new.

I'll go over the audio again before making the correction you suggested.

>Is it me or "server" and "client" were meant w.r.t. the header field

See above.

>There are no arguments for _not_ deprecating ;-)

Ok.  We won't have to spend more time on this issue if everyone 
agrees to the above.

Please note that it is appropriate to suggest corrections to the 
minutes through this mailing list if you believe that it does not 
reflect what was discussed during the meeting.

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Mon, 23 Apr 2012 17:57:04 -0700

Hi Alessandro,
>servers deprecate the old field while they add the new.

I edited the text and added the above.

>Is it me or "server" and "client" were meant w.r.t. the header field

This part was for a three-way hum (questions asked by the 
Chair).  I'll keep it as it is as the results of the hum are below that text.

I don't fully understand the question you asked.  I'll ask my 
co-chair about this once the final minutes are done.

If anyone in this working group wants to object the following they 
can contact the WG Chairs or the Responsible Area Director.  I gather 
that English is not your native language.  You can expect more 
leeway. :-)  It is fine with me if you raise objections or ask for 
clarification if you do not understand something I said.

Regards,
S. Moonesamy

---

From: Hector Santos <[email-masked]>
Date: Mon, 23 Apr 2012 23:11:19 -0400

S Moonesamy wrote:

> scope of the working group.  Dave Crocker suggested writing the text and 
> figuring out where it should go and the Chair agreed.

I don't believe that was I stated. If that is how it was scribed, it 
was not my intent to say it would be out of scope. Thats because very 
early on in the SPFBIS, offlist, I proposed the to AD if I could write 
a deployment guide as I saw it might be useful. So it wasn't much 
about being out of scope because I already believed in an integrated 
solution.  My version of a SPFBIS deployment would be to focus on 
existing SPF methods, SPF + SIDF + SUBMITTER, a "How To Guide" and 
also help address the cited conflicts in DNS record conflicts, better 
describe lookup for dual TXT/99 and also perhaps offer a way to 
"inject" DKIM/ADSP into the picture since there has been cited 
interest in the area of SPF SOFTFAIL plus ADSP.

However, realistically if a deployment was agreed I would not be the 
editor and the concern was how an fast track Information RFC could be 
used to change the scope of the SPFBIS charter with DKIM and other new 
methods and that is based on the experience with DKIM WG and how the 
Informational DKIM Deployment Guide helped change and reshaped 
DKIM-BIS as a Reputation based design despite the face Reputation as 
an out of scope in the DKIM charter. I did not wish to experience this 
again using an SPFBIS Deployment injected integrated methods like 
DKIM, REPUTATION and overall, replaced SIDF and end up with a less 
deterministic mail filtering model it offers today.

While I not at all adverse to good solid integrated designs, the 
concern was how it change the SPFBIS WG focus towards MARKING instead 
of REJECTION for FAIL policy results.  See below.

> replacing the Received-SPF: header.  Scott Kitterman commented that it 
> cannot be deprecated as there are still people using them.  Tony Hansen 
> explained that deprecation means not to use it in future implementations 
> as it will go away at some point, it does not mean that it is no longer 
> supported in the specification.  There were two people in the Jabber 
> room in favor of deprecating and using the Authentication-Results: 
> header.  Doug Otis commented on having the IP address in 
> Authentication-Results: like Received-SPF: does.
> 

I would like to see a review on this with a new issue of defining what 
"MARK-ON-FAIL" means.

For the sake of discussion, 4408 states there are two modes a receiver 
can work with for FAIL policy results:

     MARK-ON-FAIL
     REJECT-ON-FAIL

A REJECT-ON-FAIL will not have any 5322.Received-SPF or any 
5322.Authentication-Result header since the message is never accepted.

4408 does not define MARK-ON-FAIL and the idea is only stated once in 
section 2.5.4 as "mark the mail".

In my technical view, a local site SPF deployment decision to either 
MARK-ON-FAIL or REJECT-ON-FAIL, SHOULD offer the same negative 
classification and MUA notification of message failure to the user.

A MARK-ON-FAIL mode of operation by the backend SHOULD separate the 
stream for the user so that offline MUA POP3 access does not mix these 
marked messages with the user's normal email.  Marked messages 
directly benefit the backend with Online MUA methods which separate 
and present the good vs bad folders.

Examples of such online MUAs are:

   - Web Mail
   - RFC-based MUA with IMAP support and a backend offering IMAP access
   - Proprietary MUAs like Window Live with a HTTP protocol to access 
and present
     the backend folders in a IMAP fashion.

I presented an example here:

    http://www.ietf.org/mail-archive/web/spfbis/current/msg01361.html

where an spoof -ALL failed policy message was accepted by hotmail.com 
and it effectively did a MARK-ON-FAIL idea but also separated the 
message into a Junk Email Folder. The user was protected due this 
separation with Window Live access and also via ThunderBird POP3 
access because the POP3 stream did not include the Junk Email 
separation.  [NOTE: The example also used no headers in DATA, and its 
possible, the email was marked as Junk-Email because of this and not 
necessarily because of SPF.]

Nonetheless, in my view, this may be an example where MARK-ON-FAIL 
offers a near similar outcome as REJECT-ON-FAIL by separating the 
stream and lowering the user exposed risk.

If separation semantics is not defined for a MARK-ON-FAIL, then there 
is an increased designed presumption and dependency for advanced POP3 
MUAs to exist and support Received-SPF and/or Authentication-Result 
headers.  If Authentication-Result are used, then it SHOULD have the
equivalent Received-SPF FAIL result interpretation if its could be 
viewed as an alternative, i.e. it is missing the IP address.

This is just "starter text" for proposing 2.5.4 text changes:

NEW:

    A "Fail" result is an explicit domain policy violation statement that
    the client is not authorized to use the domain in the given identity.

    When the result is a "Fail", the checking software MUST offer local
    receiver SPF deployments the option to choose between marking and 
classifying
    (MARK-ON-FAIL) the the message having failed the domain SPF policy or
    rejecting the mail outright (REJECT-ON-FAIL).

    When the REJECT-ON-FAIL option is used, the SMTP server MUST 
reject the mail
    during the SMTP transaction and it SHOULD issue a permanent 
rejection reply
    code of 550 and for servers supporting extended reply code 
[RFC3463], use a
    policy based rejection description subject sub-code of 5.7.1. The 
following
    are some examples of REJECT-ON-FAIL server responses:

        550 SPF MAIL FROM check failed:
        550-5.7.1 SPF MAIL FROM check failed:
        550-5.7.1 The domain example.com explains:
        550 5.7.1 Please see http://www.example.com/mailpolicy.html

    When the MARK-ON-FAIL option is used, it server SHOULD report this 
failure by
    adding a Receiver-SPF header to the received message. See Section 7.

    The REJECT-ON-FAIL should be regarded a System Level local policy 
for global
    filtering for all users, where the MARK-ON-FAIL should be regarded 
as a User Level
    Policy framework where good vs bad mail is separated for the user.

    Since the receiver option to either mark or reject should provide 
the same
    negative failure outcome of the message to the user, the receiver 
applying the
    the MARK-ON-FAIL option SHOULD also separate the message in 
appropriate user
    in-box folders, i.e. "Junk E-MAIL"   The primary reason for this 
is related
    to the type of MUA being used by the user. If an online MUA is 
used, then the
    backend host can control the display of separate folders.  If an 
offline MUA
    is used with POP3 mail pickup, the backend POP3 server SHOULD NOT 
combine
    the failed separated mail with the normal mail pickup.  If the MUA 
is using
    IMAP [RFCxxxx], then this will continue with a safer separating of 
folder displays
    for users. Overall, the local site SPF deployment of MARK-ON-FAIL 
SHOULD be aware
    of how it users are accessing the mail.

-- 
Hector Santos, CTO
http://www.santronics.com
http://hector.wildcatblog.com

---

From: S Moonesamy <[email-masked]>
Date: Mon, 23 Apr 2012 20:39:06 -0700

Hi Hector,
At 20:11 23-04-2012, Hector Santos wrote:
>was not my intent to say it would be out of scope. Thats because 
>very early on in the SPFBIS, offlist, I

I received the raw notes.  I worked from the audio ( 
http://www.ietf.org/audio/ietf83/ietf83-252a-20120330-0855-am.mp3 ) 
to get what was said during the SPFBIS session.  The Jabber log is at 
http://www.ietf.org/jabber/logs/[email-masked]/2012-03-30.html 
I can remove the sentence from the minutes.

>editor and the

Ok.

BTW, it is up to the WG Chairs to select a document editor.

>I would like to see a review on this with a new issue of defining 
>what "MARK-ON-FAIL" means.

Noted.

Regards,
S. Moonesamy
SPFBIS WG co-chair