Thank you for your reply. I have reordered some parts of my response to
keep related concepts together.
NB: Keys/hashes, header names etc. are used for illustrative purposes.
On 6/09/2025 4:21 am, Allen Robinson wrote:
I believe that the similar verification can be achieved through
non-breaking changes if the proposed ESMTP DKIM2 syntax is simply
extended to include a signed hash for each recipient. Any upstream
server supporting DKIM2 would pass this along to upstream servers and
the receiving server would be able to verify the recipient was an
intended recipient. This value would then be added to the e-mail
prior
to delivery into the inbox, preserving the ability to perform
client-side verification. This doesn't fully address handover to
non-DKIM2 servers, but a simplified implementation would see faster
adoption of DKIM2 and realisation of the benefits sooner.
Including the addresses of all BCC'd recipients in the signature
header field is obviously bad for privacy reasons. Including a hash is
marginally better. However, a list of hashes still allows recipients
to guess that the email was BCC'd somewhere (more signed recipients
than would be expected based on To/Cc fields). A recipient could also
make educated guesses as to which addresses might have been BCC'd and
check them against the included hashes. Or for a sufficiently small
local part namespace, they could simply bruteforce hash every possible
address.
Based on your subsequent comments, I suspect you figured out what I was
proposing while replying. To avoid any confusion, my proposal is to
include a separate hash for each intended recipient within the envelope
that would be passed along to upstream servers as a RCPT TO parameter.
As such, this information would only be seen by servers that can already
observe BCC recipient addresses in clear text.
I'm not entirely opposed to the idea of splitting messages for BCC
recipients, since most e-mail is going to be split into separate
deliveries at some point anyway, however, by moving the hash to RCPT TO,
any DKIM2-compliant system that CAN split out BCC messages would only be
required to do so on handover from DKIM2 to non-DKIM2 services,
including delivery to the mailbox. At that point, you can simply add a
DKIM-Recipient header containing the hash as that instance of the e-mail
won't be seen by other recipients.
The RCPT TO would look something like this...
RCPT TO:<[email protected]>
DKIMRCPT=oTjChbUP05I+4PXR8wSHTpuy+q/uV9MrnCss8l+J3Js=
DKIMRCPT would include a signed hash of the RCPT TO e-mail address and
the full DKIM-Signature (after signing).
The final delivered e-mail would contain the usual delivery headers,
plus a DKIM-Recipient header...
Return-Path: <[email protected]>
Delivered-To: user_example.com
DKIM-Recipient: [email protected];
h=oTjChbUP05I+4PXR8wSHTpuy+q/uV9MrnCss8l+J3Js=
This preserves the ability for e-mail to have end-to-end DKIM2
verification, including recipient verification, even if created by
systems that cannot practically split the e-mail on submission,
including MTA implementations.
Importantly, this also prevents unnecessary early expansion of e-mails.
Through the volunteer work I do, I receive weekly e-mails that are
regularly in excess of 10MB, and monthly report e-mails that are around
20MB. These are BCCd to around 200 volunteers, most of whom have free
accounts with the big mail providers. I am not authorised to make public
disclosures, so I can't provide specific details that may identify the
organisation, but when a system upgrade unexpectedly sees them being
billed for the additional resources required by a greater than two order
of magnitude increase in e-mail volume, that isn't going to go unnoticed.
I believe I heard that there's an imminent update to either 5321 or
5322 that suggests sending BCC'd recipients separately, independent of
what is being proposed here.
This is concerning, for the reason outlined above. It will also lead to
more e-mail being 'sent', potentially higher rates of rejection and
retries due to more incoming e-mail being observed by receivers.
I think it is only workable if it can be made to work with RSA
signatures though.
I assume this is due to the prevalence of existing RSA keys. After
further consideration, I believe I have a workable solution. See below.
Granting change permissions would also mean intermediary services
don't
need to be DKIM2 aware at all, allowing a smoother transition to
the new
standard. These servers could even be DKIM1 hosts which routinely
sign
and edit messages. Their changes would be trusted because the sender
said they can be. There are a large number of marketing services out
there which quite frankly shouldn't be holding the keys to their
user's
domains. These services require control over keys for a domain
because
they need to alter links and insert tracking etc., but would pass
DKIM
checks using their own key if the ability to grant permission for
changes were to be added to the spec. Users would still need to
setup a
DKIM key (which in most cases they would already have), but it would
remove the need for multiple CNAME records to be placed in DNS to
accommodate marketing providers and have the additional benefit of
not
restricting those providers to switching between one or two
pre-determined selectors. This would greatly ease the ability to
adopt
Ed25519 signatures ahead of a full DKIM1 to DKIM2 transition as it
wouldn't necessitate a hard switch over from one mechanism to
another,
while at the same time improving security and allowing for longer
verification periods.
I don't think this aligns with how I've been told ESPs (Email Service
Provider) work in general. From what I've been told, the typical setup
is that they originate the email (including tracking pixels or
whatever), and sign using both their customer's domain and the ESP's
domain.
The model has shifted significantly, from services providing pure SMTP
to a mixture of SMTP and API-based e-mail services. This has created the
need to sign using the customer's domain, because a customer using the
API never possesses the e-mail in order to be able to do the initial
signing. Most services force the user to create two CNAME records and
sign using those, even if this signing is unwanted. There is a whole
group of users who are only seeking reliable SMTP transit who now have
very limited choice of providers if they (as they should), want to
retain control over their keys to the maximum extent possible.
My recollection from all the services I have tested, which is probably
about a dozen, is that most only sign using the customer's key. They
typically don't allow sending if the DNS records aren't configured, but
those that don't insist on the creation of CNAME records add a
DKIM-Signature using their own domain as you would expect. I.e. When
DKIM is not configured, there is no matching key for the domain, so the
filter simply applies the default.
Deprecating RSA has non-technical barriers. For service providers
operating at scale, it is difficult (verging on impossible) to
convince every customer to publish new public keys. This is the
primary motivation for supporting RSA in DKIM2 at all.
This is actually one of the issues I am attempting to resolve through
the addition of the trusted signer concept. DKIM is limited by only
permitting a single record under each selector name, and altering that
would break existing verifiers that expect a single DNS answer record.
It's something that is easy to fix in code, but it would be a breaking
change, which I'm trying to avoid. A graceful switch to Ed25519 at
present would therefore require four CNAME records, allowing for
reliable rotation of two key types. A hard switch over to Ed25519 would
be possible using two CNAME records, but it would be dependent on
verifiers supporting the new keys first.
Getting users to add records may be difficult, but if we introduce a
trusted signer concept, we can break the dependency on a single pair of
selectors and deploy DKIM2 sans RSA from the outset.
An ESP would do the following...
1. Sign the e-mail using DKIM v1 with one of the current domain keys.
2. Create a new authorisation header, authorising their own server to
sign on behalf of the domain, signed using the same key in step 1.
3. Sign the e-mail again using DKIM2, ensuring all DKIM2 mandated
headers are used, with Ed25519 etc.
The authorisation header would look something like this...
DKIM-Authorized-Signer: d=provider.com; k=ed25519;
s=B9VoiuIq9M6WU6KrK72oBLGV9vkIXl30NwrCnswlpxI=; ...
Because this is a header and not constrained like RCPT TO, we can easily
use any existing RSA key in this authorisation header as well.
A DKIM v1 verifier would be able to use the original DKIM-Signature to
check e-mail integrity. As the ESP controlled the process, this would
always pass if the message is not subsequently changed, preserving DKIM
v1 integrity. A DKIM2 verifier could also check the inserted DKIM2 key
and signing authority, and I expect the spec would contain a SHOULD or
even MUST in that instance to ensure DKIM2 verification is promoted
ahead of the earlier version, especially if a more appropriate minimum
set of headers is mandated.
Where the ESP doesn't have direct control over keys, the steps would
essentially be the same, with the exception that step 1 could also
include a DKIM2 key from the outset, step 2 would be optional if no
changes were permitted (the use case not currently well catered to), and
step 3 would only be necessary if a DKIM2 key were not provided during
step 1 or the e-mail was altered, but given it's innocuous and keeps
mail flow consistent, this step should probably always be done and may
ever be mandated for change tracking.
Modifications can happen on receive-side infrastructure. This mailing
list, for example, appends a couple links at the bottom of all
messages. Modification tracking would allow a downstream receiving
system to see that most of the message was signed by you, and the
footer text was added by ietf.org <http://ietf.org>.
The current mailing list also passes DKIM checks just fine. A mailing
list message is, in my view, a derivative work, so I expect it to be
signed separately. Indeed, looking at the source, very little is as
originally created. It's not my e-mail.
First, I believe distinguishing "good" changes from "bad' changes is
certainly out of scope for DKIM2. I don't think it's possible to come
up with a workable definition for what types of changes are inherently
good or bad. Having reliable information about the changes that were
made and the systems that made them will likely be useful for
higher-level systems that are making these determinations.
I certainly agree that knowing when changes occurred is useful. A single
canonicalisation method alone would help (but not completely) identify
when changes occurred to the body if we sign at each step, although I
favour simple/simple for this purpose.
The ability for changes to be "undone" is something that concerns me
greatly as a sender. It suggesta that e-mail providers will look at the
content of e-mail, decide if changes are insignificant and "pass" the
message if they do. It would go against the fundamental ability for an
organisation to claim ownership of that content and removes vital
protection for both senders and receivers. Any 'discretion' needs to be
something senders can opt out of and be brought to the attention of
recipients, otherwise the new standard risks being completely worthless
and outright dangerous.
Fortunately, detecting changes and approving changes are not mutually
exclusive, and it would also be of benefit by receivers to know
explicitly if changes were approved and factor that into their
decisions, so there's potential to include both concepts.
Regards,
R. Latimer
Inveigle.net
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
