On 11/30/20 9:43 PM, Brandon Long wrote:
To summarize what I said already in this thread, DKIM is taken by many
receivers as the responsible party for a message, in both spam and
phishing classifiers, with the latter being perhaps more relevant.
DMARC is the one example of that. DKIM signing a message that
transits your system allows for reputation washing of the original
message. The ARC chain is specified as a relay responsibility, which
is a lesser burden.
Ignoring the existing usage of DKIM, DKIM+A-R would only work for a
single hop, and lead to some complication compared to the other DKIM
signatures already on the message.
Wait, what? a DKIM signatures survives until it encounters an
intermediary that alters the message in a breaking manner.
Arc-Signatures are no different in that respect. In fact as far as I can
tell they are identical modulo the i= difference.
DKIM is not the only thing that can be reputation washed, SPF can as
well. 821.FROM rewriting is more common, so there are work-arounds.
OTOH, SPF doesn't survive forwarding, but with ARC you can forward
it. DKIM+A-R would only work for a single hop, and lead to some
complication compared to the other DKIM signatures already on the message.
So mtcc.com <http://mtcc.com> is now hosted by gsuite (::sigh::),
so you're saying that it would run into problems? I haven't put up
a DMARC policy, but if I did I might run into issues with false
positives? Like I said, I'm trying to get my head around what the
actual problems are, and this is coming from a person who stressed
mightily from the very beginning about the mailing list problem.
It's unlikely you have a complicated mail flow involving multiple
vendors, but certainly there are plenty of configuration options
alllowing folks to shoot themselves in the foot.
By definition a message hitting the front door of the destination domain
(via an MX record) sees the DKIM signatures in the message and can
process them at that point, or at some point before other manglers get a
hold of the message. I don't see why we should care at all about what
happens beyond the destination domain's front door because that's their
problem not ours. The entire point of DKIM is the inter-domain case, not
intra-domain.
With ARC, we can instead say "trust this arc admd" and have the data
passed directly, and also work around the DKIM breakage.
But ARC suffers the same breakage with the ARC-Signature. And if the
ARC-Signature is broken, you can't trust the sealed data because that's
a trivial cut and paste attack as far as I can see. So I'm just not
seeing how this is any better than just a plain old DKIM-Signature with
the old auth-res renamed and signed since you can already for 15 years
trust signing intermediaries or not.
As for another comment in the thread about adding two signatures per
hop, there was a suggestion that it could be replaced with a single
signature per hop near last call with some loss of information
(maybe), but it was decided to move forward with the existing solution
that already had several implementations and was experimental anyways.
As I said elsewhere, since this is an active experiment and it's already
been a year, it might be good to start documenting what the experiment
is teaching us. I still after many messages have no clue what what ARC
does that DKIM+old-auth-res cannot beyond tying the authres and
signature together. It would be nice to know in a quantitative way why
that is important, as well as any other things that cannot be done with
DKIM+old-auth-res.
In fact since I expect that most signature breaking intermediaries DKIM
resign the messages (and if they don't thay aren't going to do ARC
either), it would be very simple to chronicle how the two approaches
differ in efficacy. The same reputation look for ARC can be done for
DKIM too, after all.
BTW: i can understand not wanting to touch DKIM or AUTH-RES proper for
an experiment, but a standards track document should really consider
just adding the binding tag to DKIM and Auth-res. They were both
designed to be able to do that.
Mike
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
