On 05/13/2016 05:24 AM, Murray S. Kucherawy wrote:
On Wed, May 11, 2016 at 7:19 PM, Roland Turner
<[email protected] <mailto:[email protected]>> wrote:
I'd suggest not. AS[1] permits a receiver (or other assessor) to
determine with some confidence that the putative signer made such
an assertion about the putative originator, it provides no
information about the involvement of the putative originator
except to the extent that the assessor additionally trusts the
assertions of the putative signer. Decisions to trust are
necessarily outside the specification. This argument applies
equivalently to AS[0] independent origination scenarios and to
AS[>0] forwarding scenarios.
What would an i=0 ARC Set tell you that the i=1 set does not?
As I understand it, an i=0 set would be the author asserting "I
validated my own mail, and it was good." How would one consume such
an assertion in a meaningful way?
(Note that during writing the following, my stance has changed. I'd now
recommend the registration of a new 7601.Method instead of specifying a
special interpretation for AS[0].)
In the specific case which I see as relevant - that of third-party
origination - an i=0 set would be a 5598.Originator asserting that it
had a good faith belief that it was acting on behalf of an Author who
has legitimate use of the domain-name/email-address, despite the fact
that no available Method can be used to substantiate that claim. Typical
cases for this good faith to belief to arise would include at least:
* ESPs acting on behalf of [typically] smaller customers who haven't
gotten their SPF include: and/or DKIM CNAMEs created correctly, and
* webmail services sending with an email address in another domain
that a user has claimed and demonstrated control of (or at least the
ability to receive messages at).
For a receiver, the ability to tell the difference between:
* "we're forwarding this message that we think is probably OK,
although we received it via SMTP and it passed no authentication
mechanisms", and
* "we originated this message on behalf of a customer or user with a
good faith belief that their use of the domain-name/email-address is
legitimate"
would be useful in cases where (and while) the receiver trusted the
Originator's practices in this respect, particularly where a statistical
model was otherwise flagging the message as borderline.
It might reasonably be objected that a DKIM signature by the Originator
alone would achieve the same result, however 7601 2.7.1 makes clear that
DKIM passes need only be reported in Authentication-Results: headers
(and therefore only appear in ARC-Authentication-Results headers) where
they are acceptable to the reporting ADMD, and specifically offers as an
example the case where
"an ADMD policy might require that the signature(s) on the message
be added using the DNS domain present in the From header field of
the message, thus making third-party signatures unacceptable even if
they verify",
meaning that a third-party Originator cannot rely upon an ARC-signing
forwarder to convey this information. As a practical matter, an
ARC-signing forwarder could also throw away the existing chain and start
a new one if it wished, however this is not an expected mode of
operation, while DKIM validators being choosy about what they validate
and/or report certainly is.
An interesting alternative would be to amend 7601 to require the
reporting of all DKIM results and to disregard the fact that some DKIM
implementations simply won't, although this does not seem ideal.
It occurs to me while writing that an additional Method could be
registered for third-party Originators to explicitly assert (a) that
they're originating on behalf of the putative Author, and (b) that
they've authenticated the Author by some prior means. This would appear
to be the essence of the capability that I'm advocating: a standardised
means of making this claim in a form that receivers can recognise
explicitly as being different from a typical forwarding case and
therefore to potentially draw different assumptions. This approach would
not require AS[0], it would simply use AS[1] and cause the assertion to
appear in AAR[1]. Pending the registration of a new Method, this could
simply be a comment on the "none" result:
From: User <[email protected]>
ARC-Authentication-Results: i=1; webmail.example; none (sent by
webmail.example on behalf of [email protected])
or
From: Company <[email protected]>
ARC-Authentication-Results: i=1; esp.example; none (sent by
esp.example on behalf of customer.example)
(some creative abuse of vbr and auth results would work, but wouldn't
quite convey the intended information).
The approach that I had suggested earlier (cv=I) now appears to me to
overload the cv field and, as above, I now view a specific 7601.Method
as a better option than a special interpretation for AS[0].
- Roland
> Yes, AS[1] testifies to the Authenticated-Results of
receiving the message
> from the originator.
That only proves the first receiver was involved. A final
receiver may trust
its results or not.
What is the first receiver reporting if not the authentication
claims made by the originator?
They could equally be reporting fraudulent claims in order to
defeat email security systems at (a) downstream receiver(s).
...meaning nodes 0 (originator) and 1 are in collusion? Sure, that's
possible, but how would requiring an i=0 thwart such an arrangement?
-MSK
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
