Re: [dmarc-ietf] ARC-Seal is meaningless security theatre

[Bron Gondwana <[e-mail]>]

On Fri, 18 Aug 2017, at 05:11, Brandon Long wrote:
> dammit, posted from the wrong address again...

You'll be dealing with this until the bulk of mailing lists AND
receivers have become ARC aware, so you've got a while to get used to
changing which address you post from :p
> On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana
> <[e-mail]> wrote:>> __
>> 
>> On Thu, 17 Aug 2017, at 10:34, Seth Blank wrote:
>>> On Wed, Aug 16, 2017 at 5:21 PM, Bron Gondwana
>>> <[e-mail]> wrote:>>>> The only way you could even hope (as a mailing list) to avoid
>>>> rewriting the sender is for every site that currently has DMARC
>>>> p=reject to change that to a new policy which explicitly means
>>>> "only reject if no ARC chain" - otherwise you can't stop rewriting
>>>> sender until you know that every receiver on your list is ARC-
>>>> aware.>>> 
>>> I don't understand your point.
>> 
>> 
>> If you are a mailing list and you receive a message from a domain
>> with DMARC p=reject, you can't send that message on to the members of
>> your list without rewriting the sender.>> 
>> 
>>> The only way DKIM works is if enough receivers validate it.
>>> 
>>> The only way adding elliptic curve to DKIM works is if enough
>>> receivers validate it.>>> 
>>> The only way a DMARC policy works is if enough receivers
>>> validate it.>>> 
>>> ARC is the explicit solution to mailing list breakage with DMARC.
>>> But, as with all other IETF RFCs, only works if enough receivers
>>> validate it.>>> 
>>> Our job is to make sure ARC accomplishes its goals under the DMARC
>>> charter, and demonstrate value to receivers that it's worthwhile to
>>> implement.>>> 
>>> There will always be a ramp up and implementation phase, that is a
>>> feature, not a bug, and not a reason to say "it won't work.">> 
>> 
>> While there exists A SINGLE SITE which is ARC-unaware and DMARC
>> p=reject aware, you can't use ARC on a DMARC p=reject domain without
>> rewriting the sender.  Otherwise that site will bounce the email.>> 
>> You still have to rewrite the sender until there is either full
>> adoption or sufficient adoption that you just don't care about the
>> stragglers.>> 
>> ARC doesn't solve that unless every receiver is either ARC-aware or
>> DMARC-unaware.  Hence the suggestion that I think Hector is making -
>> to define a new policy p=rejectnonarc or something, which means that
>> sites which are ARC-unaware accept rather than reject.> 
> Theoretically, if rewriting the from header had been the "approved"
> way to work around DMARC issues for mailing ilsts, one could imagine
> that something like ARC could have explicitly allowed for that concept
> and making it so receivers could back-sub the original From or
> something. That way, ARC implementers would get immediate benefits
> over from rewriting.
I've thought quite a lot about that as well.  I would love if most
mailing lists included enough data to reconstruct the original DKIM-
passing message again, so the receiver could actually know the diff from
the original message and scan it separately.  That way you could very
easily know whether the source of any objectionable content was the
mailing list or the original sender.
> OTOH, if you ignore from header rewriting as a solution (which many
> have), then ARC implementation theoretically adds immediate benefit
> (or the potential for immediate benefit, since it requires
> participation from both the mailing list and receivers)
I kind of buy that.  I'll be interested to see how it pans out in
practice.
> ARC definitely solves more than from header rewriting does, but from
> header rewriting is certainly a much simpler solution for mailing
> lists... even as it makes them slightly worse to use.
As someone just about to launch a new mailing list product, we will be
from-header rewriting for DMARC p=reject domains for at least a little
while, and likely building something horrible which attempts not
rewriting for individual recipients and keeping a whilelist to see if
they don't reject.  Though if someone is just dropping messages, we
would never know - it's a horrible uncertain situation as the site in
the middle, because you don't know how the message will be handled
downstream - it depends on whether the recipient supports ARC, and you
can't know that for sure.
That's the big that makes me uncomfortable - ARC is defined in such a
way that certain participants are unsure of whether they can safely keep
sending legitimate email and have it accepted, because the interaction
with DMARC is defined in such a way that ARC *changes the behaviour of
DMARC* in a non-backwards-compatible way, and we will be running, for at
least a while, in a world in which some recipients treat DMARC the old
way (non-ARC-aware) and some treat it the new way.
So your only possible mitigation as the middleman, if you want full
deliverability, is to modify the message in such a way that DMARC no
longer applies to it.
Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [e-mail]