Vittorio, That is a useful redirect. Here is what our data shows.
The analysis covers 6,400 messages processed through EMail Parrot between June and October 2026. Two streams are historical Gmail and Yahoo inboxes, already filtered by those providers’ spam and virus systems; a third stream is dedicated aliases assigned to specific senders, recently created and not yet carrying accumulated marketing relationships. Together they represent the environment in which DKIM2 will deploy. The lead measure is distance from a stated content standard: all remote resources generic, all links generic or function-serving, no identifier in non-rendered regions. Only 21.1% of messages meet all three. Open tracking: 48% of messages carry a confirmed tracking pixel - tiny or hidden, non-CDN host, URL carrying a per-recipient identifier. Under the broader reading adopted by France’s CNIL in March 2026 (effective July 2026), the figure is 83.2%, because loading any remote resource is a reading operation on the recipient’s terminal regardless of whether the URL carries a personal token. Cross-company identity correlation: 12.3% of messages carry a hashed version of the recipient’s own email address transmitted to a third-party domain - a confirmed join key, direct evidence of identity being merged across company boundaries. In the historical Gmail and Yahoo inboxes the rate is 11.9% and 18.1% respectively. In the controlled alias stream it is 0.3%, reflecting that senders given a dedicated alias have not yet propagated it through partner networks. This is the mechanism relay services protect: a controlled address that does not carry the recipient’s accumulated identity across senders. Deceptive or suspicious content - messages where visible link text names a different domain than the actual URL, or where attachments carry active content flags - rose from 9.3% of messages in June to 16.5% in October. The environment is not static. Consumer and regulatory response to these conditions is growing. Apple Mail Privacy Protection, Firefox Relay, DuckDuckGo Email Protection, and the CNIL recommendation adopted in March 2026 reflect the same recognition. The services addressing these conditions share a common technical characteristic: they receive mail, process it on the recipient’s behalf, and re-deliver it under their own domain. In DKIM2 terms, that makes them first-position signers with no prior chain - not because they are evading the protocol, but because re-origination is the mechanism by which they provide the protections the data describes. The concern is precisely that i=1 with no prior chain, left undefined in the adopted BCP, will be treated as an adverse signal by implementations that are trying to do the right thing. Spam filtering and reputation systems operate on many signals. DKIM2 chain structure is a new one, and implementors will use it. Services with demonstrated privacy value should not pay a deliverability cost because the spec left their chain pattern unexplained. William Weiner From: Vittorio <[email protected]> To: "Ietf Dkim"<[email protected]> Date: Tue, 13 Oct 2026 11:52:48 -0600 Subject: [Ietf-dkim] Re: BCP: operator note on header size limits and Message-Instance growth > Hello William, > > Thanks, and for what it is worth neither point was a position, they were > both matters of fact. > > One correction, though. There is no proposal of mine to support. I wrote > to Pete two days ago that in my view this needs no change to the BCP and > that I am not proposing one, and that still holds. What I said about the > general form was not a draft I am carrying. It was a remark on shape, in > case anyone takes the view that this should be written down. My own view > is that it does not need to be. > > On visibility, I do not take part in the meetings either. The sessions > are recorded, though, and the recordings are available afterwards. That > is how I follow them, and the same is open to you. > > If you are looking for something to contribute that nobody else in this > discussion can, I would suggest it is not more text. You operate the > kind of service this discussion is about. Figures from your own > operation, whichever ones you are able to share, would corroborate the > reasoning rather than leave it to be argued. They would carry further > than any wording. > > Regards, > Vittorio Moccia > > Il 2026-10-13 18:20 William Weiner ha scritto: > > Vittorio, > > > > Both points are well taken and I accept them. The combination is not > > specific to re-origination during transition, and narrowing the > > sentence to a named category would reintroduce the heuristic dependency > > it is meant to remove. I should not have framed it that way. > > > > The general principle as you have stated it - that absence of a prior > > chain must not be treated as a negative indicator for an i=1 signature, > > whoever produced it - is the right language and I support seeing it in > > adopted text. > > > > I was not at the September meeting and do not have full visibility on > > where things stand or what you have in mind for this language. Is there > > a way I can usefully support your proposal beyond the statement above? > > > > William > > > _______________________________________________ > Ietf-dkim mailing list -- [email protected] > To unsubscribe send an email to [email protected] > _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
