Dave,
Take a look at how DomainKeys considered the "Sender" header. It may
help your proposal for Sender.
https://tools.ietf.org/html/rfc4870#section-3.3
Specifically, regarding the "h=" tag:
If present, this tag MUST include the header that was used to
identify the sending domain, i.e., the "From:" or "Sender:"
header; thus, this tag can never contain an empty value.
and also section 3.1 "Determining the Sending Address of an Email"
https://tools.ietf.org/html/rfc4870#section-3.1
where there is a protocol language regarding From: and Sender:
--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos
On 7/14/2020 8:30 AM, Hector Santos wrote:
On 7/13/2020 1:21 PM, Dave Crocker wrote:
A proposed new 5322.Author header?
Yes.
Is is required to be hash bound to DKIM signature?
No. In fact the DKIM requirement to include From: in the set of
hash-bound text was a last-minute imposition by an area director,
rather than a functional need set by the working group or larger
community.
No disrespect, but I was an active participant in the DKIM WG and I
don't remember this to be the case.
Since DomainKeys, the 822.From was required to be hash bound to the
signature. I recall this being carried on to DKIM and we did debate
the merits of the binding requirement as the sole anchor and immutable
object that remains with email.
https://tools.ietf.org/html/rfc4870#section-3.3
and it did not change with DKIM followed up:
https://tools.ietf.org/html/draft-allman-dkim-base-01#section-5.4
That has never changed. Let us keep in mind the fact DomainKeys and
the follow up DKIM work, both had a built-in policy component based on
the 5322.From anchor identity since the 5322.From identity was a
hashing requirement. The original APIs for DKIM and Domainkey had
SSP/ADSP lookup functionality.
822.From was selected because this header is not expected to be
legitimately modified or removed in transit. In fact, the signer has
a SHOULD NOT hash a header that could be modified or removed. This
proposal will continue to perpetuate the idea that 5322.From MAY be
modified.
Yes, I do recall that advocates (mostly you and Levine) were against
the 1st party Author Domain dependency requirement preferring instead
a 3rd party sender, 3rd party signer authorization and trust model.
That said, of course I'd expect signers to choose to include it.
I don't see how this can be escape. Something has to be sacred in
email and right now, it is 5322.From which is not expected to be
modified. Cracking open this door will have its consequences.
Will be make it a MUST NOT modified NOR rewrite it?
No idea where this would be mandated or why.
Because of the policy component. We are here because the original
design model aspect to bind an immutable object like 822.From is once
again being questioned by these proposals by the same folks who never
wanted it in the first place.
2) draft-crocker-dmarc-sender
It's a proposal to have DMARC use the Sender: field, in preference to
the From: field.
Ok.
Does this mean the Sender header is now required to be hash bound to
the signature?
cf, above, about the nature of the requirements. Again, it would make
sense to bind it, but mandating is a separate issue.
I am not closed to either proposals but I don't see we can "safely"
have it both ways. You need triggers and variant logics for backward
compatibility and also for enforcement.
We have the logic in place to resolve this issue. The List Systems
need to be updated. Bottom line.
If we are asking developers, signers, verifiers and resigners to
"change" then it should consider what are the current change
"requirements" versus anything new to perhaps simplify it, scale it,
but most importantly resolve the all important 3rd party signers
authorization issue.
We spent 15+ IETF-MAN years in all this and we now going back to the
1st party vs 3rd party signer design model. Does the DKIM Service
Architecture still applicable?
https://tools.ietf.org/html/rfc5585
I believe it was settled that a DKIM Policy as a function of the
5322.From Author domain, the legitimate copyright holder of the
self-signed signature, was a good thing to do to maintain a strong
original integrity of the email. We knew the list integrity change
issue was a problem. We said "make them resign" and they began to do
so. We also knew restrictive policies will cause a list distribution
problem with downlink verifying receivers primarily because we didn't
have a 3rd party resigner authorization protocol.
This is where we left it, never to go away, and its back again.
How do resolve this without re-inventing email and introducing new
headers?
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
