Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment

From: Douglas Otis <[email-masked]>
Date: Tue, 01 May 2012 05:51:22 -0700

On 4/30/12 2:25 PM, Scott Kitterman wrote:
> On Monday, April 30, 2012 06:29:40 AM Murray S. Kucherawy wrote:
>> I have made the changes stated below in my working copy, but will hold off
>> including them in a posted -08 until we're sure there's no objection and
>> WGLC has ended (or the chairs direct me otherwise).
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On Behalf
>>> Of Dave Crocker Sent: Sunday, April 29, 2012 10:54 AM
>>> Cc: [email-masked]
>>> Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment
>>>
>>>> 3.1.  DNS Resource Record Types
>>> ...
>>>
>>>> these surveys pulled a large number of domain names
>>>>
>>>>     from recent activity logs
>>> The surveys are, presumably, distinguished by which activity logs they
>>> were based on.  The introduction should state this and should provide
>>> some basic description of the operational activities that provided the
>>> sources of logging data.  A log from a personal email operation is a
>>> rather different sampling environment from an email service provider
>>> having hundreds of millions of mailboxes...
>> In all cases they were based on domains found in actual email traffic, so
>> I've tweaked that text to say so explicitly.
>>> As I recall, these are activity logs of large receivers.  Unless there
>>> is a reason to sanitize their names, use them.
>> I've added the survey numbers in the case of the DNS surveys to the credits
>> at the end, which allows attribution.  I could add them parenthetically to
>> the "DNS Survey #X" tags as well if you like.
>>> Also, what is the difference between an "activity log" and a
>>> "nameserver
>>> log"?  The text uses both terms without explanation. (I'm suggesting
>>> adding clauses, not sentences, to explain these.)
>> Clarified in the text.  "activity log" is email traffic data; "nameserver
>> log" is a trace of queries received by a nameserver.
>>>> 3.2.  Implementations
>>> It might be worth adding an analytic conclusion suggesting that these
>>> data point mean that there are reasonably good software choices for
>>> using either mechanism, so that the gating factor probably was
>>> operational policy, rather than lack of coding sources.
>> Added.
>>
>>>> 3.3.  The SUBMITTER SMTP Extension
>>> I suggest starting with a one sentence summary of the function.  It
>>> isn't explained elsewhere in the doc.
>>>
>>> Hmmm, probably worth doing a sentence describing PRA, too.
>> Added.
>>
>>>> Fewer than 4.5% of these advertised the
>>>>
>>>>     SUBMITTER extension.
>>> This is picky, but the earlier, table format for this kind of data,
>>> makes it particularly easy to extract core data from the document.  I
>>> suggest re-using the format for all data, such as the one here.
>> I'll see what I can come up with.  There are so few numbers in this case
>> that it seems like overkill to create a table, but perhaps I can add a line
>> that's more illustrative to make it worthwhile.
>>>> Over 97% of the responding MTAs advertising the SUBMITTER SMTP
>>>>
>>>>     extension were different instances of one MTA.
>>> My general fear of common problems in casual reading during reviews
>>> worries that this sentence might be mis-read to mean that 97% of active
>>> MTAs implement the feature, rather than 97% of the 4.5%.
>> Fixed.
>>
>>>> 4.  Evidence of Differences
>>> It is probably worth adding a sentence at the end of this section that
>>>
>>> observes something along the lines of:
>>>        Anecdotally, the differences in conclusions have not been noted
>>>
>>> as
>>> causing significant operational problems by the email-receiving
>>> community.
>> Added.
>>
>>>> 5.  Analysis
>>> ...
>>>
>>>> 6.  Although they may be marginal, there remain obstacles to
>>>>
>>>>         deployment of protocols that use DNS RRTYPEs other than the
>>> most
>>>
>>>>         common ones,
>>> Drop the opening clause.  Opinions about the import of the obstacles
>>> vary quite a bit, and it is not necessary to resolve it in this
>>> document.
>>>
>>> The fact is that barriers remain and that they are important enough to
>>> mention here.
>> Done.
>
> Since you're doing another update, I'll take another shot at resolving my
> objection to the introduction....
>
> The current published version starts:
>
>     In April 2006, the IETF published the [SPF] and Sender ID email
>     authentication protocols, the latter consisting of three documents
>     ([SUBMITTER], [SENDER-ID], and [PRA]).  Both of these protocols
>     enable one to publish via the Domain Name System a policy declaring
>     which mail servers were authorized to send email on behalf of a
>     specific domain name.  The two protocols made use of this same policy
>     statement and some specific (but different) logic to evaluate whether
>     the email client sending or relaying a message was authorized to do
>     so.
>
>     Consensus did not clearly support one protocol over the other, and
>
>     there was significant concern that the two would conflict in some
>     significant operational situations, interfering with message
>     delivery.  The IESG required the publication of all of these
>     documents as Experimental, and requested that the community observe
>     deployment and operation of the protocols over a period of two years
>     from the date of publication in order to determine a reasonable path
>     forward.
>
> Reading it again, I'm also not sure any reference to consensus is appropriate
> as there were never any IETF attempts at consensus on these two documents.
> I'd be happy with the following if you think it's OK:
>
>     In April 2006, the IETF published the [SPF] and Sender ID email
>     authentication protocols, the latter consisting of three documents
>     ([SUBMITTER], [SENDER-ID], and [PRA]).  Both of these protocols
>     enable one to publish via the Domain Name System a policy declaring
>     which mail servers were authorized to send email on behalf of a
>     specific domain name.   There was significant concern that the two would
>     conflict in some significant operational situations, interfering with message
>     delivery.
>
>     The IESG required the publication of all of these documents as
>     Experimental, and requested that the community observe
>     deployment and operation of the protocols over a period of two years
>     from the date of publication in order to determine a reasonable path
>     forward.
>
> I think that says enough for our purpose and avoids the issue I was concerned
> about.
Dear Scott,

Agreed, misstatement of consensus effort should be corrected. This text 
does just that well.

Regards,
Douglas Otis

---

From: John Leslie <[email-masked]>
Date: Tue, 1 May 2012 09:36:39 -0400

I think Scott's Introduction text is good, but I'd raise one nit:

>    specific domain name.   There was significant concern that the two would
                                       ^^^^^^^^^^^
   I'd drop this "significant".

>    conflict in some significant operational situations, interfering
>    with message delivery.  
> 

--
John Leslie <[email-masked]>

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 01 May 2012 09:41:09 -0400

> >    specific domain name.   There was significant concern that the two

I'm OK with it either way.  That's carried forward from the current text.  At 
the time, I think the concern was significant (else they'd have just approved 
them both), but if people prefer that dropped, I think it's fine.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 1 May 2012 13:45:52 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Tuesday, May 01, 2012 6:41 AM
> To: [email-masked]
> I'm OK with it either way.  That's carried forward from the current
> text.  At the time, I think the concern was significant (else they'd
> have just approved them both), but if people prefer that dropped, I
> think it's fine.

I think it's semantically correct to include it, but use of the same word twice in the same sentence close together is just weak writing.  So I'm fine either taking it out or replacing it with "substantial" or something.

-MSK

---

From: Barry Leiba <[email-masked]>
Date: Tue, 1 May 2012 11:20:31 -0400

> I think it's semantically correct to include it, but use of the same word twice
> in the same sentence close together is just weak writing.  So I'm fine either
> taking it out or replacing it with "substantial" or something.

I like the diffs, and I'm happy with Scott's proposed change (with or
without the "significant" or "substantial" word).

Barry

---

From: Dave Crocker <[email-masked]>
Date: Tue, 01 May 2012 08:28:12 -0700

> without the "significant" or "substantial" word).

+1

d/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

---

From: Hector Santos <[email-masked]>
Date: Tue, 01 May 2012 11:31:08 -0400

>>    specific domain name.   There was significant concern that the two would

+1 on dropping or change it to below:

IMO, it is was significant (or substantial) then why was it 
immediately addressed then or in fact, just not dropped?  There was no 
"significant concern" from the stand point of # of people, however, I 
suggest:

    There were concerns .....

and that would be good enough and more accurate in either direction.

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

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 07 May 2012 19:45:42 +0200

On Mon 07/May/2012 10:14:36 +0200 Andrew Sullivan wrote:
> 
> Please perform a complete review of the document and send your remarks
> to the mailing list.

Although I agree with the text composed thus far, I think the
Resolution of The SPF and Sender ID Experiments lacks some
consideration of the interoperability issues that SPF causes.  Such
issues are relevant to the resolution of the experiment inasmuch as
they are part of the reasons why SPF and Sender ID were given
Experimental status.

I propose the following additions/changes:

Section 3.2 *Implementations*
First part of the introductory paragraph moved to the new subsection:

OLD
  It is likely impossible to determine from a survey which Mail
  Transfer Agents (MTAs) have SPF and/or Sender ID checking enabled at
  message ingress since it does not appear, for example, in the reply
  to the EHLO command from extended [SMTP].  We therefore rely on
  evidence found via web searches, and observed the following:

NEW
  We collected evidence of existing implementations of the core
  functionality via web searches, and observed the following:

New subsection of Section 3 *Detectable Checks*

  An active survey cannot determine which Mail Transfer Agents (MTAs)
  have SPF and/or Sender ID checking enabled at message ingress since
  it does not appear, for example, in the reply to the EHLO command
  from extended [SMTP].  Nevertheless, the option to reject a sender
  at the early stages of an SMTP transaction is provided for by
  [RFC4408].

  Our test program was able to start an SMTP session in about 80% of
  cases.  After EHLO, it issued a MAIL command with an SPF-invalid
  parameter such as <[email-masked]> --a domain publishing a TXT
  RR with "v=spf1 -all".  In 78% of cases MAIL was accepted.  In
  about 1.2% of the sample cases, the domain's MX server rejected the
  SPF-invalid parameter but accepted both an RSET and a subsequent
  MAIL command with an SPF-valid sender.

  While the ability to start a session only characterizes the sample
  (random parts of DNS Survey# 2) and possibly the testing host, that
  small percentage of rejections seems to be stable under variations
  of the sample and the helo identity.  On answering a questionnaire
  submitted to 70 mail admins, 14 of them (29%) said SPF can cause
  rejection on their systems.  However, rejection does not have to
  occur at the MAIL command, and SPF results may just contribute to
  message score.

Section 5. *Analysis*

The added subsection can be condensed in an additional point[*]:

  N.  SPF can be deployed with relative ease, and causes no
      interoperability problems except those that can be solved using
      some sort of sender rewriting scheme.

[*] See Ned's answers (2) and (3) to his own questions in
http://www.mhonarc.org/archive/cgi-bin/mesg.cgi?a=ietf-smtp&i=01OF6HRP963S0006TF%40mauve.mrochek.com

I don't attempt to add to the Conclusions, but alluding to a recharter
for SPF deployment --Ned's "mitigation strategies"-- might be in order.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 7 May 2012 18:10:17 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Monday, May 07, 2012 10:46 AM
> To: [email-masked]
> Cc: Ned Freed
> [...]

I don't believe we're chartered to re-evaluate why SPF and Sender ID were given Experimental status.  The answer to that question for those that wonder is in the IESG Note added to RFC4405-4408.

>   MAIL command with an SPF-valid sender.

This sample shows that in 22% of your tests, the MTA rejected the envelope sender.  How do you know for certain that SPF is the reason?  And for the 78% that accepted it, it's not possible to tell whether SPF (or Sender ID) is in use.

As for the additional conclusion, that's an interesting conclusion if it's also the case that we can say something comparative about Sender ID.  Do you have something like that to include?

But more importantly, how does this help us resolve the experiment question?  The question we're answering is "Which has seen wider use?", and we're specifically avoiding speculation about why.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 07 May 2012 13:48:24 -0500

"Murray S. Kucherawy" <[email-masked]> wrote:

>I don't believe we're chartered to re-evaluate why SPF and Sender ID
>were given Experimental status.  The answer to that question for those
>that wonder is in the IESG Note added to RFC4405-4408.
>
>This sample shows that in 22% of your tests, the MTA rejected the
>envelope sender.  How do you know for certain that SPF is the reason? 
>And for the 78% that accepted it, it's not possible to tell whether SPF
>(or Sender ID) is in use.
>
>As for the additional conclusion, that's an interesting conclusion if
>it's also the case that we can say something comparative about Sender
>ID.  Do you have something like that to include?
>
>But more importantly, how does this help us resolve the experiment
>question?  The question we're answering is "Which has seen wider use?",
>and we're specifically avoiding speculation about why.

FWIW, Postfix, by default, defers all such processing to the recpt to stage when checking SPF (and other things) via its policy interface. I don't know what fraction of the queried MTAs were Postfix, but that's an example of why we can't draw too much from these numbers.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 07 May 2012 21:04:47 +0200

On Mon 07/May/2012 20:44:16 +0200 Murray S. Kucherawy wrote:
>> From: ietf.org On Behalf Of Alessandro Vesely
>
> envelope sender.

No, 22% includes a 20% of servers that I couldn't start a session
with.  The feebly detectable trace of SPF deployment is in the
remaining 2%.  Sorry if I misreported that.

> How do you know for certain that SPF is the reason?

Some of that 2% didn't take RSET, some rejected the good sender too.
About 1.2% seems to be discerning SPF.  That percentage varies with
the sample (1.6 among #2 domains publishing "-all", 2.5% for the
domains from my inbox.)

> And for the 78% that accepted it, it's not possible to tell whether
> SPF (or Sender ID) is in use.

Not without overly intrusive and abusive surveying.  And also, it
would be more instructive to reason in terms of email addresses rather
than domains, but I'm not going to buy a million-address CD for that :-)

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 7 May 2012 19:29:27 +0000

> From: Alessandro Vesely [mailto:[email-masked]]
> Sent: Monday, May 07, 2012 12:05 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]; Ned Freed
> No, 22% includes a 20% of servers that I couldn't start a session with.
> The feebly detectable trace of SPF deployment is in the remaining 2%.
> Sorry if I misreported that.
> 
> Some of that 2% didn't take RSET,

They violate RFC5321 Section 4.1.1.5.

> some rejected the good sender too.
> About 1.2% seems to be discerning SPF.

1.2% seems to be applying reject-on-failure for SPF at the MAIL command.  Scott points out there are other implementations, and that's assuming those rejections are all caused by SPF, which cannot be determined.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 08 May 2012 09:54:53 +0200

On Tue 08/May/2012 09:30:27 +0200 Murray S. Kucherawy wrote:
>> From: Alessandro Vesely
> 1.2% seems to be applying reject-on-failure for SPF at the MAIL
> command.  Scott points out there are other implementations, and
> that's assuming those rejections are all caused by SPF, which
> cannot be determined.

Yup.  When you see the attached text it looks clear.  The further the
SMTP transaction, the fuzzier the SPF contribution.  For example,
consider a server who accept SPF-invalid senders only if it finds
valid DKIM signatures.  It would reject after end of data, using a
convoluted message.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 8 May 2012 16:17:18 +0000

> Sent: Tuesday, May 08, 2012 12:55 AM
> To: [email-masked]
> consider a server who accept SPF-invalid senders only if it finds valid
> DKIM signatures.  It would reject after end of data, using a convoluted
> message.

Two of your examples are ambiguous as to whether it was an SPF decision.

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 09 May 2012 13:23:34 +0200

> Two of your examples are ambiguous as to whether it was an SPF decision.

I guess you mean "554 Sending address not accepted due to spam filter"
(well, that's one).  I only queried for the top ten, so probably there
are more cases that don't mention SPF explicitly.
Some ambiguity is intrinsic in this kind of test, and in statistics in
general.

Actually, I inferred SPF checking by just the first digit of the reply
code and how it changed submitting an spf-valid sender.  Rather than
sweeping all the names, I run two random ~30K-item samples varying the
helo identity, obtaining 1.11% after an address literal and 1.21%
after a proper helo name.  I also run a much smaller sample (~5K
names) with the same helo name and got 1.18%.  Thence I draw that such
result is stable.  However, its value depends on the domain names
where I extracted the samples from, because on a 558-item sample
extracted from my inbox I got 2.77% (address literal) and 2.75%
(proper helo name) --no surprise that an inbox is cleaner than
activity logs.

This test shows that a base of indomitable MTAs who do reject-on-fail
exists.  At the same time, the test shows that reject-on-fail is so
hard to deploy as to be uncommon in practice.

Anyone else has an opinion on this?  Arguably, reject-on-fail is one
of the "serious open issues" mentioned in the IESG Note, since it
would seriously affect interoperability if it were widespread.

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 09 May 2012 06:28:03 -0500

Alessandro Vesely <[email-masked]> wrote:

>valid

Only if done improperly. The architectural concerns only arise if it's not done at the border.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 9 May 2012 13:32:39 +0000

> Sent: Wednesday, May 09, 2012 4:24 AM
> To: [email-masked]
> Anyone else has an opinion on this?  Arguably, reject-on-fail is one of
> the "serious open issues" mentioned in the IESG Note, since it would
> seriously affect interoperability if it were widespread.

Since reject-on-fail was not a mandatory component of RFC4408, as has already been pointed out many times, and since a co-chair formally declared on April 20th that this was off-topic, we really need to drop this.  At a minimum, it has nothing to do with the experiment, and is consuming our energy which we'll need for our second deliverable.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Wed, 09 May 2012 09:53:14 -0400

> Since reject-on-fail was not a mandatory component of RFC4408, as has already 
> been pointed out many times, and since a co-chair formally declared on April 
> 20th that this was off-topic, we really need to drop this.  At a minimum, it has 
> nothing to do with the experiment, and is consuming our energy which we'll 
> need for our second deliverable.
> 

-1.

I disagree with your assessment.

It (REJECT-ON-FAIL) is and always was a critical mandatory part of 
RFC4408 and there should be not ambiguity about long time history of 
deployment it at all scales and from the purity of  a raw protocol, 
despite the scale level of usage.

I believe the co-chair declared that the idea of whether 
REJECT-ON-FAIL was part of the protocol or not, was off-topic.  Not 
that REJECT-ON-FAIL is not part of the protocol.  I believe the 
miscommunication was related to RFC119 level language.

I agree REJECT-ON-FAIL has nothing to do with the experiment because 
its already part of the protocol considerations and should not be 
questioned whether its an deployment option or not.

However, as issue #29 exemplifies, the local deployment option to 
choose REJECT-ON-FAIL or MARK-ON-FAIL, is very critical for RFC4409bis 
from many angles and in particular security related.  The clear 
outline reasoning showing where and why are things that should not be 
watered down as insignificant.

It would incredibly awesome to recognize these points and in the 
interest of reducing WG noise, not wait for escalation to occur to 
finally realize REJECT-ON-FAIL is a significant part of the protocol. 
  To not do so, will be wasting energy.

-- 
Hector Santos
http://www.santronics.com
http://hector.wildcatblog.com
jabber: [email-masked]

---

From: Hector Santos <[email-masked]>
Date: Wed, 09 May 2012 10:14:11 -0400

> would seriously affect interoperability if it were widespread.

My view is that REJECT-ON-FAIL or MARK-ON-FAIL are mandatory part of 
the purity of the SPF Protocol as deployment options and there should 
be no ambiguity about its usage, level of usage and who is using it.

The only issue I have is related to protocol consistency when it comes 
to the local deployment option to use one or the other.  In the end, 
both options SHOULD yield the same result and/or conclusion when the 
POV of the targeted user otherwise we have a *security loophole*.

I have a problem that this is not recognized. I have provided 
background reasoning and also proposed some text to help close the 
security loophole potential with insights that local deployments MUST 
consider when choosing MARK-ON-FAIL over REJECT-ON-FAIL mode of local 
site operation.

To assume REJECT-ON-FAIL is not in play is an major fault in this WG 
thinking. To assume MARK-ON-FAIL is the only way SPF is deployed is a 
major fault in this WG thinking.

Both at part of the protocol and implementations SHOULD be prepared to 
offer it to operators, and SPF publishers of -ALL policy SHOULD be 
aware that any publicly exposed policy desire to reject-on-fail to 
help protect spoofing of their domains may not always happen. But I 
suggest that they do expect a negative classification and stream 
separation for the benefit of the user not to be harm by the receiver 
passing on -ALL failed messages.

We can't control how MARK-ON-FAIL will be done, but RFC4408BIS SHOULD 
NOT be blind about it either.  There is one reference to it and no 
definition behind it.  REJECT-ON-FAIL is very clear. Mail Rejection, 
User does not get mail. How will the user see a MARK-ON-FAIL message?

---

From: Hector Santos <[email-masked]>
Date: Wed, 09 May 2012 11:14:24 -0400

Hi,

I think the changes made to address my concerns were adequate and with 
its stated framework, it should be acceptable.

However, I wish to state I believe the framework was in error as the 
Interop report offers very little in presenting anything new and very 
little in helping to address issues cataloged to help codify the 
pending RFC4408BIS work.

In other words, the worth of the interop value would had increased if 
it had help address some of real deployment concerns and/or ambiguity 
in RFC4408. i.e. REJECT-ON-FAIL vs MARK-ON-FAIL.

Instead, the report focused on addressing on what should be done 
between SenderID and SPF with too much energy spent on promoting the 
notion SenderID should be abandoned using data that isn't really all 
unexpected, new or help to show that it should be abandoned.

(Note, the one thing gain was the Type 99 issue, where I felt it 
wasn't used, but the report had changed my mind regarding continuation 
to explore usage.)

In other words, overall, nothing gain by this report.  But at the very 
least, as it was written, it works for me.

I don't know what the above means to the IETF consideration regarding 
WGLC and leave it to you to be the judge.

Andrew Sullivan wrote:
> Dear colleagues,
> 
> This message begins a 2 week Working Group Last Call on the document
> draft-ietf-spfbis-experiment-07.
> 
> Your chairs would like to be sure that the document really represents
> WG consensus in the event we forward the document to the IESG for
> publication.  As a result, we would like to see as many reviewers as
> possible who state that they have read the document and approve its
> publication, and in no case fewer than five.  In the case of those who
> have read and reviewed previous versions of the document, we would
> like evidence that you are amenable to changes that have been made in
> response to your comments; we will count those among the five.
> ("Five" is an arbitrary number intended to be a minimal threshold of
> review; if we can't find five people who say something is a good idea
> to publish, it's hard to argue that there's any interest at all.)
> 
> SM will be the document shepherd for this document.
> 
> This last call closes on 2012-05-09 at 00:00 UTC.
> 
> Best regards,
> 
> Andrew 
>

---

From: S Moonesamy <[email-masked]>
Date: Sun, 13 May 2012 00:23:45 -0700

Hi Alessandro,
>   occur at the MAIL command, and SPF results may just contribute to

I didn't explain why I did not make use of the questionnaire and its 
results as I thought that it was obvious.  It's not about your work 
not being good.

If I am going to make use of the opinion of 70 mail admins, someone 
might ask whether "well deployed" means at least 70 people.  It's not 
convincing to say that 14 not-so-random people are doing X.  People 
who have a strong opinion about X might argue otherwise.  It is 
better to consider the perspective of people who have not been 
involved in the WG.

Regards,
S. Moonesamy (as document shepherd)

---

From: Hector Santos <[email-masked]>
Date: Sun, 13 May 2012 12:18:27 -0400

>>   occur at the MAIL command, and SPF results may just contribute to

My Opinion:

I don't get it why ADMINS will dispute and make life harder to ignore 
the -ALL declaration of what is considered "bad" within SPF when the 
domain owner is telling you!

-ALL is BAD, not MAYBE BAD, not "I don't know".   If the domain thinks 
it is MAYBE BAD, then that is what SOFTFAIL (~ALL) is for.  If the 
domain is completely ignorant of its operations, then that is what the 
?ALL declaration is far.

But -ALL is BAD and the domain publisher knowns better than anyone else.

I can understand how this conflicts with people who have this 
"Reputation" angle view of things.  But when one ignores the strong 
-ALL declaration, all it does it add delayed, belated, complex, 
unknown, non-consistent, non-persistent, ADMIN level "Favorite SPAM 
tool" derivatives across different sites which at the end of the day 
all yield different belated results and/or scores when it SHOULD all 
yield the same ultimate result, it was BAD after all.

Admins should consider the huge DNS overhead SPF presents at the 
system level and it is critical that this overhead is minimized and 
come with some level of a payoff, not come with complete indeterminate 
results even for the -ALL declaration.

I will venture that domains that have a -ALL published have a near 
100% REJECT-ON-FAIL expectation and a near 100% deployment at the 
applying it to others as well.   In other words, you expect others 
will do the same your -ALL violations as you will do to their -ALL 
violations.

If MARK-ON-FAIL is actually the recommended mode of operations, then 
unless this is strongly defined in SPF-BIS, I don't think I can 
continue to endorse SPF or support for a IETF proposed standard.

There are many domains with -ALL, even with ietf.org:

     v=spf1 ip4:12.22.58.0/26
            ip4:64.170.98.0/26
            ip4:208.66.40.224/27
            ip6:2001:1890:123a::0/56
            ip6:2001:1890:1112:1::0/64
            -all

Its telling me what to expect for its MTAs.  Why should anyone dispute 
what the DNS record publisher thought very hard of what it was doing 
here with a -ALL declaration?  If he/she wasn't sure, it would of had 
a SOFTFAIL (~ALL) or NEUTRAL (?ALL).

Just follow the protocol, its that simple. -ALL violations means BAD 
and the only real protocol problem is the undefined MARK-ON-FAIL 
deployment option.  REJECT-ON-FAIL is well understood and simple 
definition, SMTP 550 rejection.

-- 
HLS