Subject: [dmarc-ietf] the painful issue of SPF HELO

From: Anne Bennett <[email-masked]>
Date: Fri, 23 Jan 2015 18:27:46 -0500

I seem to have wandered into a bit of a minefield.  :-/

Obviously I like Murray's proposed changes, since they're
based on mine :-), but I see that he has added "typically"
in a couple of places... and I begin to understand why it's
necessary to waffle somewhat.

** What is interoperability in this context? **

Interestingly, Murray explains that changes "will be limited to
correcting serious problems that would prevent current DMARC
implementations from interacting properly".  If I may be a
bit pedantic for a moment, it doesn't look as though DMARC
implementations interact (with each other) at all.  Rather,
as mail receivers, they "interact" with values published in
the DNS by mail senders.

In that light, one could argue that a problem which prevents
a sending domain from predicting what "pass/fail/none" result
a DMARC-compliant receiver will assign to its messages, is a
problem which "prevents proper interaction".

Unfortunately, since this effort is one to document what's out
there now, and since (it's slowly becoming clear to me) not
all DMARC implementations produce the same evaluation results,
it's impossible to define the DMARC mechanism unambiguously.
Murray would like the "goal posts [to] sit still for a while",
but I think the goal posts are behaving more like waves than
like particles!

** A technical problem: how many results from SPF? **

[SPF] defines a test which is recommended to be applied to
two separate identifiers (HELO and MAIL FROM), where the receiver
can consider the results of each test independently.  (However,
I can publish only one SPF record for a name - that is, I cannot
say "my policy is *this* if the name is used for HELO, but my
policy is *that* if it is used in MAIL FROM".  But that's not a
topic for this list.)

Along comes DMARC, which expects to receive *one* result from
"the SPF test", but there are *two* possible SPF tests.  Scott
takes the position that this doesn't much matter, and for all
I know he may be right in practice, but from the point of view
of the poor sod trying to figure out what will happen when she
publishes SPF and DMARC records, it sure makes life difficult.

I doubt we're going to be able to do much better than the
proposed "-13" (or something very similar) with respect to HELO,
but at least it raises the issue instead of leaving people like
me perplexed, and it admits that there's more than one way a
DMARC implementation could choose to use (or ignore!) the two
SPF results.

** A "political" issue: how is receiver policy determined? **

Scott points out, with respect to the SPF RFCs, that the results
of each SPF check are unambiguous, that "The almost complete
lack of receiver policy specification in RFC 4408 (and RFC 7208)
is not an oversight.  It was a deliberate design choice", and
that "[Franck's] mistake [is] to insist that there be one and
only one defined way to deal with SPF results from both HELO
and Mail From and there isn't".

All of this is fair enough and true, but some of it is
tautological: the receiver can do as it pleases, and no one can
stuff an unwanted e-mail message down someone else's throat.
I suspect I can choose to refuse all mail on Tuesdays if I want
to, so certainly I can do whatever I wish with SPF results.

I think that discussion about who determines the receiver's
policy misses the point.  The current draft even states that
"Final disposition of a message is always a matter of local
policy".

The point, IMHO, is that when I publish DMARC and SPF and
DKIM records, I should be able to reliably predict whether
a given message will result in a DMARC pass, fail, or none,
quite regardless of what the receiver will choose to do based
on that result.

It looks as though that won't happen in this go-round, no
matter what.  :-(

** 4408 vs 7208 - does it matter? **

Hector points out that SPF implementations using the "obsoleted"
RFC 4408 will be around for some time, and expresses
the concern (if I understand him correctly) that if DMARC
references the newer 7208, there may be an implication that the
5322.Authentication-Result header will be expected to be present
so DMARC can "consume" it.  But there's no mention of the use
of these headers in the current draft (except, in passing,
"Original-Authentication-Results").  The draft mentions using
the *results* of the SPF and DKIM tests, but not how they are
obtained, and I think that may be the right approach.

Or, Hector, are you concerned that DMARC implementations
will be expected to *provide* one or both those headers,
and if so, that this should be explicitly stated?

** The word "contradiction" **

Murray proposed this text for 4.1, based on my suggestion:

  [SPF], which authenticates the domain found in an [SMTP]
  MAIL command, or the domain found in the HELO/EHLO command if
  the MAIL command has a null path. Note that in contradiction
  to [SPF], in the context of DMARC, this latter identity is
  typically only used in the case of a MAIL null path.

Franck objects to the word "contradiction", and suggests:

  [SPF], which authenticates the HELO identity and the MAIL
  FROM identity: the domain found in an [SMTP] MAIL command,
  or the domain found in the HELO/EHLO command if the MAIL
  command has a null path. Note that in the context of DMARC,
  this later identity is only used.

Hmm.  How about this:

  [SPF], which authenticates:
    - the domain found in an [SMTP] HELO or EHLO command
      (the "HELO result"), and/or
    - the domain found in an [SMTP] MAIL command, or the domain
      found in the HELO/EHLO command if the MAIL command has a
      null path (the "MAIL FROM" result).
  It is not specified whether DMARC uses the "HELO result"
  or the "MAIL FROM result"; implementations differ.

It certainly exposes the ugly truth.  ;-)

But speaking of ugly truths, the document already allows for
differences; in section 6.7 we have:

-12>  DMARC-compliant Mail Receivers typically disregard any mail handling
-12>  directive discovered as part of an authentication mechanism (e.g.,
-12>  ADSP, SPF) where a DMARC record is also discovered that specifies a
-12>  policy other than "none".  Deviating from this practice introduces
-12>  inconsistency among DMARC operators in terms of handling of the
-12>  message.  However, such deviation is not proscribed.

** A tiny rant **

Necessary as this flexibility is if this document is to be
finished any time soon, it causes problems for a person trying
to create SPF and DMARC records in a way that will not cause
more problems than it solves!  While it's tempting to stay away
from this stuff until it all settles down, that's becoming more
difficult, and not only because my parent domain at work might
be poised to publish a DMARC record which could interfere with
my domain's outgoing mail.  Even at home, a few months ago,
Gmail started tagging my outgoing mail as spam, and when I
tried to troubleshoot this, their "why is this spam" web page
essentially insisted that I publish an SPF record before going
any further!
(end of rant)

It's only fair to admit that despite my frustration, I'm
grateful for all the work being done on these issues, both to
combat spam, and to document what on earth is going on.

Anne.
-- 
Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8
[email-masked]                                    +1 514 848-2424 x2285

---

From: Franck Martin <[email-masked]>
Date: Fri, 23 Jan 2015 18:14:12 -0600 (CST)

----- Original Message -----
> From: "Anne Bennett" <[email-masked]>
> To: [email-masked]
> Sent: Friday, January 23, 2015 3:27:46 PM
> Subject: [dmarc-ietf] the painful issue of SPF HELO
> 
> 

>   or the "MAIL FROM result"; implementations differ.
Your text is clearer but replace the last sentence by:
DMARC uses the MAIL FROM result.

If you look Terri's, my implementation, which is used at least by another large ISP, and Tim's conformance tests, that were used for much code out there. Then I can say DMARC uses the MAIL from result today. I cannot speak for everyone, but this is what I feel is true out there.

I have not seen any evidence that DMARC uses the HELO result, so your implementation differ is conjecture.

> -12>  message.  However, such deviation is not proscribed.

This was mainly added in the case of people that follow -all to the letter and reject emails on sight.

> combat spam, and to document what on earth is going on.

I think once you get aggregate reports, all these questions won't matter much... 

Seriously, if you DKIM sign your email with an aligned domain, then it will give you a DMARC pass, SPF will be here for the <0.5% of cases where DKIM fails for not apparent reason (provided you can DKIM sign your bounces, which many people can but forget to do).

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 23 Jan 2015 19:17:57 -0500

> policy is *that* if it is used in MAIL FROM".  But that's not a

FWIW, in a decade of doing SPF work I've yet to run into a case where this was 
a real life problem.

> It looks as though that won't happen in this go-round, no

You may not be able to get to 100%, but you can get very close.

> obtained, and I think that may be the right approach.

RFC 7208 didn't replace Received SPF, it just added reference to the A-R 
header field as an option.  Since that was already documented in other RFCs, 
that didn't change anything.  

How authentication information is communicated to different parts of an 
entity's mail system is a local choice without a global interoperability 
impact.  One way to do it is by adding either a Received SPF or A-R field to a 
message for consumption by a downstream process.  There are others.  In the 
case of SPF Received versus A-R, all that matters is that the SPF verifier 
includes the one that the downstream processor can use.

Adding A-R to RFC 7208 changed nothing.  Not trying to specify internal mail 
system design details (which is what the current DMARC draft does) is the 
correct approach.

> and if so, that this should be explicitly stated?

It would be SPF implementations.  A DMARC verifier might need to be prepared to 
consume both data formats (as opendmarc does), but that's really not very 
hard.  It's also unrelated to RFC 4408 versus RFC 7208 because even if RFC 
4408 had never been updated, there were standards track RC defining how to use 
A-R to report SPF results.

>   this later identity is only used.

This is close.  It's really only the SPF Mail From result that's used.  The 
trick is that in the case of a null Mail From, that result is calculated using 
a synthetic Mail From built using the HELO domain.

> It certainly exposes the ugly truth.  ;-)

I think this is good too, but we can simplify it, I think.

> combat spam, and to document what on earth is going on.

I appreciate you sticking with it.  It's good to get in depth review from new 
sets of eyes.  I certainly was sure I was sure I knew what the discussion 
about SPF meant, but then I already knew what was intended, so it's good to 
have someone else reviewing.

How about this:

   [SPF] can authenticate both the domain found in an [SMTP] HELO/EHLO
   command (the HELO identity) and the domain found in an [SMTP] MAIL
   command (the MAIL FROM identity).  DMARC uses the result of SPF
   authentication of the MAIL FROM identity.  Section 2.4 of [SPF] describes
   SPF MAIL FROM processing for cases in which the MAIL command has a
   null path.

Scott K

---

From: Franck Martin <[email-masked]>
Date: Fri, 23 Jan 2015 18:23:54 -0600 (CST)

----- Original Message -----
> From: "Scott Kitterman" <[email-masked]>
> To: [email-masked]
> Sent: Friday, January 23, 2015 4:17:57 PM
> Subject: Re: [dmarc-ietf] the painful issue of SPF HELO
> 

> have someone else reviewing.

+1

>    SPF MAIL FROM processing for cases in which the MAIL command has a

+1

Ship it!

---

From: Kurt Andersen <[email-masked]>
Date: Fri, 23 Jan 2015 17:05:51 -0800

> >    SPF MAIL FROM processing for cases in which the MAIL command has a

+1 also :-)

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 23 Jan 2015 17:29:02 -0800

> as mail receivers, they "interact" with values published in

Right.  The statement is a very general one about making edits this late in
a protocol document's life cycle, not something specific to how DMARC works.

> problem which "prevents proper interaction".

I think that's impossible to resolve completely because, for a given
receiver, there's no guarantee that you'll be told your message was
rejected specifically because of DMARC policy.  Some operators specifically
choose never to reveal which test you failed so that you don't have any
specific information about how to get through their filters.  (See Section
5 of RFC7372.)  Thus, you may never know what result a DMARC-compliant
receiver assigns to your messages since there are other factors that can
come into play before your message gets rejected.

> but I think the goal posts are behaving more like waves than

You're not talking about the same goal posts I am.  The DMARC document has
been alive for no less than three years, and we've had one last call after
another for making changes or finding defects.  The changes get made,
everyone says we're ready, we make some progress, and then some other big
change gets proposed.  I believe we've reached a point of diminishing
returns for this version of the document, imperfect as it might still be,
in terms of holding it for one more edit and one more edit.

Despite issues like the one you've raised that might still be in there,
there's also abundant evidence that it is useful to some operators in its
current form.  That might be because they've all assumed, agreed, etc.,
that the HELO value is not used, and just forgot to write that down.  Or it
might be coincidence that many (but not all) implemented it that way since
the goal is to match as well as possible against what's in the From: field.

For reasons not worth getting into now, this version of the base
specification is on track to be published not as a standard but as an
"Informational" document, kind of as a handoff step between the team that
first developed DMARC and the IETF, which is more rigorous in terms of
developing standards.  The goal posts to which I'm referring are the
completion of that handoff.  We need to publish DMARC in its current state,
even if it's not full-standard quality yet, to do so.  If we reset that
process every time a defect is identified, we might not be done for a
really long time.

DMARC will not be final when this version is published.  If it's broken, I
agree it should be fixed, and we have a process for that.  This iteration
of the document, though, shouldn't be held indefinitely.  So how long is
long enough?  We need to draw a line someplace, and hand off what's left to
the working group for a proper standardization effort.

I've already opened a ticket in the working group's tracker identifying
this issue so the working group can decide if and how it wants to handle
this matter.

> quite regardless of what the receiver will choose to do based

But how can you tell?

I'm not trying to deflect your question -- I know you want at least the
DMARC part to be deterministic, which isn't an unreasonable request -- but
there's really no way to determine whether a particular receiver is
applying bare DMARC or is applying local stuff on top of it.  So if
receiver behaviour is unreliable in the first place, how can one reasonably
claim that this is clearly a defect in DMARC?  DMARC's not introducing that
uncertainty; clearly the issue you're talking about certainly isn't helping
it either, but it's not as if resolving that here will suddenly make
receiver handling of email deterministic.

> obtained, and I think that may be the right approach.

There is no prescription of how SPF or DKIM results are communicated to the
DMARC agent.  Authentication-Results (RFC7001) is one way, but it's not the
only way.  There are DMARC implementations (mine, for example), that use
that header field to signal results between modules attached to the MTA,
but there are commercial implementations where that information is passed
across API calls within the same process.  It doesn't matter, really, so
DMARC doesn't specify.  So I claim "will be expected" is false.  Moreover,
Authentication-Results does support returning two SPF results, and
disambiguating them.

On the other hand, RFC7001 is the suggested way to report DMARC results to
whatever wants to consume them, though again that's not mandatory.

Personally, I fall on the "doesn't matter" side because I don't believe
this is a change in behaviour between the two versions of the SPF
specification.  Both of them say checking HELO is RECOMMENDED, leaving it
to the careful discretion of the receiver.  We'd therefore have to have a
rather good reason for making a normative reference in DMARC to an obsolete
document.

>   or the "MAIL FROM result"; implementations differ.

I would leave off "implementations differ", but that's fine with me if it's
fine with others.  It's probably more accurate.

> -12>  message.  However, such deviation is not proscribed.

This is there for two reasons:

a) because (as you've acknowledged) we can't force the receiver to do
anything; and
b) because if SPF rejects the message by enforcing "-all" after MAIL FROM,
there's no chance for DKIM to report a "pass", which could satisfy the
DMARC test.

-MSK

---

From: Anne Bennett <[email-masked]>
Date: Fri, 23 Jan 2015 22:22:40 -0500

Franck Martin <[email-masked]> responds to my suggestion

> If you look Terri's, my implementation, which is used at
> least by another large ISP, and Tim's conformance tests,
> that were used for much code out there. Then I can say DMARC
> uses the MAIL from result today. I cannot speak for everyone,
> but this is what I feel is true out there.
> 
> I have not seen any evidence that DMARC uses the HELO result,
> so your implementation differ is conjecture.

Not quite conjecture; it's based on Murray writing, a few days ago:

MK> I can say that OpenDMARC consumes the Authentication-Results
MK> field, or the Received-SPF field if the former isn't there,
MK> but it prefers a result based on MAIL FROM over one based on
MK> HELO if both are present.  But it will use both.

Perhaps I misunderstood him?

I certainly have no objection to Scott's text, which he proposed
in another message, assuming it is correct, which I certainly
don't feel qualified to comment on.  My efforts have been aimed
at making things clear - whether they are correct has to be
someone else's call!  ;-)

Anne.

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sat, 24 Jan 2015 17:35:53 +0900

Anne Bennett writes:

 > finished any time soon,

That's not why the flexibility is there, though.  The point of the
flexibility is that *this* RFC is being published to document what is
already "out there", based on the original non-IETF spec.  Clarifying
ambiguity only helps if we're pretty sure that in fact there aren't
any implementations based on an alternative interpretation.  If we're
not sure enough, we're exposing you to additional risk.

This is not to say that your technical points aren't well-taken.  But
the sooner we put *this one* to bed, the sooner we can get to work on
a normative RFC, and *picking* interpretations of existing ambiguity
that make it easier to configure the mail system and still enable
filtering of malicious mail.  Maybe even fixing unambiguous problems
in the current spec (although propagating changes to deliberately
chosen specifications to implementations is always a difficult task).

 > it causes problems for a person trying to create SPF and DMARC
 > records in a way that will not cause more problems than it solves!

No, since this RFC is informational, it simply fails to help where it
is ambiguous.  Any actual problems already exist "out there" -- and
there probably aren't going to be a lot of new ones because the DMARC
consortium claims that 80% of mail is already protected by DMARC.

If you stay away from SPF "-all" and use DMARC "p=none", I don't see
that there's much risk.

Steve

---

From: Hector Santos <[email-masked]>
Date: Sat, 24 Jan 2015 19:05:54 -0500

> and if so, that this should be explicitly stated?

Being Specific is Terrific.

Note -12 rev has no mentioning of Received-SPF.  Also note, during 
SPFBIS there was an attempt (Issue #10) to deprecate Received-SPF 
which was shot down. Murray was concern of having two mechanisms here. 
  Of course, he was also the author of the Authentication-Result header.

Anyway, it depends on the type implementations and there are many 
kinds.  If you starting fresh, you have the luxury to do whatever you 
want.  For others, its can be an expensive change endeavor and for 
some (like me), they will wait until its all settled.   It can also 
possibly be done via private meta-data when the 5322 payload is saved 
for mail processing during DATA.

In all, we are talking about an integrated framework of a total 
possible four or even seven components and the possible variations:

    SMTP
    SPF, SUBMITTER
    DKIM
    ADSP, ATPS
    DMARC

If you are adding DMARC to an existing framework, it needs to decide 
what it needs to use.  DMARC is classified in DMARC as a "Super-ADSP." 
See appendix A.5. Is this deprecated too?

IMO, if its not the developer of the SPF component, the better DMARC 
implementation should expect 4408 operations.  There are new designs 
and plug and play considerations here. There is also new SMTP change 
requirements too.  This DMARC doc needs to be clear in the migration 
path.

I believe you are concern about the HELO mostly. Historically, it was 
an unreliable check. Very high overhead with little payoff.  The 
default is NO CHECKING, but I will recognize this is changing and 
overall DNS lookup waste more feasible to handle across the board.

But in general, I always felt that would be a boolean TRUR or FALSE 
output as a function of SPF and for implementations of all the SPF and 
related protocols, like SENDER-ID, it included RFC4405 (SUBMITTER) 
field as well as input to the CheckHost() function

      SPF.Result = CheckHost(HELO, MAIL.FROM, MAIL.SUBMITTER)

despite Scott's adamant refusal to not recognize the existence and its 
impact (SPFBIS issue #11). There are ESMTP clients do send the 
SUBMITTER field in MAIL FROM for SPF processing.

Unless it can be very clear about it, how is is done, the order, etc, 
is generally out of scope for IETF protocols.  What is important is 
that the end result is mostly the same.

IMO, DMARC is problematic when it looks for an alignment concept 
because an -ALL at SMTP can preempt a DMARC process altogether, i.e. 
the DATA payload will not be received/transferred.  But DMARC also has 
semantics for DELAYING SPF processing until the PAYLOAD is received. 
IMO, that encourages waste, however, getting the REPORTING 
requirements seems to be also important for many, still.   Keep in 
mind this redundancy will turn into waste, so even processing delay 
options are provided, implementation needs should allow it to be 
optimized (turned off).

Thats all optional implementation design decisions.  I steer towards 
optimized and scaled designs so the only data received for DMARC 
processing would be transactions with:

      SPF.Result = NONE|SOFTFAIL|NEUTRAL|PASS

In our implementation, DMARC will never see a -ALL failure since its 
immediately rejected before DATA.  So the alignment can alter the 
DMARC result, not the SPF result.

If you think SMTP should have information about the DMARC policy 
before DATA is reached, then we don't that ESMTP (Extended SMTP) idea 
officially proposed yet.

Keep in mind, there was once a proposal on the table called CSV/DNA 
that did allow for Reputation, Authentication and Authorization 
Policies at the EHLO level.

Many DNS-based Email Policy applications have been proposed and 
explored at various levels. DMARC is the latest one and its DOMAIN 
anchor is the Author Domain.  That piece of data is not at SMTP until 
DATA is received.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Sat, 24 Jan 2015 20:01:17 -0500

On 1/23/2015 8:29 PM, Murray S. Kucherawy wrote:

> "Informational" document, kind of as a handoff step between the team
> that first developed DMARC and the IETF, which is more rigorous in
> terms of developing standards.  The goal posts to which I'm referring
> are the completion of that handoff.  We need to publish DMARC in its
> current state, even if it's not full-standard quality yet, to do so.
> If we reset that process every time a defect is identified, we might
> not be done for a really long time.

The probably you face is new implementations of this "info" version 
which to them is a "pseudo" standard track item.

I think you got most of whats needed.  But I would add more info as a 
"Get Ready" guide to minimize changes in the future.

  [1] Get ready for 3rd Party Extensions
  [2] Make sure DMARC processors DO NOT BARF on unknown #1 tags.
  [3] Forget about ADSP, remove A.5
  [4] Independent DMARC modules need to be aware of independent SPF 
4408 only modules

> DMARC will not be final when this version is published.  If it's
> broken, I agree it should be fixed, and we have a process for that.

Too long and costly and that fact we have to wait for you, its has a 
major delay and cost impact now, i.e. no rush to do anything now, list 
systems and list users have to wait for solutions (until you are are 
ready to work with it).  Seriously, the IETF AD needs to be aware of 
the man power issue.  There is no reason why can't have parallel 3rd 
party Policy Design teams working.  There are interested parties to 
help here.  There is no reason why ATPS can't be updated for
DMARC to get early explorers started.  Remember, before, the interest 
was not there with ADSP.  But now you have it with DMARC. Much 
different situation now.

Good luck

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Sat, 24 Jan 2015 21:03:51 -0500

On 1/23/2015 8:05 PM, Kurt Andersen wrote:

>Scott proposed:
>> Frank voted:

Slow down. :)

I don't get that second sentence:

   "DMARC uses the result of SPF authentication of the MAIL FROM 
identity."

Does that mean it gets return-path from the "Authentication-Result:" 
header? or the "Return-Path:", "Sender:" headers?  or is about what 
SPF should report?

I believe, it sounds to me, that it should be:

   [SPF] can authenticate both the domain found in an [SMTP] HELO/EHLO
   command (the HELO identity) and the domain found in an [SMTP] MAIL
   command (the MAIL FROM identity). Section 2.4 of [SPF] describes
   SPF MAIL FROM processing for cases in which the return path is null,
   for example MAIL FROM:<>.

   For DMARC domain alignment policies, DMARC uses the return path 
(MAIL FROM)
   of the transaction for alignment with the author domain, see 
Section 3.1.

Its really two separate ideas imo.

-- 
HLS

---

From: Anne Bennett <[email-masked]>
Date: Sun, 25 Jan 2015 10:03:56 -0500

Hector Santos <[email-masked]>:

> header? or the "Return-Path:", "Sender:" headers? 

It doesn't say how it gets the results, which IMHO is
appropriate, since this is implementation dependent - who are
we to say how the components of an e-mail filtering system
should communicate with each other internally?

> or is about what SPF should report?

I definitely would not read the above sentence that way; I
raised this because I was trying to understand your objection
with respect to the headers.

Anne.

---

From: Hector Santos <[email-masked]>
Date: Tue, 27 Jan 2015 11:36:10 -0500

> with respect to the headers.

I don't have a objection.  The two headers are needed for maximum 
upward and backward compatibility support.  I was just making a note 
that it is highly possible that a 4408 module may only exist for the 
new dmarc module to work with. It will only see Received-SPF, 
otherwise it is custom-made to support internal I/O meta-data or its 
responsible for updating the 4408 module to possible do it all with 
Auth-Res.   In other words, a DMARC developer needs to be aware of 
possible scenarios.  It can not assume AUTH-RES is guaranteed to have 
all the SPF information.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Wed, 28 Jan 2015 12:33:56 -0500

In all honesty, I have fallen behind on Murray's work with Auth-Res. A 
number of years back, I know that it wasn't quite ready for full ADSP 
(reporting/tracing) support  and I had slightly deviated from what he 
was pushing/registering. I didn't feel it covered all the information 
what a ADSP plus ATPS downlink consumer would need for support or for 
a MFA (Mail Filtering Agent).  For example, this what I have so far 
with Auth-Res for the message I posted. I just added DMARC processing 
(without the rejection/quarantine switch):

Authentication-Results: dkim.winserver.com;
  dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;
  adsp=pass policy=all author.d=isdg.net asl.d=ietf.org;
  dmarc=pass author.d=isdg.net signer.d=ietf.org (atps signer);
  dkim=fail (DKIM_SIGNATURE_BAD) header.d=isdg.net header.s=tms1 
header.i=isdg.net;
  adsp=pass author.d=isdg.net signer.d=isdg.net (originating signer);
  dmarc=pass author.d=isdg.net signer.d=isdg.net (originating signer);
  dkim=fail (DKIM_SIGNATURE_BAD) header.d=beta.winserver.com 
header.s=tms1 header.i=beta.winserver.com;
  adsp=fail author.d=isdg.net signer.d=beta.winserver.com 
(unauthorized signer);
  dmarc=fail author.d=isdg.net signer.d=beta.winserver.com 
(unauthorized signer);

Try to make sense out of that!!!  We have no SPF AUTH-RES reporting 
yet! I should note that our mail system was one of the first few, if 
only one, that supported DKIM+ADSP+ATPS and the current effort and 
desire is to basically replace ADSP with its "Super-ADSP" DMARC but 
also with ATPS support (see section 3.1.3):

    3.1.3.  Alignment and Extension Technologies

    If in the future DMARC is extended to include the use of other
    authentication mechanisms, the extensions will need to allow for
    domain identifier extraction so that alignment with the RFC5322.From
    domain can be verified.

We have wizards for the ADSP setup and now with DMARC:

  DKIM ADSP Policy Wizard http://www.winserver.com/public/wcadsp
  DKIM DKIM Policy Wizard http://www.winserver.com/public/wcdmarc

In the above real Auth-Res header example, the top AUTH-RES results 
pass because of the 3rd party ATPS authorization for the IETF.ORG 
domain published in our DMARC extended records for 3rd party 
authorization:

    v=DMARC1; p=none; atps=y; rua=mailto:[email-masked]; 
ruf=mailto:[email-masked];

The atps=y tag tells a DMARC+ATPS compliant receiver to check for the 
unaligned signer (d=ietf.org)
domain authorization.   The lookup follows this ATPS algorithm for a 
DNS A record:

    base32(sha1({SIGNER-DOMAIN}))._atps.{AUTHOR-DOMAIN}

So the solution has been known. The question is one of feasibility and 
scalability.  I believe it is for the MAJORITY of domains and even for 
the big guys, it isn't going to break their back.

Anyway, not trying to change the topic regarding 3rd party policies, 
but to point out this is a very complex integrated solution.  Canned 
or total package solutions have an advantage since they see how things 
all fit.  We have to make it work generically for an automated 
protocol framework (the MUSTs features) and with extracted options for 
administrators to play with (the SHOULDs, MAYs features).

PS: To Murray, you might find it useful that I have not seen any DMARC 
parser barfing on the unknown tag "atps=y" which is good and tells us 
we are very ready for a DMARC extensions market.

Bye

--
HLS