The registration problem is not a red herring because it doesn't
exist, but because it is intractable. Thus, any response to the
third-party problem that relies on a solution to that problem
(which includes ATPS, DSAP, and TPA) is probably not viable.
I agree.
But I think that some of the "re-signing" schemes being proposed at
the moment do *not* require this type of registration, so in those
cases, the registration problem wouldn't apply. If A is not "signing
B's mail", but rather, "signing its own modifications to B's message",
then the evaluation of the two signatures doesn't require a published
or pre-existing relationship between the two domains.
The signers still needs a "database" to determine when to add the
double signature and the MLM receiver still needs to support the
detection of this in order to allow it or not if missing.
IOW, the MLM receiver still needs to reject the MLM submission and the
final receivers still need support it as well otherwise the bounces
will still occur that causes automated unsubscribe problems. So no
matter what, the MLM still needs to support it.
- Signer needs to know when it double signs,
- MLM receiver filters restrictive domains, allows double signers,
resigns doubles.
- End-User Receivers support the resigned double signers.
So there are changes at three places with a registration concern as
well. At best, with the alternative to the DNS lookup, you have done
two things;
- got the DNS administrator out the picture and
- maybe less endorsement requirement from the DNS community.
But it comes with a higher risk of security problems -- potential,
theoretical. Doesn't mean it can happen and probably a way to get
around that too, for example, its possible to have a double From: exploit:
From: user1@domain1 <---- unprotected, unsigned from
From: user2@domain2 <---- hash bound DKIM protected
If the MUA displayed the first one, you have fraud, phishing
potential, etc. We addressed that by making it a responsibility of
the receiver to check for a valid RFC5322 first. But DKIM should
also check it too just in case the MTA doesn't check it.
Doing a munge of the 5322.From is a old industry taboo. If any system
does it, to me, and strongly believe many of my industry peers as
well, they are renegades, no control and liable to legal issue. I
wouldn't trust them. Its an ethical thing and I would probably appeal
any recommendation to do so within an IETF mail protocol document.
Its the same exploitable idea of a Double From and it will probably
encourage filter writers to seek out a From Munged transaction
detection strategy and immediately reject it.
Now we are creating wars when you do that and the IETF should not
encourage such mail matters. From Munging SHOULD NOT be an
recommendation coming from the IETF.
--
HLS
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
