Subject: Re: [spfbis] #33: Marked Failed Mail Exposure

From: S Moonesamy <[email-masked]>
Date: Fri, 07 Sep 2012 03:32:23 -0700

Hello,

I'll comment as an individual.  The example of the security issue at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg02246.html 
shows a Received-SPF: header field with a SPF result of "fail".  It 
was mentioned that "its recommended it (the message) should not be 
part of the normal pop3 mail pick up".  The outcome is similar to 
rejecting the message.

A message was posted at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg02331.html 
about the question of rejecting a message on SPF Fail.  I read 
another message ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg02370.html ) 
about marking a message on SPF Fail.  In my individual opinion, this 
issue is about not delivering a message that fails SPF evaluation to 
the intended mailbox.  It can be argued that such a message might 
contain hostile content.  Is that attack even in scope for the protocol?

Regards,
S. Moonesamy

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 07 Sep 2012 09:17:42 -0400

> contain hostile content.  Is that attack even in scope for the protocol?

I think it is, but only barely.  It is probably worth mentioning that if you 
deliver messages that were not authorized by the domain owner, some of them 
may be malicious.  That doesn't make it unreasonable to do so as there are 
also quite legitimate ways messages can end up coming from not authorized 
sources.  It's a trade off that designers of receiving systems have to make, so 
while I think we could mention it, I don't think it's in the scope of the 
protocol to solve it.

Scott K

---

From: Dotzero <[email-masked]>
Date: Fri, 7 Sep 2012 09:36:48 -0400

> while I think we could mention it, I don't think it's in the scope of the

+1

I go with the folks that have previously indicated that SPF is an MTA
to MTA protocol. 4408 provided two things a receiver could do on fail
(reject or mark). That was the extent of telling receivers what to do.
We should be very careful about introducing new meanings in the bis
document.

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 7 Sep 2012 13:03:43 -0700

> while I think we could mention it, I don't think it's in the scope of the

I agree.  I'm not even sure what one could say; legitimate messages
can arrive without SPF authorization, and illegitimate messages can
arrive with SPF authorization.  The logical reduction of that is "Some
mail is bad", or more usefully, "You might receive bad mail
irrespective of authorization."  We might say simply that and be done
with it.

-MSK

---

From: S Moonesamy <[email-masked]>
Date: Fri, 07 Sep 2012 13:52:39 -0700

>irrespective of authorization."  We might say simply that and be done

The above idea is worth exploring.  It would help to put this issue 
to rest.  The WG could adopt the idea as a way forward if there is agreement.

Regards,
S. Moonesamy

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 07 Sep 2012 17:05:35 -0400

> to rest.  The WG could adopt the idea as a way forward if there is

I'm fine with it, but ....  There is a subtlety that while the above is true, 
there is definitely a differentiation of risk between the two.  For "bad" 
domains, authorized or not, the mail is likely to be "bad".  For "good" 
domains, not authorized mail is substantially more likely to be "bad" than 
authorized domains.  Unfortunately I no longer have access to the data set I 
used to establish this to my satisfaction (and it was private in any case), so 
I can't prove the assertion.

I think that if we can get some flavor of differentiation in there, it will be 
sufficient, but I'm not sure how to do it without opening Pandora's box.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Fri, 07 Sep 2012 18:10:01 -0400

Dotzero wrote:

> 4408 provided two things a receiver could do on fail

There is no new meaning.

Issue #33 is basically stating mark-on-fail MUST|SHOULD be 
semantically equivalent to a REJECT-ON-FAIL from a security and 
functional standpoint.  It would be an obvious security leak otherwise.

Also consider the following:

Issue #33 also provides non-normative insight for backend operators to 
take precautions. This was carefully worded with the hope of providing 
a compromise and also targeted at two audiences:

  1) Early SPF 2003 adopters who used original 2003 SPF specifications 
with RFC2119 normative
     languages for a REJECT-ON-FAIL [1][2][3]

      Fail (-): the message does not meet a domain's definition of
      legitimacy.  MTAs MAY reject the message using a permanent
      failure reply code.  (Code 550 is RECOMMENDED.  See [RFC2821]
      section 7.1.)

     The MARID production with RFC4408 only relaxed it to appears the 
IETF adoption
     process among the mail community who typically have concerns with 
strong languages
     towards mail rejection concepts.   Early adopters would not be 
changing their
     operations. Some may have added logic to mark-on-fail, but it 
would incomprehensible
     to believe they would just accept and mark it without separating 
the mail.

  2) New developers working off 4408bis with stronger A-R reporting 
emphasis having
     no rejection features. They MUST be made aware of their security 
issues in this
     higher focus Mark-on-Fail mode of operation.

[1] http://tools.ietf.org/html/draft-mengwong-spf-00
[2] http://tools.ietf.org/html/draft-mengwong-spf-01
[3] 
http://www.openspf.org/svn/project/specs/drafts/draft-mengwong-spf.02.9.4.txt

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Fri, 07 Sep 2012 18:31:01 -0400

Please take into account that there were many early pre-4408 early 
adopters that following the RFC2119-like compliancy language such as 
the one in section 3 [1]

     --------------------
    3. SPF Record Evaluation

    An SPF client evaluates an SPF record and produces one of seven
    results:

      None: The domain does not publish SPF data.

      Neutral (?): The SPF client MUST proceed as if a domain did not
      publish SPF data.  This result occurs if the domain explicitly
      specifies a "?" value, or if processing "falls off the end" of
      the SPF record.

      Pass (+): the message meets the publishing domain's definition of
      legitimacy.  MTAs proceed to apply local policy and MAY accept or
      reject the message accordingly.

      Softfail (~): the message does not meet a domain's strict
      definition of legitimacy, but the domain cannot confidently state
      that the message is a forgery.  MTAs SHOULD accept the message
      but MAY subject it to a higher transaction cost, deeper scrutiny,
      or an unfavourable score.

    There are two error conditions, one temporary and one permanent.

      Error: indicates an error during lookup; an MTA SHOULD reject the
      message using a transient failure code, such as 450.

      Unknown: indicates incomplete processing: an MTA MUST proceed as
      if a domain did not publish SPF data.

    When SPF-aware SMTP receivers accept a message, they SHOULD prepend a
    Received-SPF header.  See section 6.

    SPF clients MUST use the algorithm described in this section
    or its functional equivalent.

    If an SPF client encounters a syntax error in an
    SPF record, it must terminate processing and return a result
    of "unknown".

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

Please keep in mind that RFC4408 did not really alter much for early 
adopters, sure, they fine tune many of the features, added new limits, 
etc, but RFC4408 was really meant to be compatible with the existing 
early adoption and the work in 4408BIS "SHOULD NOT" dismiss the 
original spirit and intent of what the -ALL policy provided domains 
and receivers - a deterministic, powerful, near zero false positive 
method of SPOOF protection.  Lets not promote the concept that SPF 
receivers SHOULD NOT give the domain publishers the benefit of all 
doubt when it comes to the -ALL policy.

[1] http://tools.ietf.org/html/draft-mengwong-spf-01

  Moonesamy wrote:
> The above idea is worth exploring.  It would help to put this issue to 
> rest.  The WG could adopt the idea as a way forward if there is agreement.
> 
> Regards,
> S. Moonesamy
> _______________________________________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis
> 
> 

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 7 Sep 2012 15:36:29 -0700

> sufficient, but I'm not sure how to do it without opening Pandora's box.

The problem I think is that SPF doesn't have a self-contained notion
of what's good and what's bad.  That ties to reputation in some form,
whether it's a local whitelist, a DNSBL, or a full-blown reputation
service of some kind.  If we can make that clear, then the kind of
thing you're talking about is a bit more reachable from here.

I don't know where this might land, but in the interest of being brief:

Operators that choose to deliver mail for which SPF produces a "fail"
result need to understand that they are admitting content that is
explicitly not authorized by the purported sender.  While there are
known failure modes that can be considered "false negatives" <section
references here>, the choice to admit those messages can expose end
users to harm.  This is especially true for domains belonging to known
good actors that are typically well-behaved; unauthorized mail from
those sources might well be subjected to much higher skepticism and
content analysis.

SPF does not, however, include the capacity for identifying good
actors from bad ones; this is the purview of reputation systems in
their various forms, and is out of scope for this specification.

?

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 07 Sep 2012 18:50:42 -0400

On Friday, September 07, 2012 03:36:29 PM Murray S. Kucherawy wrote:
> > I'm fine with it, but ....  There is a subtlety that while the above is
> > true, there is definitely a differentiation of risk between the two.  For
> > "bad" domains, authorized or not, the mail is likely to be "bad".  For
> > "good" domains, not authorized mail is substantially more likely to be
> > "bad" than authorized domains.  Unfortunately I no longer have access to
> > the data set I used to establish this to my satisfaction (and it was
> > private in any case), so I can't prove the assertion.
> > 
> > I think that if we can get some flavor of differentiation in there, it
> > will be sufficient, but I'm not sure how to do it without opening
> > Pandora's box.

Seems like a reasonable basis for discussion.  Unless someone has better 
ideas, I'll add that in and close the issue.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Fri, 07 Sep 2012 16:18:54 -0700

Hi Hector,
At 15:10 07-09-2012, Hector Santos wrote:
>  1) Early SPF 2003 adopters who used original 2003 SPF 
> specifications with RFC2119 normative
>     The MARID production with RFC4408 only relaxed it to appears 
> the IETF adoption
>     process among the mail community who typically have concerns 
> with strong languages
>     to believe they would just accept and mark it without 
> separating the mail.

According to the SPFBIS charter, draft-ietf-spfbis-4408bis is 
intended as a standards track document defining SPF, based on RFC 
4408 and as amended above (the charter).  There isn't any mention of 
any SPF drafts.  The work is only on RFC 4408 instead of RFC 4408 and 
SPF drafts.  It is not the purpose of this working group to convince 
or force anyone to change their operations.

>adopters that following the RFC2119-like compliancy language such as 

That means ignoring the following messages:

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

and what is in the SPFBIS charter.  There isn't any mention of early 
pre-4408 in it.

>adopters, sure, they fine tune many of the features, added new 
>limits, etc, but RFC4408 was really meant to be compatible with the 
>existing early adoption and the work in 4408BIS "SHOULD NOT" dismiss 
>the original spirit and intent of what the -ALL policy provided 
>domains and receivers - a deterministic, powerful, near zero false 
>positive method of SPOOF protection.  Lets not promote the concept 
>that SPF receivers SHOULD NOT give the domain publishers the benefit 
>of all doubt when it comes to the -ALL policy.

The working group cannot change RFC 4408 if it is not compatible with 
existing early adoption.  Whether RFC 4408 did not really alter much 
or what it was really meant to be does not alter the facts.  RFC 4408 
is the starting point for draft-ietf-spfbis-4408bis.

I suggested a way to put the issue to rest ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg02656.html 
).  It is useful to have other alternatives.  Could you please 
suggest one which is in accordance with the SPFBIS charter?

Thanks,
S. Moonesamy
SPFBIS WG co-chair

---

From: Hector Santos <[email-masked]>
Date: Fri, 07 Sep 2012 19:38:46 -0400

S Moonesamy wrote:
> existing early adoption.  Whether RFC 4408 did not really alter much or 
> what it was really meant to be does not alter the facts.  RFC 4408 is 
> the starting point for draft-ietf-spfbis-4408bis.
> 
> http://www.ietf.org/mail-archive/web/spfbis/current/msg02656.html ).  It 
> is useful to have other alternatives.  Could you please suggest one 
> which is in accordance with the SPFBIS charter?

I'm lost because my original concerns are materializing and don't know 
what other simple compromise can be reached that was not proposed by 
issue #33.  It has nothing to do with REPUTATION MODELING or doubting 
the protocol compliant of an SPF Domain publishing very strong unique 
exclusive authorization policies with -ALL directives. It has to do 
with a very simple premise:

     Mark-on-Fail MUST|SHOULD be semantically equivalent to 
Reject-On-Fail both
     on a security and functional basis, otherwise you have a security 
leak.

Whats so hard about this?  I don't know where all this has gone. We 
don't need a new thesis on the SPF Theory for -ALL policies.  We know 
what it designed to do since 2003 and we also new where it faulted as 
well with unexpected relays at final destination MX sites.

Anyway, I'm lost. Going swimming! :)

-- 
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 07 Sep 2012 20:04:31 -0400

> Anyway, I'm lost. Going swimming! :)

Hector,

As far as anyone else can tell, we haven't changed anything.  I think the 
proposed security consideration explains the issue to that 
implementers/deployers are alerted to deal with it, but the issue you are (I 
think) worried about is not new and explaining it is all we can do.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 7 Sep 2012 17:22:20 -0700

> think) worried about is not new and explaining it is all we can do.

I proposed text to mention it, which could reasonably land in Security
Considerations.  We need people to review and comment on that
proposal.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Fri, 07 Sep 2012 21:37:29 -0400

What is wrong with the original issue #33 proposed text?

I think it covered all the key implementation points I believe to be 
realistic in practice without getting into the historical theory or 
any new mandates. It doesn't introduce any other "batteries required" 
concepts, non-existing protocols, layered process modeling framework 
changes, i.e. reputation frameworks that would not be persistent 
across all receivers.  It provided the key problem statement and the 
key IETF standard mail protocols references for most common mail 
hosting operations that need to consider where their possible 
integration points are to deal with this.

My point below was that -ALL was special, was always special since 
2003 and never needed any other helper technology. The new proposed 
text [1] scott is considering begins to crack open the door to 
reputation  modeling and this will now open up new concerns regarding 
the value of -ALL policies for DOMAIN. This can diminish the worth of 
the SPF protocol in a similar same way reputation revamped DKIM with 
its lost and deemphasis of a Policy-Based Security wrapper - DKIM 
original model and framework.  ADSP and the informational DKIM 
deployment guide began to tell readers that it was ok for mail 
receivers to ignore strong ADSP policies and to depend on Reputation 
Modeling, Scoring and Heuristics systems - and unfortunately, it did 
not exist!

I have no issue using additional methods for indeterminate SPF 
policies (anything but -ALL).  I hope we can keep focus here on what 
SPF hard fail policy (-ALL) offered domains and receivers. It didn't 
need anything else to function.

[1] http://www.ietf.org/mail-archive/web/spfbis/current/msg02661.html

S Moonesamy wrote:
> According to the SPFBIS charter, draft-ietf-spfbis-4408bis is intended 
> as a standards track document defining SPF, based on RFC 4408 and as 
> amended above (the charter).  There isn't any mention of any SPF 
> drafts.  The work is only on RFC 4408 instead of RFC 4408 and SPF 
> drafts.  It is not the purpose of this working group to convince or 
> force anyone to change their operations.
> 

-- 
HLS

---

From: S Moonesamy <[email-masked]>
Date: Fri, 07 Sep 2012 19:22:33 -0700

Hi Hector,
>What is wrong with the original issue #33 proposed text?

I read the following comment ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg02198.html ):

   "There's no prescription for rejection in 2.5.4.

   I think this gets into too much detail about internals of final
   delivery to the user."

It's not a matter of "what is wrong" with text.  If there is one 
paragraph which says the same thing as two paragraphs, it is better 
in my opinion to pick the one paragraph as long as there is agreement about it.

>any new mandates. It doesn't

I might agree with you but if the group agrees on other text, that 
text takes precedence.

>text [1] scott is considering begins to

Ok.

Would you be ok with the following text:

   SPF does not, however, include the capacity for identifying good
   actors from bad ones; this is out of scope for this specification.

Note that the above text still requires strong agreement for it to be 
included in the document.

Regards,
S. Moonesamy

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 08 Sep 2012 13:03:46 +0200

On Sat 08/Sep/2012 00:36:29 +0200 Murray S. Kucherawy wrote:
>> authorized domains.

I don't agree with the last sentence, unless "good" is intended to
mean relaxed, broad authorizations.  Mail can be forwarded without
notice and without rewriting --so as to fool the smtp.mailfrom SPF
check-- irrespectively of the domain's goodness.

> thing you're talking about is a bit more reachable from here.

Possibly, but that's definitely at a different layer.  IMHO, we should
stick to the more basic notion of _registered domain_.  If it is
registered, people can find abuse reporting addresses, including
reputation trackers', and complain as they like.  It's someone else's
job to make sure that's effective.  Dealing with "bad" registered
domains is not our job.  SPF won't and can't do anything about it.

> users to harm.

Yes, that's the essence of #33.

> This is especially true for domains belonging to known good actors
> that are typically well-behaved; unauthorized mail from those
> sources might well be subjected to much higher skepticism and 
> content analysis.

Again, I disagree with that sentence [see why].

False negatives need whitelisting, either on recipient's initiative,
e.g. producing a sample message retrieved from the spam folder, or on
sender's initiative after getting a bounce.  That's mark vs reject.

Abating false negatives is a distinct problem, unrelated to coping
with them, albeit the abundance of false positives favors marking
inasmuch as the latter allows to cope better.  Tackling the abatement
problem is what we need rechartering for.  Correct?

> their various forms, and is out of scope for this specification.

Careful:  I fully agree, assuming that "bad" is intended to mean the
various shades of gray that upper layer protocols such as reputation
systems will delineate.  However, when "bad" means the blatantly
illegal spamming committed by abusing others' domain names, that's
exactly what we want SPF (and DKIM) to deal with.

-- 
[see why]:  That sentence misinterprets the statistical skew due to
the fact that well-known domains are abused more often that others,
while false negative ratios are distributed irrespectively of domain's
behavior.  Processing based on that can be easily gamed.

For example, if I put a dot-forward to my new mailbox, paypal
transactions and my mate's postcards will fail alike.  The
distribution of false negatives is related to the ease with which
senders adopt my new address.  Banks and mailing lists require me to
take special action whereas (some) acquaintances and various kinds of
spammers may do it spontaneously.

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 08 Sep 2012 09:35:16 -0400

On Saturday, September 08, 2012 01:03:46 PM Alessandro Vesely wrote:
> >> true, there is definitely a differentiation of risk between the two. 
> >> For "bad" domains, authorized or not, the mail is likely to be "bad". 
> >> For "good" domains, not authorized mail is substantially more likely to
> >> be "bad" than authorized domains.
> 

I said more likely and you said it's not certain, so I don't see where the 
disagreement is?  I agree it's not certain.

> exactly what we want SPF (and DKIM) to deal with.

No.  They don't.  It is a fallacy to claim that SPF deals with the 
"good"/"bad" of anything at all.  It deals with authorized/not authorized.  
For well behaved ("good") domains that are spoofed there is a significant 
correlation between "bad" mail and not authorized mail, but don't let that 
lead you into thinking one directly relates to the other.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Sat, 08 Sep 2012 09:37:37 -0400

>   I think this gets into too much detail about internals of final

I believe maybe it was misread referring to the the final paragraph:

    Backends needs to take precautions of marking messages resulting
    from SPF -ALL failed transactions but were not rejected as
    prescribed in section 2.5.4.

There is a RFC2119 "prescription" for SMTP level rejection when 
Reject-On-Fail is the active protocol in action.  The the original 
issue #29, I believe, focused on defining the Marking behavior where 
there there was no "prescription" per se.  Since that didn't have 
traction, I had no choice but to restate it as a security issue (#33). 
Now we need some level of semantics, insights, etc, to help mitigate 
the potential risk differences between the two type of receiver 
protocol behavior.

> included in the document.

I personally do no recommend any REPUTATION talk involved with the 
-ALL policy.  Its 100% unrelated.  We risk going down the same path 
ADSP did with DKIM arguing uselessly the merits of strong exclusive 
mail authoring domain policies.

Besides, we can waste time argueing the above statement is not correct 
and/or depending on one's definition for "actor" or reputation 
modeling, SPF certainly does have the capacity of identifying good 
actors from bad ones.  That is the whole point of -ALL.

    if a mail sender uses our domain from none our our IP addresses, 
then its a
    BAD ACTOR, I am telling you he is a BAD GUY, please REJECT this 
transaction.

Thats a very strong deterministic capacity and falls under the ideas 
such as Query Dissemination methods. Its all part of process control 
and optimization theories. Its used in many ways, in many sciences and 
applications and conceptually, the faster your can filter your stream 
the better you can achieve, reach, zoom in on a higher quality in your 
result.  So I have written many times, I believe before you can even 
get a reputation consideration, you must filter all the deterministic 
junk first.

Anyway, we don't want to revisit the theory of SPF with reputation or 
worst leave it as such (with your text) that the SPF protocol is 
broken due to some subjective idea that reputation is required but 
unfortunately because its out of scope it can't be discussed and 
SPFBIS -ALL policies are now less optimal, non-effective for DOMAINS 
to use.  I don't think that would be correct.

My opinion is to set the facts straight.  Operations can use reject or 
mark per 2.5.4 and they need to take precautions to perhaps separate 
the SPF failed marked mail which would be otherwise rejected and thus 
never reaching the user under a different mode.

-- 
HLS

---

From: S Moonesamy <[email-masked]>
Date: Sat, 08 Sep 2012 10:38:14 -0700

Hi Hector,
At 06:37 08-09-2012, Hector Santos wrote:
>issue #29, I believe, focused on defining

With all due respect, I have to point out that there isn't any RFC 
2119 key words about that in RFC 4408.

>  the Marking behavior where there there was no "prescription" per 
> se.  Since that didn't have traction, I had no choice but to 
> restate it as a security issue (#33). Now we need some level of 
> semantics, insights, etc, to help mitigate the potential risk 
> differences between the two type of receiver protocol behavior.

I mentioned previously that I would be concerned if a security 
consideration is used to promote a particular behavior instead of 
addressing an attack.

Regards,
S. Moonesamy

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 8 Sep 2012 23:26:10 -0700

On Sat, Sep 8, 2012 at 4:03 AM, Alessandro Vesely <[email-masked]> wrote:
> stick to the more basic notion of _registered domain_.

That is far from a "basic notion", given it is impossible to determine
from the DNS.  If you're talking about tying SPF to WHOIS, that's
definitely not within scope here.

(Andrew has a draft he presented to APPSAWG about being able to
identify the registered domain from within the DNS, but it's far from
being a complete and deployed idea.)

> Dealing with "bad" registered

That part I agree with.

> sender's initiative after getting a bounce.  That's mark vs reject.

Whitelisting is a subset of reputation, and is a concept not in scope
for SPF (and please, let's not try to make it so).

> problem is what we need rechartering for.  Correct?

In a normative sense, I believe so.  In an informative sense, I
believe we are chartered to do that (as a "clarification"), although
we can't continue to pack things into the document under the guise of
clarifications when they have one foot in scope and one foot out.  We
need to resist that kind of bloat.

> exactly what we want SPF (and DKIM) to deal with.

Without the use of some kind of system that assigns value to names,
even as simple as a whitelist, how could one write software to detect
the kind of abuse your last sentence describes?

SPF and DKIM can't identify those cases alone.

This is a specific case of the more general problem, for which text
already exists in the document.  If we intend to call out every fail
reason and expound on it with examples and references to statistics,
we're never going to be finished.  We need to set some boundaries
here.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 09 Sep 2012 13:21:25 +0200

On Sat 08/Sep/2012 15:35:16 +0200 Scott Kitterman wrote:
>>>> For "good" domains, not authorized mail is substantially more
>>>> likely to be "bad" than authorized domains.
>> 
> I said more likely and you said it's not certain, so I don't see
> where the disagreement is?

In glimpsing some kind of cause-effect relationship with goodness.

> "good"/"bad" of anything at all.  It deals with authorized/not

I considered them synonyms, good ~= authorized, and bad ~= not
authorized.  Indeed, I was pointing out that the term "bad" is
ambiguous and we need to be careful :-/

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 09 Sep 2012 13:21:44 +0200

On Sun 09/Sep/2012 08:26:10 +0200 Murray S. Kucherawy wrote:
> from the DNS.

I assume you mean one cannot determine the associated ADMD.  Levels
are also fuzzy, e.g. paypal.com vs co.uk.  However, if you are able to
look it up on the DNS, it must belong to some registered domain,
unless the DNS server in use plays funny tricks.

In addition, everybody means the same thing when they talk about a
"registered domain".  Compared to terms like "good", "bad", and
"reputation", it is astoundingly well defined.

> If you're talking about tying SPF to WHOIS, that's definitely not
> within scope here.

Agreed.

> being a complete and deployed idea.)

Weirds is also promising.

> for SPF (and please, let's not try to make it so).

The point here is to characterize the difference between mark and
reject.  I agree that whitelisting is not the only means, but it is a
well known and widely used workaround.

> need to resist that kind of bloat.

Definitely.  Normative language forces a clear specification, while
the so-called clarifications, even if they are substantially correct,
tend to leave too much rope to different interpretations and gauging
of their applicability.  That way, they might well turn out to
actually obfuscate a point.

IMHO, without updating the charter, we cannot significantly better the
current state of affairs.

> the kind of abuse your last sentence describes?

Results from DNS imply a domain is registered.  Using them, software
can address the basic sense of "bad".  It can combine the results of
different identities, for example.

> SPF and DKIM can't identify those cases alone.

Modulo false negatives, they can.  DKIM would need a new, robust
canonicalization, and SPF a revised use of HELO identities.  Which
fruit is hanging lower?

>> For example, if I put a dot-forward to my new mailbox [...]
> 

IMHO, we need to consider fewer fail reasons, but more effectively.

The current spec suggests many possible behaviors to be operated by
both SMTP servers and clients.  It doesn't say who to blame for a
false negative, though.

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 09 Sep 2012 11:59:49 -0400

>In glimpsing some kind of cause-effect relationship with goodness.

This isn't about cause and effect, it's about statistics.

>ambiguous and we need to be careful :-/

They aren't entirely unrelated in some cases, but one does need to be careful as they are different concepts.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 9 Sep 2012 10:08:25 -0700

> "reputation", it is astoundingly well defined.

For humans, not for software.

> reject.

More than what's already in the document?  Really, I think we've
beaten this one to death.  We could define "mark" and "reject" in
Section 1 somewhere if it would make people happy, but really I don't
find that necessary.

> I agree that whitelisting is not the only means, but it is a

It's still a notion not in SPF's scope.  SPF itself doesn't (and
shouldn't) talk about how to decide what a good domain is.

> actually obfuscate a point.

OK, since you agree, then let's go one step further: All of the stuff
we're talking about here amounts to more clarification text that we
don't actually need.

> current state of affairs.

Hooray!

> different identities, for example.

Those exceed the scopes of the protocols themselves and extend into
the realm of either deployment guides or even applicability
statements.  They're bloat for the core protocols.

> canonicalization, and SPF a revised use of HELO identities.  Which

This isn't the right venue to discuss such a DKIM extension, though
you can suggest it on ietf-dkim if so inclined.  But (and I cringe
asking this) what are you suggesting with respect to HELO?

> both SMTP servers and clients.  It doesn't say who to blame for a

I think the use of "blame" here is a hornet's nest.  Explaining the
causes of "false" negatives (false for humans, not for the protocol)
is fine, but pointing fingers about what's "broken" will only get us
into trouble.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 09 Sep 2012 13:34:26 -0400

>On Sun, Sep 9, 2012 at 4:21 AM, Alessandro Vesely <[email-masked]>
....
>asking this) what are you suggesting with respect to HELO?
...

Let me suggest that whatever it is, there is a 100% chance it's out of our current scope so it should either be discussed elsewhere or here after the chartered work is done.  Here, at this time, it's a distraction.

Scott K