Subject: [apps-discuss] An Authentication-Results method for white (and black) lists

From: Alessandro Vesely <[email-masked]>
Date: Thu, 01 Aug 2013 14:08:57 +0200

Comparing *dnswl*, http://www.dnswl.org/tech 

   Categories (127.0.X.y):

    2 - Financial services
    3 - Email Service Providers
    4 - Organisations (both for-profit [ie companies] and non-profit)
    5 - Service/network providers
    6 - Personal/private servers
    7 - Travel/leisure industry
    8 - Public sector/governments
    9 - Media and Tech companies
    10 - some special cases
    11 - Education, academic
    12 - Healthcare
    13 - Manufacturing/Industrial
    14 - Retail/Wholesale/Services
    15 - Email Marketing Providers 

   Trustworthiness / Score (127.0.x.Y):

    0 = none - only avoid outright blocking (eg Hotmail, Yahoo mailservers, -0.1)
    1 = low - reduce chance of false positives (-1.0)
    2 = medium - make sure to avoid false positives but allow override for clear cases (-10.0)
    3 = high - avoid override (-100.0). 

and *swl*, http://www.spamhauswhitelist.com/en/usage.html

   127.0.2.2 	IP sending individual mail
   127.0.2.3 	IP sending transactions
   127.0.2.102 	IP sending individual mail - Temporary Courtesy Listing (entry will expire)
   127.0.2.103 	IP sending transactions - Temporary Courtesy Listing (entry will expire)

I find the score is an actionable value, as it can be directly compared
with scores obtained by other means (spamassassin).  Interesting as the
other values are, I'm not clear on if/how they are used.  In order to
uniformize the result of a lookup, one would need a default value, e.g.
one could assign a score of 50 to the entries in the swl, as swl provides
no hint on how to compute one.

I posted an attempt in
http://tools.ietf.org/html/draft-vesely-authmethod-dnswl-01

Any suggestion on how to improve that?

Please note that version 00 of that thing simply provided for copying
any A and/or TXT records retrieved from a list, as if there were only
one list, whose encoding could then be assumed as the de-facto standard.
("TXT" still appears in a few places of version 01, erroneously.)

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 6 Aug 2013 12:08:09 -0700

> Any suggestion on how to improve that?
This is a good start.  Some comments to get you going:

General:

There are several places throughout the document where you refer to DNSWL
or DNSBL where I think it should be DNSxL, since the mechanism is the same
in both cases.

Section 1:

The comments about saving resources could refer instead to Appendix C in
RFC5451, which gives a pretty thorough treatment of that topic.

Section 2:

You should say up front that the authentication method you're registering
is called "dnsxl".

I don't know what an "outsourced extension" is.

I'm not sure about "policy.score".  Is it not enough to report pass/fail
according to the local policy parameters at the MTA where this is being
evaluated?  You could put score information in comments for debugging but
the point here is to have downstream agents (e.g., MUAs) be as simple as
possible.  The definition of "policy." in RFC5451 doesn't agree with this
usage either.

What you have as "policy.contact" should just use the existing "reason"
portion of the A-R field, or also be in a comment.

The result definitions are fine, except for "fail" you should have "IP
address" instead of just "IP".

Section 3:

Please don't reserve a name that you don't fully specify ("dnswl" in this
case).  It's also ambiguous to the one you're defining here ('dnsxl").

This is a good start, but I suggest you model the registrations after some
other document that already does this sort of work.  Section 5 of RFC6212
is probably a good basic reference.

Section 4:

You should copy the complete boilerplate from RFC6982 if you want to use it.

There's probably a lot more detail in here about Courier-MTA than we really
need to evaluate implementation.  I'm also not sure that describing use of
dnswl.org is relevant, since they don't implement this header field but
rather provide the DNSxL service that an MTA will query.

Section 5:

You might also want to refer to the Security Considerations of RFC5782.

Appendix A:

Your example doesn't appear to match your definitions.  In particular:

- dnswl should be dnsxl
- dns.zone should be policy.dnszone
- policy.ip is not defined
- policy.txt was discussed above

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 06 Aug 2013 16:30:15 -0400

>- policy.txt was discussed above

A dnsxl doesn't authenticate anything. Isn't something related to repute more appropriate? 

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 07 Aug 2013 16:20:31 +0200

On Tue 06/Aug/2013 22:30:15 +0200 Scott Kitterman wrote:
>> There are several places throughout the document where you refer
>> to DNSWL or DNSBL where I think it should be DNSxL, since the
>> mechanism is the same in both cases.

Albeit the mechanism is the same, the semantics is different.  The
description of pass and fail, for example, hinges on that.  Any
specific case where factoring would be worth?

>> Section 1:
>>
>> The comments about saving resources could refer instead to
>> Appendix C in RFC5451, which gives a pretty thorough treatment of
>> that topic.

Added a reference to Appendix D of I-D.ietf-appsawg-rfc5451bis.

>> Section 2:
>>
>> You should say up front that the authentication method you're 
>> registering is called "dnsxl".

Added in the abstract and at the end of the introduction.

>> I don't know what an "outsourced extension" is.

I'm not 100% clear on what a policy is.  Considering it an intrinsic
concept, I assume it can be extended, and its extensions can be
outsourced rather than brewed inhaus.

I split those sentences to:

   The receiving MTA needs to determine whether the data returned is
   applicable; that is, usable as an outsourced extension of its
   local policy.  In that case, it stores a uniformized version of
   the data in the apposite properties of the Authentication-Results
   header field.

Is that any better?

>> I'm not sure about "policy.score".  Is it not enough to report 
>> pass/fail according to the local policy parameters at the MTA
>> where this is being evaluated?  You could put score information
>> in comments for debugging but the point here is to have
>> downstream agents (e.g., MUAs) be as simple as possible.

If the score is going to be used by an automated tool --some SA-
equivalent filter that sums up all the scores and delivers the message
according to the result-- then it is more straightforward to parse a
property than a comment.

>> The definition of "policy." in RFC5451 doesn't agree with
>> this usage either.

Why not?

   A "ptype" value of "policy" indicates a policy decision about the
   message not specific to a property of the message that could be
   extracted.

The score is not extracted from the message, but imported according to
the local policy.

>> What you have as "policy.contact" should just use the existing
>> "reason" portion of the A-R field, or also be in a comment.

The policy.contact is designed to be used automatically:  In case the
recipient signals the message as spam, an MTA implementing RFC 6650
will send an ARF message to that contact.

>> The result definitions are fine, except for "fail" you should
>> have "IP address" instead of just "IP".

Done.

>> Section 3:
>>
>> Please don't reserve a name that you don't fully specify ("dnswl"
>> in this case).  It's also ambiguous to the one you're defining
>> here ('dnsxl").

I can add more information on "dnswl".  Since the I-D is
Informational, describing is not standardizing.  The point is if it is
possible to register that a "dnswl" method is used in the wild.

>> This is a good start, but I suggest you model the registrations
>> after some other document that already does this sort of work.
>> Section 5 of RFC6212 is probably a good basic reference.

Done.

>> You should copy the complete boilerplate from RFC6982 if you want

That sounds unpractical for readers, unless I structure the section
into subsections.

>> There's probably a lot more detail in here about Courier-MTA than
>> we really need to evaluate implementation.

Yes.

>> I'm also not sure that describing use of dnswl.org is relevant,
>> since they don't implement this header field but rather provide
>> the DNSxL service that an MTA will query.

It helps understanding the use case, though.

>> You might also want to refer to the Security Considerations of

Added.

>> - policy.txt was discussed above

Yes, I realized I hadn't changed it right after uploading version 01 :-(

I'll fix that before next upload.

> A dnsxl doesn't authenticate anything. Isn't something related to

I agree DNSBLs do not.  However, dnswl.org, for one, does.  It reports
the registered domain of the sender IP address, so that the receiver
learns the policy.contact.

In addition, it may make sense to register what the reputation value
was at the time a message was received.  I believe that practice will
come as soon as hands-on repute experience will have been gained.
DNSWLs have existed for years, and their usage seems to be mature
enough to allow for more methodical deployments.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 7 Aug 2013 11:23:50 -0700

> specific case where factoring would be worth?

The semantics are that being listed on a DNSWL means the message should be
allowed through while being listed on DNSBL means the message should not be
allowed through, and not being listed on either doesn't tell you anything.

You could register two methods, "dnswl" and "dnsbl" and thus encode the
meaning of a "pass" in the name itself.  You would have to update your
registrations and definitions accordingly.

>    the data in the apposite properties of the Authentication-Results

I still don't know what you mean by "outsourced".  Do you mean the
filtering agent is making a decision to trust a third party's opinion about
the trustworthiness of the source?

I also don't know what "uniformized" means; did you mean "canonical" or
"distilled"?

The use of "policy" as a ptype is meant to indicate that some kind of local
policy is superseding what would normally take place.  The specific example
I can remember is a DKIM signature that passes, but the Subject: field was
not included in what the signature covered, and local policy requires that
it is.  In that case you would generate something like "dkim=pass header.d=
example.com policy.dkim-unsigned=subject".  There, "dkim-unsigned" is the
name given to the local policy that checks to see whether a required set of
fields was covered by a DKIM signature, and the value indicates which
field(s) DKIM didn't cover.  Policy names are created locally, so they're
not specified in the RFC or registered with IANA.

> according to the result-- then it is more straightforward to parse a

OK, but unfortunately "policy" is not the mechanism to do that.  Really,
putting acceptance decisions in the hands of downstream filters or MUAs is
kind of against the whole model that A-R attempts to provide.  Instead, the
handling thresholds should be encoded in the method result.  Maybe you want
something more granular in your result codes than just "pass" and "fail"?

> >> The definition of "policy." in RFC5451 doesn't agree with

See above.

> will send an ARF message to that contact.

An MTA doing so already has this information.  It doesn't need to relay it
to downstream filters or MUAs.  Or are you talking about MUAs implementing
RFC6650 themselves?

> possible to register that a "dnswl" method is used in the wild.

Yes, but if this gets published, an IANA registry entry created will point
to this document, which (at present) says nothing about "dnswl".  If you
really want to reserve that name, you should consider registering "dnsbl"
and "dnswl", and not "dnsxl".

> That sounds unpractical for readers, unless I structure the section

RFC6982 sections are deleted before publication.  They're only meaningful
during evaluation of the document.

> learns the policy.contact.

That's a database lookup, not authentication work.

However, to Scott's point, VBR is not itself an authentication method
either, but it has A-R entries.  That drew no objections at the time, but
that could've been an oversight.

> enough to allow for more methodical deployments.

All true, except that providing the details of the evaluation to downstream
agents is not what A-R is for.  The ultimate goal is to indicate to MUAs
that this message did or did not pass a particular set of tests, and these
are the message properties that are worth highlighting in some way.  For a
DNSXL, that model doesn't indicating anything about a scalar reputation.
You could restrict "pass" to mean "listed and above a certain score" if you
like, but that's not something that's meant (in this model) to be exposed
to MUAs.  It passed your test, or it did not.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 08 Aug 2013 13:06:45 +0200

> the trustworthiness of the source?

Yes.  It is the receiving ADMD, rather than the filter, who makes the
decision of acquiring the policy extension from an external supplier.

> I also don't know what "uniformized" means; did you mean "canonical" or

Canonical, or homogeneous.

> policy is superseding what would normally take place.

If that is meant to be normative, it ought to be specified better (in
5451-ter?)  W.r.t. the example quoted below, the evaluation of a DKIM
signature, rather than an IP address, is affected by a local policy.  It
is not obvious why would policy.dkim-unsigned be valid given that
policy.score is not.

> The specific example I can remember is a DKIM signature that passes,
> but the Subject: field was not included in what the signature
> covered, and local policy requires that it is.  In that case you
> would generate something like "dkim=pass header.d= example.com
> policy.dkim-unsigned=subject".  There, "dkim-unsigned" is the name
> given to the local policy that checks to see whether a required set
> of fields was covered by a DKIM signature, and the value indicates
> which field(s) DKIM didn't cover.  Policy names are created locally,
> so they're not specified in the RFC or registered with IANA.

Registration of "dnswl" and "dnsxl" can get much simpler if some names
can be omitted, e.g. because they are created locally.  But how should
parsing software behave in such cases?  I thought that the example given
near the end of Section 2.2 referred to some yet unspecified method,
since no method registered a "policy" ptype.  (I see now that there is a
"policy.iprev" property at IANA's.  Where does it come from?)

>>> I'm not sure about "policy.score".
>>
>> [It might be used by] an automated tool --some SA- equivalent
>> filter that sums up all the scores and delivers the message 
>> according to the result.
> 
> kind of against the whole model that A-R attempts to provide.

Eh?  I must have misunderstood much of 5451-bis:

   The intent of the header field is to create a place to collect such
   data when message authentication mechanisms are in use so that a
   Mail User Agent (MUA) and downstream filters can make filtering
   decisions [...]

What is the difference between acceptance decisions and filtering decisions?

> Instead, the handling thresholds should be encoded in the method
> result.

That doesn't allow a final decision to be made by weighting
contributions from many upstream filters.

> Maybe you want something more granular in your result codes than just
> "pass" and "fail"?

I'm not (yet) using the score, so I can follow the consensus on this issue.

> to downstream filters or MUAs.  Or are you talking about MUAs implementing

No, the MUA just signals the message, possibly by moving it in a "Spam"
folder.  At this point, the server formats the message according to ARF
and sends it to policy.contact.  In the current implementation, the
contact is already in a database at that point.  However, it made it
into the database after parsing the "policy.txt" property of the
existing "dnswl" method.

If "policy.txt" can stay non-registered, like locally created names,
I'd be happy to revert to version 00 "dnswl".  It looks much simpler
than standardizing the score.  Would it be possible to update 5451-bis
so as to add "dns"?

> and "dnswl", and not "dnsxl".

For "dnsbl", Scott's objection is valid.  See below.

> RFC6982 sections are deleted before publication.  They're only
> meaningful during evaluation of the document.

Yes, but I slightly stretched the spirit of RFC 6982 trying to better
recount the use case.  Readability would be at stake if distinguishing
boilerplate from other notes became difficult.

>>> [Scott:] A dnsxl doesn't authenticate anything. Isn't something
>>> related to repute more appropriate?
>>

The former is a means to achieve the latter.

> that could've been an oversight.

Hm...  Establishing the identity of an actor is not really different
from authenticating:  The tokens that we authenticate, names or IP
numbers, are strongly related to the identity of the actor who bears
them.  And an identity is the collection of multiple traits and
properties that make an actor recognizable and possibly trustworthy.

In that sense, both SWL (VBR) and dnswl.org (this) are means to
authenticate a sender.

> are the message properties that are worth highlighting in some way.

MUAs are a difficult target for A-R, unless they are aware of the
internal processing details of the unique ADMD that they fetch messages
from.  In the latter case, they can be considered internal filters,
albeit interactive.

My understanding of A-R, until now, is that it is a convenient means to
pass authentication results to downstream filters.  An omnibus.  What am
I missing?

> For a DNSXL, that model doesn't indicate anything about a scalar
> reputation. You could restrict "pass" to mean "listed and above a
> certain score" if you like, but that's not something that's meant (in
> this model) to be exposed to MUAs.  It passed your test, or it did
> not.

Well, some more granularity might be useful in some cases.  The
granularity offered by dnswl.org encoding is nowhere near the continuity
of a real scalar, though.  I agree that real values belong rather to
fuzzy evaluations, such as Bayesian statistics.  IMHO, those fuzzy
filters ought to run under the direct control of recipients, not on a
server.  Yet, it might be useful for A-R to inter-operate with those
processes.  Dunno.