I understand that Authentication-Results are intended for use within a
single organization, since any assertion by an outsider could be
malicious.
Since IETF does not apply ARC Sets, we are using A-R as a proxy for what
might be possible with ARC, but the two are different.
I still see a problem with ARC or A-R. These headers assert, "These
attributes had these statuses values when I saw them," but they do not
reliably indicate when that look was performed. The typical message
header set provides a list of address identifiers which have little
connection to servers, and a list of server identifiers which have little
connection to the address identifiers.
Consider these results from a sample message from this list. They are
presented in the order that they appear in the message headers (top might
be newest.) The first two are A-R and the bottom one is ARC-A-R:
ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=
comcast.com
ietf.org; dkim=none (message not signed) header.d=none;ietf.org;
dmarc=none action=none header.from=comcast.com;
i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comcast.com;
dmarc=pass action=none header.from=comcast.com; dkim=pass header.d=
comcast.com; arc=none
The bottom one tells me that an authenticator identified as "
mx.microsoft.com 1" saw an SPF Pass, but I don't know what IP address it
authenticated, and I don't know when this occurred. There are no
Microsoft.Com servers in the Received header list, and the Auth-Ident is
not intended to convey a server or domain identifier.
The bottom entry says that the message passed DKIM, but the second entry
tells me that there are no signatures at all, yett the third one assures me
that the signatures have suddenly reappeared and are verifiable.
DKIM, A-R, and ARC should all have a mandatory attribute indicating the
HELO name of the server applying the header, the IP Address of the previous
server which supplied the information being evaluated, or both. Without a
link between the address identifiers and the server identifiers, I don't
see how a viable algorithm can be constructed to use the data.
Message forwarding provides so much opportunity to confuse the spam filters
that I am surprised that the bad guys do not use it extensively.
DF
On Tue, Dec 29, 2020 at 3:01 PM Michael Thomas <[email protected]> wrote:
>
> On 12/29/20 11:35 AM, Todd Herr wrote:
>
> None of the validation checks bothered with the p= value in the
> mrochek.com DMARC policy record, because the p= value is immaterial to
> the validation check. Whether DMARC passes or fails is based on whether SPF
> or DKIM passes or fails with an aligned domain, full stop.
>
> Once the DMARC validation result is determined, then the mailbox provider or
> entity performing the DMARC validation check can refer to the p= value in
> determining how to dispose of the message, but it doesn't have to. It's worth
> noting perhaps that Google does record message disposition in the auth-res
> header, though:
>
> dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mrochek.com
>
> Unless those values in parens are a MUST requirement, the dmarc=fail is
> highly misleading. I haven't even seen any specification for the dmarc part
> of auth res in rfc 7601, which may be part of the problem. I don't see any
> normative language which would update rfc7601 in dmarc with the syntax and
> semantics of the dmarc field.
>
> At the very least this needs to be straightened out because auth-res, to
> Ned's earlier point, can have consumers in the form of MUA's.
>
> Mike
> _______________________________________________
> dmarc mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dmarc
>
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
