On Tue, May 30, 2017 at 11:43 AM, Scott Kitterman <[email protected]>
wrote:

> On Tuesday, May 30, 2017 10:14:08 AM Seth Blank wrote:
> > 2) smtp.client-id
> >
> > The goal here is to track the originating source_ip for DMARC
> > categorization and reporting. Otherwise, all ARC messages will have a
> DMARC
> > report source_ip of the last forwarder, not the originating service. This
> > will be exceptionally confusing to consumers of DMARC reports.
>

When A-R came to be in RFC5451 there was a protracted debate (leading all
the way to an IESG appeal, and ultimately the text of Appendix C in that
document and in RFC7601) about this very thing.  The tl;dr is that we left
it out on purpose, for two reasons:

1) A-R is meant to relay properties of the message that were
authenticated/validated/whatever, and the IP address is not part of the
message or its envelope; and

2) A-R is meant to relay information about what
authentication/validation/whatever was done in a way that's meaningful to
users, and the IP address (especially now in a v6 world) is pretty much
never meaningful to users.

Another way to look at it: A-R is meant to be a channel to record what
authentication was done and what thing in the visible message got
authenticated so, say, an MUA could show the domain name in green next to a
spinning gold key or whatnot to show that it was safe, based on
<method-of-choice>.  It was not meant to provide enough information that an
MUA or internal MTA could re-perform authentication, say, when the message
was opened by a user.

What we're seeking to do here is add it to A-R as a way to get that
information through to a place where DMARC can get it to include in
reports.  If we want to redefine what A-R is to meet that requirement, then
that's something consensus could certainly do, but if not, I'd prefer not
to use it as a substrate against its stated purpose.

We could also, however, standardize "X-Source-IP" (without the "X-", of
course) and use that, as it already has numerous consumers and other
applications well beyond ARC and DMARC.

-MSK
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to