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 protected];
ruf=mailto:[email protected];
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
On 1/27/2015 11:36 AM, Hector Santos wrote:
On 1/25/2015 10:03 AM, Anne Bennett wrote:
Hector Santos <[email protected]>:
"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?
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.
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.
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
