On Monday, November 14, 2016 05:34:19 PM Murray S. Kucherawy wrote:
On Mon, Nov 14, 2016 at 4:37 PM, Scott Kitterman
<ietf-dkim(_at_)kitterman(_dot_)com>
wrote:
Doesn't that presuppose point-to-point handling? The proposal here
doesn't.
Your proposal breaks all non-point-to-point handling, if I understand it
correctly, so whether you make DKIM signatures non-forwardable or do it in
DMARC policy, it's the same end result.
How does it break all non-point-to-point handling? It does break if the
envelope has to change, but that's not what I think of when you say
"point-to-point"; it makes me think of mail from A to C that happens to
transit B, which should survive just fine.
Within an ADMD, internal relaying should survive just fine, since, as you say,
RCP TO doesn't change, but I don't think that's an interesting case. Email
authentication check tend to be very fragile if not done at the edge of the
ADMD for lots of reasons.
What I was thinking of was non-point-to-point handling while between two
ADMDs. Typically mailing lists or transparent forwarding. In both of those
cases, RCPT TO changes. One set of advice given to mailing list operators
about DMARC has been to change their list setup so that they don't break DKIM
signatures (and some have done that). This proposal would make that
impossible.
Between two ADMDs, you would not be able to change RCPT TO, so it would have
to go direct. At that point, if you engage DMARC alignment requirements on
the SPF check, you achieve the same result.
Also, if you make this a DMARC policy choice, then the added restrictions
associated with restricting changes to RCPT TO only affect senders that have
opted into the policy choice.
I think your pushing a substantial change to DKIM and to the extent this
is a reasonable problem to solve, DKIM isn't the right layer in the email
authentication stack to do it.
Ah, yes, that's a plausible argument.
I think the solution to "I have a problem that results when I sign spam"
is "don't do that", not the entire community turns on its head to work
around someone's local configuration problems.
Yes, I agree that's the preferable solution. It sounds as if there are
some operators (well, at least one, I think) that are having a problem for
which "don't do that" is an expensive solution, and a question has been
posed about the possible existence of an easy, incremental protocol
solution for it. It's fine if the answer is "no", but I'd like to have the
discussion without prematurely slamming any doors.
OK. Ultimately, "don't sign spam" has got to be the solution or reputation is
going to suffer, so I think they are going to have to eventually bite the
bullet and fix it. I don't think an opt-in extension to DMARC like I suggest
above is unreasonable and I think it would be able to be deployed more
quickly. So far though, I don't see fixing it in DKIM as a good way to go.
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html