Subject: [spfbis] A general cleanup strategy

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 17 Feb 2012 10:48:04 -0800

This is just a procedural suggestion.  I'm fine if we throw it away.

The charter has a lot of things in common with the general characteristics of the steps one would take if a working group wanted to advance something along the standards track.  That is, clarify and tidy up the specification, and toss out parts that are not known to be in use.

Would it be helpful to prepare an interoperability report, or at least go through the exercise of doing so, even if we don't actually ask the IESG to publish it?

-MSK

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 17 Feb 2012 13:56:17 -0500

On Fri, Feb 17, 2012 at 10:48:04AM -0800, Murray S. Kucherawy wrote:
> 
> Would it be helpful to prepare an interoperability report, or at
> least go through the exercise of doing so, even if we don't actually
> ask the IESG to publish it? 

This is an excellent suggestion, and I think it would be a wonderful
thing to do.  Do we need to organize any formal testing, or do we have
the data we need?

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 17 Feb 2012 11:01:03 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Sullivan
> Sent: Friday, February 17, 2012 10:56 AM
> To: [email-masked]
> Subject: Re: [spfbis] A general cleanup strategy
> 
> > Would it be helpful to prepare an interoperability report, or at least
> > go through the exercise of doing so, even if we don't actually ask the
> > IESG to publish it?
> 

The data Philip Gladstone has provided to date are a terrific start.  Anyone else with comparable data sets should be encouraged to provide them.  Paul tells me offline that the Microsoft database that collects such information was recently reset but will be back online soon, so he could provide us with that report at that time.

The trick, of course, is that we can't tell who's checking SPF or Sender-ID inbound, so it's very hard to gauge (other than anecdotally) how many people are using which ones and in which modes.

I'll poll some off-list resources and get them to give us what they can.

The interoperability report for DKIM was done with data from only a few sources (though a couple were quite large, fortunately), so I don't think any formal organization is necessary at this stage.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 17 Feb 2012 18:42:10 -0500

> thing to do.  Do we need to organize any formal testing, or do we have

I have mentioned the SPF test suite before, but I think it bears mentioning 
again in this context:

http://www.openspf.net/Test_Suite

There are at least four open source libraries that pass all the mandatory 
requirements in the test suite and can be, on that basis, said to be 
interoperable (given the same input data they wiill produce the same result).

http://www.openspf.net/Implementations

I think it's probably worth some discussion about what is interoperability in 
an SPF context.  It's not like DKIM where you have to verify messages signed 
by one impelementation are properly verified by another.  

SPF libraries consume SPF records and produce a result.  Interoperability is, 
I believe, a function of getting the "same" output from the same input SPF 
records where "same" may not quite mean identical since there are corner cases 
that just aren't worth worrying about.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 17 Feb 2012 15:46:01 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Friday, February 17, 2012 3:42 PM
> To: [email-masked]
> I have mentioned the SPF test suite before, but I think it bears
> mentioning again in this context:

Yep, we'll likely need to use that.  Thanks for the reminder.

> I think it's probably worth some discussion about what is
> interoperability in an SPF context.  It's not like DKIM where you have
> to verify messages signed by one impelementation are properly verified
> by another.
> 
> SPF libraries consume SPF records and produce a result.
> Interoperability is, I believe, a function of getting the "same" output
> from the same input SPF records where "same" may not quite mean
> identical since there are corner cases that just aren't worth worrying
> about.

If you add "same envelope and source IP address" to the mix, I'd agree that this is probably what we're working with here.  The other part of general SPF interoperability is Received-SPF (use of it, is there anything that consumes it, etc.).

-MSK

---

From: Hector Santos <[email-masked]>
Date: Fri, 17 Feb 2012 20:29:39 -0500

> thing to do.  Do we need to organize any formal testing, or do we have

Please lets be very careful this. State your GOALS and PURPOSE first. 
  There is 9 years of field, operations and customer support 
experiences, by millions of domains and its doesn't not serve any 
justice to have isolated subjective conclusions in this extremely 
small IETF new SPF-BIF working group coming to erroneous conclusions 
based on limited and isolated collections of data.

Lets please understand the "BIG BOYS" do no have the copyright on SPF 
understanding and should be the principle decided on new SPF 
directions here.  There are millions of small operations/domains and 
private operations supporting SPF.

If you want 9 years worth of SPF log and data statistics, I have it. 
You can see the 2003 to current summary statistics here, including how 
SPF or more specifically see the notations on how new DNS based 
technology starting with LMAP solutions alter how our SMTP server 
operated:

          http://www.winserver.com/SpamStats

If we are simply considering which SPF feature can be *deprecated*, 
that is something long time real field operations and customer support 
implementators should be able to chime on.

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

---

From: S Moonesamy <[email-masked]>
Date: Fri, 17 Feb 2012 18:54:58 -0800

Hi Hector,
At 17:29 17-02-2012, Hector Santos wrote:
>Please lets be very careful this. State your GOALS and PURPOSE 
>first.  There is 9 years

 From the SPFBIS WG Charter ( 
http://tools.ietf.org/wg/spfbis/charters ), there is the following deliverable:

   "A document describing the SPF/Sender-ID experiment and its
    conclusions to the IESG for publication."

The purpose of a working group is to produce its deliverables.  The 
working group has not decided on what goes into the above 
draft.  Andrew and I welcome suggestions and input from WG participants.

>Lets please understand the "BIG BOYS" do no have the copyright on 
>SPF understanding and should be the principle decided on new SPF 

This working group is open to anyone who would like to participate.

>You can see the 2003

Thanks for the offer.  Andrew posted a request for experimental 
evidence ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00285.html 
).  It is an open request to anyone who would like to help 
out.  Philip Gladstone provided some data ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00287.html ).

Regards,
S. Moonesamy
SPFBIS WG co-chair

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 17 Feb 2012 19:15:14 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Hector Santos
> Sent: Friday, February 17, 2012 5:30 PM
> To: Andrew Sullivan
> Cc: [email-masked]

The purpose of an IETF interoperability report is well-documented.  RFC5657 is a good place to start if you're unfamiliar with their purpose or structure in our context.  There are also tons of implementation reports available here to show you what sort of thing we're talking about:

	http://www.ietf.org/iesg/implementation-report.html

The one we did for DKIM is in that list.

>           http://www.winserver.com/SpamStats

I looked at a few of these, and at best what I found is a column that shows how many messages were rejected based on SPF on a given day.  The data appear to stop about four months ago.  What we need for an interoperability report is more like what Phillip Gladstone already provided, such as a ratio of sites that appear to have SPF policies published, what type of DNS RR they used, which mechanisms are popular, which extensions are popular, common errors, how many use macros, any information on false positives, etc.  The point is to evaluate how wide deployment is (or appears to be), what parts of RFC4408 are actually implemented and which ones are not, how many people got them right or wrong, any unintended consequences or side effects of deployment, etc.  And given the context in which RFC4408 is published, any associated data about Sender-ID would also be helpful.

Do you have anything like that?  Aggregate rejection counts can be interesting, but they don't answer the question an interoperability report presents.

> implementators should be able to chime on.

That is precisely what I believe has been requested.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Sat, 18 Feb 2012 20:02:47 -0500

S Moonesamy wrote:

>  From the SPFBIS WG Charter ( http://tools.ietf.org/wg/spfbis/charters 
> ), there is the following deliverable:
> 
> working group has not decided on what goes into the above draft.  Andrew 
> and I welcome suggestions and input from WG participants.

It was probably a mistake to decide to refrain from commenting on the 
last charter writeup other than in the name of moving on, to basically 
give it +1. But there was items in the charter should needed 
clarification and had a few unproven conclusions and I did add issue 
#4 alluding to the one the conflicts.

This is why I believe the only relationship is issue #4 and IMV, the 
above document is different than an Interop report unless the common 
"goal" of either report to is bring about a justification that 
SENDER-ID and by default SUBMITTER are no longer supported protocols 
that SPF implementations should be concern with.

Overall, I am little confused with the charter if one the purposes of 
the SPF-BIF group is to make a conclusion on SENDER-ID/SUBMITTER. 
That doesn't seem right to me or fair to all current 
SENDER-ID/SUBMITTER supporters.

(Note, the above is cut down version of a much longer message. <g>)

---

From: "Stuart D. Gathman" <[email-masked]>
Date: Sat, 18 Feb 2012 22:51:17 -0500 (EST)

On Sat, 18 Feb 2012, Hector Santos wrote:

> Overall, I am little confused with the charter if one the purposes of the 
> SPF-BIF group is to make a conclusion on SENDER-ID/SUBMITTER. That doesn't 
> seem right to me or fair to all current SENDER-ID/SUBMITTER supporters.

You are correct, however there is the outstanding conflict that 
rfc4406 paragraph 3.4 has with 4408.  A 4408bis should resolve this conflict
somehow, although a simple errata for 4406 would be the simplest and
least political: "v=spf1 SHOULD be treated as equivalent to spf2.0/mfrom".

If an errata for 4406 is out of scope for this WG, then 4408bis should
recommend (SHOULD) an "spf2.0/pra" record in addition to any v=spf1 record.
This would also address the conflict (and cover existing implementations of
4406 as well).

But if 4406 is not actually being used, then no such attention is necessary.

-- 
 	      Stuart D. Gathman <[email-masked]>
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

---

From: Hector Santos <[email-masked]>
Date: Sun, 19 Feb 2012 00:06:03 -0500

Hi Stuart,

In all honesty, since I never believed in SENDER-ID, didn't see how it 
resolved the "path independent" problem, I never directly supported it 
but I didn't deny it existence and used SUBMITTER as our indirect support.

But what wasn't ever fully investigated if looking for SPF2.0 records 
was necessary since over 84% of the time, the 5321.MailFrom domain was 
the same as the PRA.

So I agree this is very good material to get resolved. I claim no 
field experience expertise with SPF2.0 like records.  I know there are 
stated conflicts, but I never got a real feel for that.

I mostly focused that it was a payload technology and if you supported 
SPF, how did it change how a SMTP receiver operated in requiring it to 
do a payload download or acceptance.  This is why I supported 
SUBMITTER as a indirect non-payload method to support SENDER-ID.

In my view, for SPF-BIF, it should stay away from possible erroneous 
conclusions about the SENDER-ID experiment (let some other WG 
determine that) and just focus at the SPF codification and consider 
the optional indirect support for the SMTP extension solution 
SUBMITTER offers.

The fact is this:

Add the ESMTP keyword exposure of SUBMITTER to your ESMTP server EHLO 
response and you quickly will see clients adding the SUBMITTER= 
parameter to the MAIL FROM command.  Any server that is not exposing 
the keyword can not be making a judgement about it over others that do.

Stuart D. Gathman wrote:
>> the SPF-BIF group is to make a conclusion on SENDER-ID/SUBMITTER. That 
>> doesn't seem right to me or fair to all current SENDER-ID/SUBMITTER 
>> supporters.
> 
> You are correct, however there is the outstanding conflict that rfc4406 
> paragraph 3.4 has with 4408.  A 4408bis should resolve this conflict

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 20 Feb 2012 10:26:01 -0500

Dear colleagues,

No hat.

On Sat, Feb 18, 2012 at 08:02:47PM -0500, Hector Santos wrote:
> Overall, I am little confused with the charter if one the purposes
> of the SPF-BIF group is to make a conclusion on SENDER-ID/SUBMITTER.

Despite my previous grousing about the lack of success criteria in the
IESG note making SPF and Sender-ID experimental, I cannot see any way
to interpret the experiment as one other than having two slightly
incompatible protocols using the same record from the DNS, only with
different meanings.  It seems to me therefore that any purported
conclusion of the experiment necessarily has something to say about
both technologies, even if the focus of that experiment conclusion is
on only one of the technologies.

If someone disagrees with that view, then I'd be very interested in
hearing why.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 20 Feb 2012 08:54:41 -0800

On 2/20/2012 7:26 AM, Andrew Sullivan wrote:
> It seems to me therefore that any purported

The challenge is in the detail of "say something about both technologies".

The premise that you offer, "slightly incompatible protocols using the same 
record from the DNS, only with different meanings" does seem terse and the 
essence of what's interesting.

Perhaps the commentary worth reporting on can be limited to:

1. Statements about adoption levels of each

2. Statements about known conflicts by having the records shared.

I actually suspect there is little objective data on the latter.

Perhaps it can be argued that a sufficiently clear differential on #1 will 
eliminate the need for answering #2?

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Hector Santos <[email-masked]>
Date: Mon, 20 Feb 2012 12:59:53 -0500

Hi Andrew,

While I believe there is an "common" integrated aspect to it via the 
SUBMITTER protocol warranting SPF-BIS discussion, in principle I 
believe no (especially negatives) determination should be done on 
SENDER-ID (and SUBMITTER) without having input for the principal cogs 
involved with the protocol namely Microsoft.  In addition, as a 
product vendor, I can't just decide to remove a feature just because 
the IETF subjectively came up with some conclusion and presumed there 
will not be an support "Hey what happen!?" repercussions.  I'm sure 
many have experienced this numerous time when its seems some "legacy" 
item was not used and hence in the name of fine tuning, clean things 
up, etc, in fact find out it was used after the rugged as been pulled 
- a non-zero costly mistake.

On the other hand, if there is something related to the suggestion 
that its authors have abandoned it and no longer support the 
technologies, then in my view, that should be one of the first 
questions to be answered.

If there was still some utility and there is still domain support for 
it, but there many feel there is some conflicts and/or contention 
issues, then in my engineering opinion, a solution should be found 
that perhaps not just focuses on a singular abandonment option.   If 
that indeed is the desire, then it also means a decision to abandon 
its companion SMTP level technology - SUBMITTER.

This is what complicates it because there are more than one pieces of 
software that are altered, one that just needs to work with RFC5322 
and one designed to work with RFC5321.

Since its a complicated issue, my suggestion the IETF should not be 
making that decision until the people who put together 
SENDER-ID/SUBMITTER and the thousands, if not millions of domains who 
have long supported SENDER-ID/SUBMITTER are involved in this 
discussion and contributes to that decision.

---

From: John Leslie <[email-masked]>
Date: Mon, 20 Feb 2012 13:09:36 -0500

Andrew Sullivan <[email-masked]> wrote:
> IESG note making SPF and Sender-ID experimental,

   The IESG of that time wasn't thinking in terms of "success criteria"
for Experimental RFCs.  (IMHO, of course, there were no Narrative Scribes
at the time.)

   The IESG has since started giving serious consideration to what might
represent "success" or "failure" of an Experiment. So it is certainly
fair game to try to satisfy that (vague) criterion.

> I cannot see any way to interpret the experiment as one other than
> having two slightly incompatible protocols using the same record
> from the DNS, only with different meanings.

   This is an excellent way to look at it. (IMHO.)

   The trouble is, how can we tell which published v=spf1 records intend 
which meaning?

   Both SPF and Sender-ID specified algorithms for evaluating these
records; and while the difference in meaning was usually slight, the
difference in algorithms was significant.

> It seems to me therefore that any purported conclusion of the experiment
> necessarily has something to say about both technologies,

   I quite agree!

> even if the focus of that experiment conclusion is on only one of the
> technologies.

   I look at it a bit differently.

   This WG was created to "advance" SPF to Proposed Standard. The IESG
(IMHO) agreed that an apparent obstacle to that was the existence of
two Experimental protocols using the same DNS record differently.

   One way out of that would be to have the SPF Proposed Standard define
a totally new DNS record, and avoid any confusion. (It appears that
nobody liked that way.)

   Another way is to conclude both Experiments and declare a single
meaning for the already-existing v=spf1 records. Enough people liked
that that this WG was created.

   That means that this WG _must_ consider the opinions of those who
prefer Sender-ID meanings; and IMHO the IESG wants the process of
considering those documented in the first milestone:
" 
" Aug 2012  A document describing the SPF/Sender-ID experiment and its
"           conclusions to the IESG for publication.

> If someone disagrees with that view, then I'd be very interested in

   I really don't "disagree" -- but I think the focus should be on our
obligation to consider any alleged benefits of the Sender-ID meaning.

   This does seem in discord with the "Specifically out-of-scope"
" 
" * Discussion of the merits of Sender-ID in preference to SPF

item; but I think we're safe to interpret the "describe the experiment"
language as more-recently-added, and more binding.

   It is, IMHO, possible to "describe" an "experiment" without arguing
the perceived "merits" of one approach.

   I hope the WGCs will be tolerant of discussion of the Sender-ID
meaning for the v=spf1 records to the extent it contributes to the
wording of our first milestone.

   Our progress will be easiest if we satisfy Sender-ID proponents that
their opinions have been respected and considered _before_ that document
goes to IETF LastCall.

--
John Leslie <[email-masked]>

---

From: "John Levine" <[email-masked]>
Date: 20 Feb 2012 21:14:30 -0000

>eliminate the need for answering #2?

I'm not aware of anyone other than Hotmail who did a non-trivial
deployment of Sender-ID, and I wouldn't expect them to publish their
results.

So I agree, there isn't likely to be enough data to say anything about
#2.

R's,
John
-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 20 Feb 2012 14:04:32 -0500

On Monday, February 20, 2012 12:59:53 PM Hector Santos wrote:
> SUBMITTER protocol warranting SPF-BIS discussion, ...

Hector,

I believe you are mistaken.  SUBMITTER and SPF are unrelated.  It's not about 
SPF/Sender-ID integration at all.  It's about using body PRA Sender-ID results 
instead of SPF.

I don't think SUBMITTER is on topic for this working group.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 20 Feb 2012 11:27:31 -0800

> Sent: Monday, February 20, 2012 11:05 AM
> To: [email-masked]

It is part of the cluster of documents that included Sender-ID, PRA and SPF, insofar as the same IESG Note was attached to it. 

I've been collecting data about SUBMITTER deployment as part of the interoperability report idea, and the experiment closure.  I can certainly stop and change that if we decide it's out of scope, but they look quite linked to me.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 20 Feb 2012 14:37:32 -0500

On Monday, February 20, 2012 11:27:31 AM Murray S. Kucherawy wrote:
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Scott Kitterman Sent: Monday, February 20, 2012 11:05 AM
> > To: [email-masked]
> It is part of the cluster of documents that included Sender-ID, PRA and SPF,
> insofar as the same IESG Note was attached to it.
> 
> I've been collecting data about SUBMITTER deployment as part of the
> interoperability report idea, and the experiment closure.  I can certainly
> stop and change that if we decide it's out of scope, but they look quite
> linked to me.

I agree it's part of the experimental closeout.

I don't the it's something that's in scope to consider for 4408bis itself.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 20 Feb 2012 11:38:35 -0800

> Sent: Monday, February 20, 2012 11:38 AM
> To: [email-masked]

Ah.  Check.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Mon, 20 Feb 2012 17:15:33 -0500

Hi Scott,

I disagree with your opinion I am mistaken. Rather than provide a 
lengthy background and evidence of reasoning why it is 100% related to 
SPF, I will suggest that we do not go down this route to make any 
critical decisions about SENDER-ID/SUBMITTER until there is clear KB 
and indication its lost of value, no longer significant, lost 
significant level of support from domains and we get some form of 
input and opinion from key authors, i.e. Katz, Lyon and Allman.

Just consider any opinion that SUBMITTER is out of scope, would 
logically imply it is also out of scope for any final chartered 
product delivery, Interop Report or any decision about it.  Its seems 
odd to me that claiming something is out of scope, somehow also 
justifies to have a non-discussed implication and conclusion it is no 
longer supported.  I don't think we can have it both ways.

Do you realize there are many clients that does support it? I stated 
that simply adding the ESMTP SUBMITTER keyword to your EHLO response 
will help measure it usage, which to me is significant.

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

---

From: Hector Santos <[email-masked]>
Date: Mon, 20 Feb 2012 18:48:01 -0500

> I don't the it's something that's in scope to consider for 4408bis itself.

How do you justify this when there evidence that it is well supported 
by MTA clients?

You can not make SPF-BIF WG conclusions about SUBMITTER/SENDER-ID 
without make it a charter goal to prove this would the correction 
decision with minimal impact.  You just don't know that and I believe 
your ESMTP server expose the SUBMITTER keyword and see how much 
traffic you get from clients supporting,  you may (I hope) have a 
different opinion about it.

Now, I disagree with you to suggest they are not related on the 
fundamental principle both SPF and SID have one thing in common - 
they are both LMAP solutions which provided the basic protocol theory 
of an authorized DOMAIN::IP association assertion.

For the same reasons I encouraged Meng to add support for optional 
EHLO checking based on the LMAP analysis I did back in 2004:

http://www.winserver.com/public/antispam/lmap/draft-lmapanalysis1.htm

There is in fact, a 3rd domain PRA that Microsoft introduced with CEP 
(Caller Email Policy).  All together for an total and full 
implementation, we have three domain::IP assertions:

      CLIENT-DOMAIN::IP
      RETURN-PATH-DOMAIN::IP
      PRA-DOMAIN::IP

As a side and very important factor in the development was the fact 
that CEP offered its own DNS subdomain name space using the subdomain 
prefix ".ep"  In fact, even today you can still see the old 
experimental Microsoft's Hotmail.com CEP record with its XML-based SPF 
record:

     nslookup -query=TXT _ep.hotmail.com

      Non-authoritative answer:
     _ep.hotmail.com text =

      "<ep xmlns='http://ms.net/1' testing='true'>
       <out>
         <m>
          <indirect>list1._ep.hotmail.com</indirect>
          <indirect>list2._ep.hotmail.com</indirect>
          <indirect>list3._ep.hotmail.com</indirect>
         </m>
       </out>
      </ep>"

What is important to remember was the fact the CEP had its own 
namespace and there would be no conflict with SPF record if it had 
indeed remained that way.

But the interest in MARID was merge and produce a common open public 
standard and there were a few key issues we voted on:

    - Should we use a XML format?  It was interesting as a 
"Direction", but XML
      was not deemed a good idea for DNS TXT based results with its 
obvious waste
      in its text overhead,

    - The desire to have a common format and language to support the 
already existing
      high and growing based of SPF domains with v=spf1 records, and

    - as stated about, CEP had its own DNS subdomain name space using 
the "_ep."
      subdomain prefix and if  were to support two protocols, even 
after we agree
      they had the same record language, it meant there would be two 
different
      DNS TXT queries with the odds that they will have same context. 
One for SPF
      and one for CEP.  There was a desire to able to read both 
records with one
      single TXT query under one name space.  If this was the genesis 
of a unforeseen
      conflict, thats another story.

Overall, in MARID we came to consensus of the deliverables that came 
with a technical acknowledgment there was interest in three different 
domains; two of them was covered with SPF with no payload requirement, 
and a 3rd domain based on the payload PRA. What was common between all 
of them was the IP.

We can not dispense the idea that any vendor wanted to offer the best 
of all SPF-like worlds to their customers.

The only beef I had was that SID promoted the payload in order to 
support that 3rd domain.

So I fought hard to push this point it would be a very wasteful 
requirement when a major interest in SPF was in fact to address the 
accept/bounce problem that SORBIG highlighted as a major SMTP relaxed 
security issue. I communicated extensively with Harry offlist about 
this and was very happy to see that in the final Meng/Microsoft 
agreement of the new goals, SUBMITTER was among them to help address 
the PAYLOAD concern as the only way to get the PRA.

So Scott, I fundamentally feel SPF-BIF can not ignore its relationship 
with SID/SUBMITTER especially when its now also is trying to make some 
decisions about the future of SID/SUBMITTER.

---

From: Paul Midgen <[email-masked]>
Date: Tue, 21 Feb 2012 01:29:37 +0000

Hotmail will indeed publish all relevant information, I can't see a good reason not to. ETA is mid to late March. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John Levine
Sent: Monday, February 20, 2012 1:15 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [spfbis] A general cleanup strategy

>Perhaps it can be argued that a sufficiently clear differential on #1 
>will eliminate the need for answering #2?

I'm not aware of anyone other than Hotmail who did a non-trivial deployment of Sender-ID, and I wouldn't expect them to publish their results.

So I agree, there isn't likely to be enough data to say anything about #2.

R's,
John
--
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly _______________________________________________
spfbis mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/spfbis

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 20 Feb 2012 18:01:24 -0800

> Sent: Monday, February 20, 2012 2:16 PM
> To: [email-masked]
> significant level of support from domains and we get some form of input
> and opinion from key authors, i.e. Katz, Lyon and Allman.

We're in the process of collecting that information.

> logically imply it is also out of scope for any final chartered product
> delivery, Interop Report or any decision about it.  Its seems odd to me
> that claiming something is out of scope, somehow also justifies to have
> a non-discussed implication and conclusion it is no longer supported.
> I don't think we can have it both ways.

Just to clarify my suggestion: The point of doing the implementation report exercise (see RFC5657) about SPF is to determine what parts of the SPF spec itself have been deployed (and should stay), which have interoperability problems (and should be clarified or fixed), and which are not in use (and should be deprecated or even removed).  I suggested this as a tool to making the RFC4408bis document as strong and tight as possible.

I'm not suggesting undertaking an interoperability report for Sender-ID, PRA or SUBMITTER except as much as we need to do so to produce our "conclusion of the experiment" document.

> will help measure it usage, which to me is significant.

Do you have a list of these?  I couldn't find one.

-MSK

---

From: "John R. Levine" <[email-masked]>
Date: 20 Feb 2012 18:11:01 -0800

> Hotmail will indeed publish all relevant information, I can't see a good reason not to. ETA is mid to late March.

That would be very helpful.  Thanks.

R's,
John

Regards,

---

From: Hector Santos <[email-masked]>
Date: Mon, 20 Feb 2012 22:43:38 -0500

> Do you have a list of these?  I couldn't find one.

Murray, I posted a report to your question in IETF-SMTP.

    http://www.imc.org/ietf-smtp/mail-archive/msg07117.html

Note, this archive reference does masked out the domain data listed. 
So list copy of the submitted message would show the better info.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 21 Feb 2012 14:50:39 -0800

> Sent: Monday, February 20, 2012 7:44 PM
> To: [email-masked]

Somehow I never got your message on ietf-smtp.  Thanks for the link.

As you said over there, it's hard to tell just how much of this is from spam clients and how much is from ESPs that are using SUBMITTER because your MTA offers it.  There's no doubt that you're seeing the traffic, but it's unfortunate that we can't tell which specific clients are doing it.  Regardless, I agree that it's unclear whether these are spammers or ESPs.  I think the interesting fact is that there are so few spf2.0/pra records out there tells me this is indeed opportunistic use of SUBMITTER rather than an indication of intended use of Sender-ID.

A survey of MTAs and their spam and virus accuracy plugins has reported that of over 20 MTA solutions that they test, only one implements SUBMITTER.  Surprisingly, that MTA is not MS Exchange.

It also raises an interesting procedural question: If we can categorize a technology like SUBMITTER as only ever having been deployed primarily by spammers, how does that figure into the questions of an interoperability report?

-MSK

---

From: Hector Santos <[email-masked]>
Date: Wed, 22 Feb 2012 01:27:50 -0500

Murray S. Kucherawy wrote:
> There's no doubt that you're seeing the traffic, but it's unfortunate that we can't 
> tell which specific clients are doing it.  Regardless, I agree that it's unclear 
> whether these are spammers or ESPs.  

It wasn't a surprise for high eMarketer usage. Like DKIM, SPF/SIDF 
became part of eMarketer and DMA recommendations for a BCP "Good Guy" 
behavior in PR efforts to lower its market negative image and 
especially promoting SIDF because of its industry standard and 
corporate endorsement image it brought.  Doing a quick search for "DMA 
SENDER-ID RECOMMENDATIONS"... first google link.

          http://www.the-dma.org/antispam/EmailBPFINAL.pdf

Looks like good stuff there, but do check out others too since this 
PDF seem to be more recent.

> I  think the interesting fact is that there are so few spf2.0/pra records out there tells 
> me this is indeed opportunistic use of SUBMITTER rather than an indication of 
> intended use of Sender-ID.

I'll check out our cached DNS data soon and focus on that on that 
question.  I should note however, I am not part of the school of 
thought to believe a low usage is enough justification from remove it 
from a standard which for all intent, it is already considered a 
standard in the eyes of long time implementators of product code.

> A survey of MTAs and their spam and virus accuracy plugins has reported that of 
> over 20 MTA solutions that they test, only one implements SUBMITTER.  Surprisingly, 
> that MTA is not MS Exchange.

I don't think this is justification nor the role of SPF-BIS to make 
that SIDF/SUBMITTER decision.  I would suggest since MARID there was 
two different groups starting with the fact SPF was growing on its own 
without the IETF. It was Microsoft with intro of the XML version of 
its SPF clone (CEP) that force the creation of MARID to solidify a 
common standard. And with the many contentions, including "Hate MS" 
camp, it is not a surprise at all to find the API resources at SPF web 
site to include software that doesn't support SENDER-ID, yet along 
SUBMITTER.

To get a better measurement, a look of the commercial MTA software 
vendors who even if they doubted SIDF value, like most things, a 
feature is added for corporate and  marketing value anyway.

But despite all that, there is something inherently wrong using high 
probable mis-read for a low usage threshold criteria to remove 
something with a disregard it may harm existing implementator business 
or customers.   When a BIG vs SMALL boys position is used to brush 
away the small boys, the small boys made just use ANTI=TRUST claims 
against the IETF if it endorses protocol changes with BIS work for 
established, well-entrenched implementors of these protocols.

> It also raises an interesting procedural question: If we can categorize a technology 
> like SUBMITTER as only ever having been deployed primarily by spammers, how does 
> that figure into the questions of an interoperability report?

I think the SPF-BIF group is playing with fire. Just for the record, 
and in all honesty, why even go there. Why all this obvious friction 
and contention when it doesn't have to be.

Until Microsoft views are seen here, I will stay away from this.

Sorry. :)

---

From: Paul Midgen <[email-masked]>
Date: Wed, 22 Feb 2012 07:18:20 +0000

As concerns SUBMITTER: this group is reviewing things that have been published for 6+ years. If by now there isn't a vocal and deployed base prepared to share data and operational experience that supports the inclusion of a given thing, that should carry a bit of weight.

For 2.5 of those 6 years I've been responsible for Hotmail's inbound infrastructure, and haven't received a single request to implement SUBMITTER.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hector Santos
Sent: Tuesday, February 21, 2012 10:28 PM
To: [email-masked]
Subject: [spfbis] SUBMITTER usage

Murray S. Kucherawy wrote:
> There's no doubt that you're seeing the traffic, but it's unfortunate 
> that we can't tell which specific clients are doing it.  Regardless, I 
> agree that it's unclear whether these are spammers or ESPs.

It wasn't a surprise for high eMarketer usage. Like DKIM, SPF/SIDF became part of eMarketer and DMA recommendations for a BCP "Good Guy" 
behavior in PR efforts to lower its market negative image and especially promoting SIDF because of its industry standard and corporate endorsement image it brought.  Doing a quick search for "DMA SENDER-ID RECOMMENDATIONS"... first google link.

Looks like good stuff there, but do check out others too since this PDF seem to be more recent.

> I  think the interesting fact is that there are so few spf2.0/pra 
> records out there tells me this is indeed opportunistic use of 
> SUBMITTER rather than an indication of intended use of Sender-ID.

I'll check out our cached DNS data soon and focus on that on that question.  I should note however, I am not part of the school of thought to believe a low usage is enough justification from remove it from a standard which for all intent, it is already considered a standard in the eyes of long time implementators of product code.

> A survey of MTAs and their spam and virus accuracy plugins has 
> reported that of over 20 MTA solutions that they test, only one 
> implements SUBMITTER.  Surprisingly, that MTA is not MS Exchange.

I don't think this is justification nor the role of SPF-BIS to make that SIDF/SUBMITTER decision.  I would suggest since MARID there was two different groups starting with the fact SPF was growing on its own without the IETF. It was Microsoft with intro of the XML version of its SPF clone (CEP) that force the creation of MARID to solidify a common standard. And with the many contentions, including "Hate MS" 
camp, it is not a surprise at all to find the API resources at SPF web site to include software that doesn't support SENDER-ID, yet along SUBMITTER.

To get a better measurement, a look of the commercial MTA software vendors who even if they doubted SIDF value, like most things, a feature is added for corporate and  marketing value anyway.

But despite all that, there is something inherently wrong using high probable mis-read for a low usage threshold criteria to remove something with a disregard it may harm existing implementator business 
or customers.   When a BIG vs SMALL boys position is used to brush 
away the small boys, the small boys made just use ANTI=TRUST claims against the IETF if it endorses protocol changes with BIS work for established, well-entrenched implementors of these protocols.

> It also raises an interesting procedural question: If we can 
> categorize a technology like SUBMITTER as only ever having been 
> deployed primarily by spammers, how does that figure into the questions of an interoperability report?

I think the SPF-BIF group is playing with fire. Just for the record, and in all honesty, why even go there. Why all this obvious friction and contention when it doesn't have to be.

Sorry. :)

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 22 Feb 2012 07:29:16 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Midgen
> Sent: Tuesday, February 21, 2012 11:18 PM
> To: Hector Santos; [email-masked]
> Subject: Re: [spfbis] SUBMITTER usage
> 
> As concerns SUBMITTER: this group is reviewing things that have been
> published for 6+ years. If by now there isn't a vocal and deployed base
> prepared to share data and operational experience that supports the
> inclusion of a given thing, that should carry a bit of weight.
> 
> For 2.5 of those 6 years I've been responsible for Hotmail's inbound
> infrastructure, and haven't received a single request to implement
> SUBMITTER.

Thanks, Paul.

If I could ask a bit more of you and your data: While you're gearing up another SPF/Sender-ID efficacy comparison, is there a way to determine whether or not your Sender-ID implementation checks type 99 (SPF) DNS records, type 16 (TXT) records, or both?  And, if both, can you gauge what the percentages are for each?

"No" is a perfectly valid answer if that would be a pain.  We already have one report done and one pending with this information, but a third data set can't hurt if we can get one.  :-)

-MSK

---

From: Hector Santos <[email-masked]>
Date: Wed, 22 Feb 2012 03:32:21 -0500

Paul Midgen wrote:

> As concerns SUBMITTER: this group is reviewing things that have been published for 
> 6+ years. If by now there isn't a vocal and deployed base prepared to share data 
> and operational experience that supports the inclusion of a given thing, that 
> should carry a bit of weight.

This is BIS work. It has always been my IETF understanding BIS work is 
not work designed and only under special and rare circumstances, to 
change current or harm any existing implementations at any level.

This particular item is not one of items to be considered lightly for 
abandonment.

> infrastructure, and haven't received a single request to implement SUBMITTER.

With all due respect and don't fall trap to disliking me, so don't - 
so what?

What you stated has no correlation whatsoever to a true reflection if 
its used or not.   In addition, and very importantly, hotmail.com is 
not a commercial service bureau. In other words, you don't sell 
hotmail.com for others to use on their own server or network.

What you didn't measure is when the HOTMAIL.COM receivers would expose 
the SUBMITTER keyword, and  now you will measure the possible million 
of clients connecting to hotmail.com and use the MAIL FROM SUBMITTER= 
keyword in order to support the PRA option in their messages.

What you seem to be suggesting in reality is that HOTMAIL.COM either 
A) does not support SENDER-ID at all, or B) does support SENDER-ID via 
SUBMITTER?

Sounds like A to me.

I don't you can voice a lack of support at hotmail.com if it never 
supported SENDER-ID or the SUBMITTER SMTP extension.

Thats like saying my SMTP server never needed to support the BITMIME 
SMTP extension and never got any request or market pressure to add 
ESMTP support and thus never got any feel for it in its transactions 
and believed it was also not supported by others - because you didn't.

But once you simply add the BITMIME Keyword to your server EHLO 
responses, just to measure it, you will quickly see how widely 
supported it is, negating all the erroneous impressions you had that 
its an unpopular protocol.  Its not.

I say that because that is what happen with us - I erroneously had the 
believe BITMIME was not a well supported SMTP extension until we 
finally explored it and added it and BEHOLD, you find how wrong you 
were believing it was low support extension.

---

From: Hector Santos <[email-masked]>
Date: Wed, 22 Feb 2012 04:05:15 -0500

Follow up and clarification:

Hector Santos wrote:
> What you seem to be suggesting in reality is that HOTMAIL.COM either A) 
> does not support SENDER-ID at all, or B) does [not] support SENDER-ID via 
> SUBMITTER?
> 
> Sounds like A to me.

Paul, I think you don't understand what the purpose was and why 
SUBMITTER was invented.

Using SUBMITTER is an server decision to order to optimize server and 
system performance and improved transaction throughput.  It is also a 
way to better trap redundant fraud by spoofers.

That was the whole purpose of it so if indeed hotmail.com supports 
SENDER-ID it would be for the benefit of the your server operations in 
terms of system performance, lower payload overhead to allow clients 
to issue the PRA at the SMTP level via the SUBMITTER protocol.

Otherwise, you are inherently requirement the payload at all times if 
SPF does not does the job for you.

No one is going to request that you support it. That doesn't make 
sense unless there were situations perhaps where hotmail.com was 
always rejection based on a Payload SENDER-ID PRA violation and the 
client was saying:

    "Hey, why you are wasting my bandwidth with transforming the 
payload when you
     are rejecting base on the PRA. I can give that PRA via SUBMITTER 
to save in
     the payload transfer."

Doesn't make sense, does it?  No, you would add it to save in payload 
overhead and improve system performance and if the there is good 
measure rejecting based on the PRA, then you benefit by supporting it.

---

From: Hector Santos <[email-masked]>
Date: Wed, 22 Feb 2012 04:42:52 -0500

Murray S. Kucherawy wrote:
> If I could ask a bit more of you and your data: While you're gearing up another 
> SPF/Sender-ID efficacy comparison, is there a way to determine whether or not 
> your Sender-ID implementation checks type 99 (SPF) DNS records, type 16 (TXT) 
> records, or both?  And, if both, can you gauge what the percentages 
are for each?
> 
> "No" is a perfectly valid answer if that would be a pain.  We already have one report 
> done and one pending with this information, but a third data set can't hurt if we 
> can get one.  :-)

This buddy-buddy system at the exclusion of others has got to stop.

Quick review of the cached DNS queries I have:

      3426   : cached TXT records (request)
      2783   : with v=spf1
        82   : with spf2.0 include INVALID ones (I believe, see below)
               10 spf2.0/mfrom
               72 spf2.0/pra

These were among the totals that I think are invalid syntax. Don't 
know off hand if v=spf2 is valid

  v=spf2
  v=spf2.0/pra
  v=spf2.0/pra
  v=spf2.0/pra
  v=spf2.0/pra
  v=spf2.0/pra mx
  v=spf2.0/pra mx
  v=spf2/mfrom,pra
  v=spf2.0/mfrom
  v=spf2.0/mfrom
  v=spf2.0/mfrom
  v=spf2.0/mfrom
  v=spf2/mfrom,pra

Even as I sure you will label me as a SMALL system, even as a small 
system there is over 80% usage of spf2.0/pra for SIDF.  To continue 
contemplating getting rid of it in SPF-BIS, would represent a serious 
problem.

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 22 Feb 2012 07:18:24 -0500

>know off hand if v=spf2 is valid

It's not.

>contemplating getting rid of it in SPF-BIS, would represent a serious 

Since v=spf1 records are considered valid for PRA evaluations by Sender ID you can't conclude anything based on your data. The fact that Sender ID is forced on SPF record publishers confuses things further.

To gauge actual interest in Sender ID, you have to have some mechanism for determining what fraction of the participation is based on consensual interest. I've no idea how to do that.

You can't separate SUBMITTER from PRA, so absent some groundswell of support for some future working group to deal with Sender ID, there's no point in worrying about SUBMITTER.

FWIW, I don't think anyone is ignoring anyone, but I do think you're venturing beyond the charter regularly, so it's no surprise such excursions don't generate a lot of positive feedback.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 22 Feb 2012 14:49:45 +0000

> Sent: Wednesday, February 22, 2012 1:43 AM
> To: [email-masked]

Your data haven't been excluded.  They're already in the report.

>         82   : with spf2.0 include INVALID ones (I believe, see below)

So that's over 97% SPF, with fewer than 3% using spf2.0, and even less than that doing PRA.  That's consistent with the other data that have been collected so far.

Since SUBMITTER is only input to Sender-ID, as Scott pointed out, its meaningful use is quite small.  But your data also point out that there's some blind opportunistic use of it, which is also worth reporting.

> system there is over 80% usage of spf2.0/pra for SIDF.
> To continue contemplating getting rid of it in SPF-BIS, would represent a serious
> problem.

That's not what your data say.  They say that among spf2.0 records, there's substantial use of PRA.  But that's only within a very small fraction of your overall DNS observations, which vastly favour SPF.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Wed, 22 Feb 2012 10:03:13 -0500

> FWIW, I don't think anyone is ignoring anyone, but I do think you're venturing 
> beyond the charter regularly, so it's no surprise such excursions don't generate 
> a lot of positive feedback.
> 

Seem to be wrong on several levels and its unfortunate, that you found 
it very convenient to state this ad nauseam attack.  Its unfortunate 
but perfectly understood why you would be part of this conflict of 
interest chorus. It only puts one on the defensive.. Damn if you, damn 
if you don't.

You are not very convincing just say "Forget about it."

1) You are assuming the chartered was correct to begin with, yet it 
has conflict of interest problems and voicing this concern is used 
against you.

2) You have an unproven belief for a lack of interest in 
SIDF/SUBMITTER and that there never existed any well conceived 
integrated association since MARID with SPF and SIDF/SUBMITTER, and

3) You have critical presumptuous this belief will not have any 
repercussions.

> Since v=spf1 records are considered valid for PRA evaluations by Sender ID you 
> can't conclude anything based on your data. 

Sure we can. I didn't include v=spf1 and your you over 80% of the 
SPF2.0 records are indeed PRA, a false claim you made that it isn't 
support.  But even better to lump v=spf1 and that means even clearer 
you have no right to be dictating abandonment.

> The fact that Sender ID is forced on SPF record publishers confuses things further.

So getting right it is your solution?

> To gauge actual interest in Sender ID, you have to have some 
> mechanism for determining what fraction of the participation is based 
> on consensual interest. I've no idea how to do that.

Huh? You can clearly measure it just look by seeing what multiple 
strings are included in TXT records.

    If it has only a SPF2.0 string then the INTENT and INTEREST is 
quite clear,

> You can't separate SUBMITTER from PRA, 

Again HUH?

> so absent some groundswell of support for some future working group to deal with 
> Sender ID, there's no point in worrying about SUBMITTER.

Sorry to disagree with this sort of subjective mandate to ignore what 
exist in practice simply because you have what appears to be a lack of 
feel for its adoption.

Thats simply not right. I stand ethical principles and whats going is 
here is a conflict on my principles.

You have absolute no right to be dictating what existing 
implementations should do, they can't just "Forget about it", 
including to support a belief no cost and support burden will not 
exist, all when you seem to be doing this purely on conjecture and no 
real feel for its support.

No amount of data isn't convince you or others wanting to get rid of 
it, and certainly proof of support shown by me is thrown by the waste 
side.

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 22 Feb 2012 10:09:21 -0500

> > You can't separate SUBMITTER from PRA, 

Have you read RFC 4405?

See paragraph 4.1 of that document.  It starts:

   The purpose of the SUBMITTER parameter is to allow the SMTP client to
   indicate to the server the purported responsible address of the
   message directly in the RFC 2821 protocol.

That's it's only purpose.  It is absolutely and completely unrelated to SPF.  
It is, in fact, a mechanism assist in not doing SPF.

End of discussion from my POV.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Wed, 22 Feb 2012 10:50:10 -0500

> That's it's only purpose.  It is absolutely and completely unrelated to SPF.  

How you jump to this conclusion is breath taken.

> End of discussion from my POV.

HA! Consensus by Osmosis! Wonderful! Its only the beginning too!

Sorry, absolutely not, your POV is ignorant of its origins.  Shows a 
lack of understand of the protocol and reasons for implementation. To 
conveniently avoid key points, including this:

6.  Security Considerations

    This extension provides an optimization to allow an SMTP client to
    identify the responsible submitter of an e-mail message in the SMTP
    protocol, and to enable SMTP servers to perform efficient validation
    of that identity before the message contents are transmitted.

Providing feedback of a major concern in MARID on the PAYLOAD burden 
SIDF promoted on SPF supported systems, but more importantly section 
4.2 describing the mechanism peppered with SENDER-ID methods information:

4.2.  Processing the SUBMITTER Parameter

    Receivers of e-mail messages sent with the SUBMITTER parameter SHOULD
    select the domain part of the SUBMITTER address value as the
    purported responsible domain of the message, and SHOULD perform such
    tests, including those defined in [SENDER-ID], as are deemed
    necessary to determine whether the connecting SMTP client is
    authorized to transmit e-mail messages on behalf of that domain.

    If these tests indicate that the connecting SMTP client is not
    authorized to transmit e-mail messages on behalf of the SUBMITTER
    domain, the receiving SMTP server SHOULD reject the message and when
    rejecting MUST use "550 5.7.1 Submitter not allowed."

    If the receiving SMTP server allows the connecting SMTP client to
    transmit message data, then the server SHOULD determine the purported
    responsible address of the message by examining the RFC 2822 message
    headers as described in [PRA].  If this purported responsible address
    does not match the address appearing in the SUBMITTER parameter, the
    receiving SMTP server MUST reject the message and when rejecting MUST
    use "550 5.7.1 Submitter does not match header."

    If no purported responsible address is found according to the
    procedure defined in [PRA], the SMTP server SHOULD reject the message
    and when rejecting MUST use "554 5.7.7 Cannot verify submitter
    address."

All and all, you still use SENDER-ID logic but now at the SMTP level. 
This SENDER-ID method is fundamentally the same method as SPF, same 
namespace, but a different tag, just a set of different rule.

How anyone can say the two technologies are not related when SPF2.0 is 
basically the same SPF1 under certain conditions, is very odd to me. 
   With SUBMITTER, it simply does the same but without needing the 
payload.

To suggest is "completely unrelated" is patently technical false and 
your desire to avoid the issue by ignoring it, is just not right if 
you intent is to kill SIDF/SUBMITTER.

All I am reading from you is a lack of feel for the protocols that you 
probably never supported before. So no feel for it.

---

From: S Moonesamy <[email-masked]>
Date: Wed, 22 Feb 2012 08:14:08 -0800

Hello,

The thread about "SUBMITTER usage" is off-topic.  Discussing about 
Issues #2, #3, #8, and #9 is on-topic:

http://www.ietf.org/mail-archive/web/spfbis/current/msg00426.html
http://www.ietf.org/mail-archive/web/spfbis/current/msg00439.html
http://www.ietf.org/mail-archive/web/spfbis/current/msg00441.html
http://www.ietf.org/mail-archive/web/spfbis/current/msg00442.html

Requests for data relevant to the SPFBIS work and providing data is on-topic.

I recommend that Working Group participants read the SPFBIS Charter ( 
https://datatracker.ietf.org/wg/spfbis/charter/ ).  The issues in the 
tracker can be read at 
http://trac.tools.ietf.org/wg/spfbis/trac/report/1  Please do not 
start any off-topic thread as it is a distraction from the threads on 
which the WG Chairs have requested input.

If you have any questions about the above, please email the WG Chairs.

Regards,
S. Moonesamy
SPFBIS WG co-chair

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 22 Feb 2012 11:28:41 -0500

Dear colleagues,

This message is about WG operation.  It is a reminder about how we
will comport ourselves on this list.  I'm hanging this on Hector's
message, but it's a general reminder.

> HA! Consensus by Osmosis! Wonderful! Its only the beginning too!

The moderators of this list are not going to tolerate rants and
sarcastic comments.  Please restrain yourselves.

> Providing feedback of a major concern in MARID on the PAYLOAD burden

As an official matter, we don't know what MARID concluded because none
of the RFCs were in fact output of the WG.  Claims about MARID and
what that WG was interested in are completely off-topic here: that was
another WG at another time, and this WG does not have the same
charter.  Please do not attempt to use claims about what MARID wanted,
said, thought, or whatever in these discussions.

One can have a legitimate discussion about whether SUBMITTER is
relevant to ending the SPF experiment.  But one has to stay on-topic
to do it, please.  For this WG to be productive, we must all
discipline ourselves to ensure that our emotions do not get the better
of us, and your chairs will step in at the first sign that the
conversation is crossing that line.  Remember, too, that email does
not come with all of the additional clues that in-person communication
does; please write accordingly.  If you are inclined to send a
message, consider it twice before sending: sometimes an argument can
be made at once more neutral and technically stronger.  Finally, we
very strongly oppose direct personalization of the discussion; please
don't do it.

Thanks and best regards,

A (as moderator)

-- 
Andrew Sullivan
[email-masked]

---

From: Paul Midgen <[email-masked]>
Date: Wed, 22 Feb 2012 17:40:16 +0000

All our systems that work with SPF records exclusively use TXT queries, there are no logged sender support requests, that I'm aware of, asking for type 99 query support.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Tuesday, February 21, 2012 11:29 PM
To: [email-masked]
Subject: Re: [spfbis] SUBMITTER usage

> published for 6+ years. If by now there isn't a vocal and deployed 
> base prepared to share data and operational experience that supports 
> the inclusion of a given thing, that should carry a bit of weight.
> 

Thanks, Paul.

-MSK