[arc-discuss] [dmarc-discuss] A bit quiet?

Terry Zink tzink7 at gmail.com
Mon Nov 2 11:41:48 PST 2015


> For heavily abused domains and/or financials, the decision of a mailbox
provider to
> implement a local policy decision to deliver a message which has failed
to validate
> DMARC under a p=reject policy may potentially create liability issues and
resultant
> lawsuits.

I hear this threat frequently - not delivering email can result in
lawsuits. Delivering email can result in lawsuits. Slightly modifying email
in transit can result in lawsuits.

But does it actually happen in real life (I mean a complaint with merit,
not from a troll)? I've been involved in lawsuit discussions internally and
I work for a company that gets sued all the time. Every lawsuit is about
something involving intellectual property, and not a single one about how
we make decisions to filter someone's email.

On Mon, Nov 2, 2015 at 10:00 AM, MH Michael Hammer (5304) via arc-discuss <
arc-discuss at dmarc.org> wrote:

>
>
> > -----Original Message-----
> > From: arc-discuss [mailto:arc-discuss-bounces at dmarc.org] On Behalf Of
> > Steven M Jones via arc-discuss
> > Sent: Saturday, October 31, 2015 8:50 PM
> > To: arc-discuss at dmarc.org
> > Subject: Re: [arc-discuss] [dmarc-discuss] A bit quiet?
> >
> > On 10/31/2015 16:57, Dave Crocker via arc-discuss wrote:
> > > On 10/31/2015 4:21 PM, Murray S. Kucherawy wrote:
> > >> On Sun, Nov 1, 2015 at 7:20 AM, Dave Crocker <dcrocker at gmail.com
> > >> <mailto:dcrocker at gmail.com>> wrote:
> > >>
> > >>     The premise is that DMARC should work on its own.  With respect to
> > >>     DMARC, ARC is interesting only if DMARC didn't succeed.
> > >>
> > >>     It is, in other words, useful as a possible path to
> "rehabilitate" a
> > >>     DMARC failure.  Yes, it is possible to define other relationships
> > >>     between the two mechanism but I will proffer that my description
> > >>     defines the simplest and (therefore) cleanest one.
> > >>
> > >>
> > >> There's little distinction in my mind, operationally at least,
> > >> between augmenting DMARC (we did always say it should be extensible)
> > >> to support a new mechanism than to have that mechanism's result
> > >> supersede DMARC's in some cases.  It's basically the difference
> > >> between "A or B or C" and "(A or B) or C".
> > >
> > > That's not my model and I don't think matches what the design team has
> > > been discussing.  That said, it hasn't quite discussed this specific
> > > enough for me to be sure.
> >
>
> The discussions have always been in the context of assisting local policy
> decisions. This is quite a different context than "rehabilitating" DMARC
> failures or including it in DMARC as a mechanism. All that is really needed
> within DMARC with regard to ARC  is to define what reporting would look
> like in the context of local policy.
>
> > Agreed that the inspiration was DMARC, insofar as DMARC highlighted cases
> > where authentication failures for indirect flows had previously been
> ignored,
> > and then (under certain DMARC policies 2012+) were being enforced. You
> > should find examples of early adopters in the dmarc-discuss archives -
> myself
> > included - who went to "p=reject" in the first months and reverted after
> > impacts to indirect flows were observed.
> >
> > In my mind, at least, trying to cast ARC as something evaluated
> during/within
> > DMARC evaluation would require more consideration. It /seems/
> > reasonable, and we tried to keep ARC independent with respect to other
> > mechanisms...
> >
>
> Please refer to my above comment. Local policy is just that, local. Unless
> one is assured that there would be consistency in behavior/outcomes across
> validators/mailbox providers, it is best not to attempt to introduce ARC as
> a DMARC validation mechanism. The originating domain asserting DMARC
> p=reject policy is not required to participate in ARC signing. P=reject is
> a very clear assertion notwithstanding the fact that some domain
> owners/administrators are not comfortable with the consequences of making
> such an assertion. The decision of mailbox providers to not follow a
> p=reject assertion is local policy, pure and simple. For heavily abused
> domains and/or financials, the decision of a mailbox provider to implement
> a local policy decision to deliver a message which has failed to validate
> DMARC under a p=reject policy may potentially create liability issues and
> resultant lawsuits.  Local policy!=interoperability and limiting it to the
> reporting aspect where implemented is the!
>   correct approach in this situation.
>
> > I think the stumbling point is a whiff of something like recursion or a
> > boundary violation -- the first intermediary would evaluate DKIM, SPF,
> and
> > DMARC normally, then convey all those results through ARC. The final
> > recipient would evaluate DKIM and SPF normally vis a vis the most recent
> > hop, then unpack ARC and evaluate the first intermediary's DKIM, SPF, and
> > DMARC results, which would all be fodder for the final recipient's DMARC
> > evaluation? And would a verifying second or third intermediary also
> unpack
> > ARC as an input to local DMARC evaluation, before it affixes
> > *its* ARC headers?
> >
> > Like I said, more consideration required. But _that_ kind of change to
> DMARC
> > would seem to be proper fodder for the IETF DMARC WG.
> >
> >
> > >
> > >>
> > >>     IMO ARC has other interesting uses, having nothing to do with
> DMARC,
> > >>     but consequently they shouldn't get discussed in a DMARC spec.
> > >>
> > >>
> > >> ARC can be (and certainly should be) specified independently of
> > >> DMARC, rendering it useful to those other interesting uses.  I don't
> > >> think that should preclude DMARC from adopting it directly, just as
> > >> DMARC would hopefully formally adopt whatever DBOUND comes up
> > with.
> > >
> > > Right.  DMARC is the motivation.  But no, there is no reason it should
> > > be the only user.  (Getting folk to see that ARC is not actually "part
> > > of" or "tied to" DMARC has sometimes taken some effort, and I'm not
> > > sure the effort is consistently successful...
> > >
> > > Anyhow, by way of example, DKIM use itself would benefit from adding
> > > ARC, since it permits propagating origination signature results after
> > > the signature is broken.
> >
> > +1. It seems like there's sufficient potential value to SPF- or
> > DKIM-only scenarios to keep ARC independent. Give it time and see whether
> > or not there is ARC uptake amongst those who eschew DMARC. Maybe ARC
> > becomes a useful way to drive email authentication further out along the
> > long tail...
> >
> > --Steve.
> >
> > _______________________________________________
> > arc-discuss mailing list
> > arc-discuss at dmarc.org
> > http://lists.dmarc.org/mailman/listinfo/arc-discuss
>
> _______________________________________________
> arc-discuss mailing list
> arc-discuss at dmarc.org
> http://lists.dmarc.org/mailman/listinfo/arc-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dmarc.org/pipermail/arc-discuss/attachments/20151102/674e8523/attachment-0001.html>


More information about the arc-discuss mailing list