But I don't have a solution for ESP messages that use DKIM to authorize the From, but use their own domain for SPF Pas on Mail From. That requires tying the signature to the server and/or Mail From domain using a signature token
On Thu, Jun 29, 2023, 1:25 AM Murray S. Kucherawy <superu...@gmail.com> wrote: > On Wed, Jun 28, 2023 at 5:50 PM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> We are talking about SPF AND DKIM because of the problems with DKIM >> replay. Can someone summarize the state of the DKIM update options that >> have been ruled in or ruled out? >> > > There's a document over in that working group that takes a run at doing so. > > I'm worried about the complexity and assumptions in the proposal that > follows: > > Given a received sequence of >> >> - Msg Date >> - Rcv Date 1 >> - Rcv Date 2 >> - .... >> - Rcv Date N >> >> A signature should have a start time between one of these date boundaries. >> > > There's no reason to trust the dates, IP addresses, or any other detail in > these header fields beyond infrequent manual diagnostic efforts. They are > trivially forged and rarely signed. You definitely should not attempt to > couple anything you infer from them with the semantics of a passing > cryptographic signature. > > The first global IP after the signature server becomes the perimeter >> server which must demonstrate that it's domain has the right to act on >> behalf of the signing domain. >> > > That sounds like the very definition of SPF. > > By "global" I presume you mean "publicly routed". Do we really want to > start teaching mail software how to determine which IP addresses are > publicly routed? It's not as simple as the RFC 1918 question. > > Improvements within control of the signing server: >> >> If the message is not created by the originating server, the message >> should contain one or more Received headers. The header list on the >> signature should contain "Received" entries to match the number of Received >> headers at the time of signing. This further identifies the signature's >> position in the Received chain. >> > > The original DKIM RFC (RFC 4871) specified a list of header fields that > SHOULD and SHOULD NOT be signed, and Received was in the latter group. > It's common for Received fields to be stripped when they depart a domain in > order to conceal the topology within that domain. Less commonly, they can > get reordered, edited, or re-wrapped. Any of those would break the > signature if it covered them. > > RFC 6376, the standard, dropped the SHOULD and SHOULD NOT, but still > discourages paying any attention to Received when signing. > > >> Improvements requiring changes to the DKIM specification >> >> They could identify a way to document the signing server's domain in the >> signature. >> > > Isn't that the "d=" tag? > > -MSK, participating >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
