[dmarc-discuss] A bit quiet?

MH Michael Hammer (5304) MHammer at ag.com
Mon Oct 26 07:54:45 PDT 2015



> -----Original Message-----
> From: dmarc-discuss [mailto:dmarc-discuss-bounces at dmarc.org] On Behalf
> Of Scott Kitterman via dmarc-discuss
> Sent: Monday, October 26, 2015 8:04 AM
> To: dmarc-discuss at dmarc.org
> Subject: Re: [dmarc-discuss] A bit quiet?
> 
> On Monday, October 26, 2015 06:47:33 AM Roland Turner via dmarc-discuss
> wrote:
> > Scott Kitterman wrote:
> > > On October 23, 2015 1:48:13 AM EDT, Roland Turner via dmarc-discuss
> <dmarc-discuss at dmarc.org> wrote:
> > >>The question is not who you trust - ARC doesn't directly change that
> > >>- but how you reliably automate determining whether the message was
> > >>forwarded only by people that you trust. At present, you have to dig
> > >>through Received: headers, infer per-forwarder internal structure
> > >>and behaviour and, frequently, guess. ARC addresses that problem,
> > >>not the one you're asking about.
> > >>
> > > I don't see why the signing domain of the DKIM signature that could
> > > be added by the most recent sender doesn't already give an
> > > identifier  to use to evaluate trust in the sender.
> >
> > It does, but that only allows you to identify - and apply your trust
> > assessment to - the most recent sender. ARC provides a means to
> > automatically assess the chain *upstream* of the most recent sender.
> 
> Only if you already have a high degree of trust in the most recent sender.
> 

ARC provides additional visibility into the chain of message handlers, not just the most recent sender/handler. This may be useful to ultimate receivers in implementing local policy decisions, both in a DMARC context as well as absent a DMARC context.

> > It might be worth pointing out that trust is this context is not
> > absolute, and should not be transitive, because:
> >
> > - trusting the integrity (good intention) of the forwarder is not the
> > same as trusting the competence of the forwarder, and
> >
> > - there are different competences that you may or may not be willing
> > to trust (ability of a forwarder to ARC/DKIM sign correctly and
> > maintain secrecy of keys is a *far* lower bar than ability of a
> > forwarder to make exactly the same decisions about what abuse to
> > exclude as those that you as receiver would make, particularly when
> > you make local, secret decisions as part of doing so; this distinction
> > gets increasingly acute as receivers get larger).
> 
> Since the most recent sender can claim in an ARC stamp whatever arbitrary
> upstream senders they care to, it seems to me that placing any value at all on
> an ARC stamp from anything other than a highly trusted sender opens an
> abuse vector.
> 

As much as I believe the use of reputation is ultimately limited (I believe that reputation ultimately is "What have you done to me lately"), if the most recent (arbitrary) sender is making false claims in an ARC stamp, it should become apparent fairly quickly.

> > > I can see that ARC gives a way to communicate information about the
> > > upstream senders, but I don't see how that's related to DMARC.
> >
> > Many receivers implementing DMARC wish to be able to make decisions
> > about when to ignore p=reject on a more fine-grained basis than
> > all-or-nothing trust of the most recent sender. ARC is built to
> > facilitate this and, therefore, is directly relevant to DMARC.
> 
> It would already require a high level of trust in the most recent sender not to
> engage in ARC stamp forgery to do this.  Since DMARC is about
> authentication of an identity (5322.From), if you trust the most recent sender
> not to have forged the ARC stamp, I'm still not seeing the value of them
> adding the stamp.
> 
> > > From a DMARC perspective, if you know the sender is trustworthy, you
> > > do a local override.  ARC doesn't seem to be needed for that.
> >
> > You keep talking about "the sender" as if there were only one. In your
> > message to which I am replying, there are 7 Received: headers in
> > various formats from 3, 4 or 5 ADMDs, interspersed with various
> > information about authentication assessments. This is tough for me to
> > assess as a human with considerable expertise in this area. For
> > software to do it reliably would be both difficult and fragile. If you
> > don't get why being able to perform this assessment automatically and
> > reliably is valuable then ARC is never going to make sense to you, no matter
> how many detail questions you ask.
> > I'd suggest that this may simply mean that ARC is not relevant to you
> > and that, therefore, it may be the case that you can safely ignore it
> > while those for whom the problem is relevant move forward to run the
> experiment.
> 
> When I'm receiving a message, I'm receiving it from a single sender.  The
> message may have a history before that, but from my perspective, it's only
> got one at the moment.
> 

There are enough (large) mailbox providers who believe there is value in having visibility into the chain of handler(s) (assertions), I defer to them. As a representative of a (formerly heavily abused) sender who asserts p=reject for our website domains, I want mailbox providers to make the most informed possible decision if they are going to assert local policy contravening our p=reject policy assertion. Until there is code running in the wild we will not know the ultimate value of ARC or if there will need to be additional tweaks. There was an effort to determine percentages of mail that goes through multiple hops across administrative domains and the amount of mail involved decreases dramatically as the number of hops increases.

> I've never said ARC doesn't have value.  I've said I didn't see the value for
> solving the the issue that DMARC has with mailing lists that perform
> transformations that break DKIM signatures (like this one).   This is the
> DMARC list, not the ARC list.
> 

It appears that there is value for DMARC validators in terms of helping inform their local policy decisions. What those local policy decisions are, will likely vary by mailbox provider.

> I'm trying to understand why people seem to be claiming ARC is somehow
> helpful to DMARC.  I don't dispute it may be independently useful, but those
> uses would be off topic here.
> 
> > >>The amount of discussion to date about specific historical whitelist
> > >>proposals is neither here nor there. The question is whether ARC's
> > >>degree of support for reliable automatic chain-of-custody assessment
> > >>provides a material improvement for a group of receivers
> > >>interoperating with a group of forwarders. So long as the answer to
> > >>that question is yes, then this is progress. I'd suggest that:
> > >>
> > >>*   large receivers are generally keen to implement things that
> > >>materially improve their ability to separate wheat from chaff (ARC
> > >>does this if it's implemented by any significant subset of
> > >>mailing-list operators), and
> > >>*   at least some of the mailing-list operators whose discomfort with
> > >>DMARC interoperation is the need to disrupt long-traditional norms
> > >>(leaving From: unchanged but tagging Subject:, stripping multiparts,
> > >>adding footers, ...) will be willing to perform ARC processing on
> > >>messages on the way in, in order to interoperate without giving up
> > >>traditional mailing-list operations.
> > >>
> > >>If these are both true, then ARC is a clear benefit.
> > >>
> > > Only if ARC processing materially affects if receivers are willing
> > > to consider the mailing list as trusted.
> >
> > No, as with *ALL* protocol specifications, decisions about who to
> > trust are out of scope. Operators will always make their own decisions
> > about who to trust, protocol specifications can't usefully take over this
> function.
> 
> The reverse is not true, however.  Operation of protocol specifications can
> give information about who not to trust.  By design, DMARC receivers don't
> trust DMARC fail messages from p=reject domains.  ARC doesn't, on it's own,
> seem to provide any change in that regard.
> 
> > > ARC appears to leverage knowledge of who are trusted senders to make
> > > it easier to trace a message path.
> >
> > Yes.
> >
> > > If there's a way to know which senders are trusted, then DMARC can
> > > already be overridden.
> >
> > No, for the reasons outlined above, it's not currently possible - in
> > general
> > - to work out whether the sender named in a particular Received:
> > header actually handled the message. Your argument is a little like
> > claiming that DKIM is not necessary because if you trust the domain named
> in the From:
> > header and also the most recent sender then you don't need to perform
> > your own signature validation. The need for DKIM arises specifically
> > because this is not true, even for forwarding that does not modify
> > messages. ARC addresses an analogous problem for forwarding which does
> modify messages.
> 
> No.  That's not right either.  Without something like SPF or DKIM you've got
> no authenticated identifier to leverage.  It's not analogous though.  As a
> domain owner, I can control what sources of mail are able to generate mail
> that passes SPF or has a valid DKIM signature with d= my domain.  Anyone,
> anywhere can generate an ARC stamp with my domain in it, so it's completely
> different.
> 
> > > Maybe I am just failing to understand, but this reads to me like a
> > > solution to the DMARC mailing list problem that only works if there
> > > already exists another solution to the DMARC mailing list problem.
> > > That or it's completely unrelated to DMARC.
> > > I'm not sure which.
> >
> > The fact that chain-of-custody doesn't immediately jump out at you as
> > an extremely useful tool for receivers suggests that you've never
> > needed to solve the problem in question. The issue then is simply that
> > the problem is not relevant to you personally, in which case perhaps
> > the solution isn't either.
> 
> Please stop claiming I said ARC is not useful.  I didn't.  If I was arguing that, I'd
> have subscribed to the ARC list and argued it there.  On this list what I'm
> looking for is relevance to DMARC and the issues DMARC currently has.
> 
> I think you've pretty much confirmed ARC and DMARC are orthogonal
> technologies that address different issues.  That's fine.
> 

I wouldn't call them orthogonal because there is some relationship overlap (think Venn diagram), but only to the extent of enhancing the ability of DMARC validators/mailbox providers that choose to use ARC in making local policy decisions. The fact that (some) large mailbox providers have committed to ARC provides an opportunity for maillists which implement ARC signing to mitigate issues they have encountered as a result of DMARC p=reject policy assertions by (some) senders.

Mike




More information about the dmarc-discuss mailing list