On Thu 24/Jul/2025 14:07:54 +0200 Taavi Eomäe wrote:
On 24.07.2025 14:26, Alessandro Vesely wrote:
Therefore, we should devise a format in which some tags have multiple
values, dependent on the algorithm, while others are valid for the whole
signature. The selector may also require this
On Mon 21/Jul/2025 16:53:16 +0200 Hannah Stern wrote:
On 7/16/25 10:42, Alessandro Vesely wrote:
On Tue 15/Jul/2025 17:01:14 +0200 Hannah Stern wrote:
[...]
Or
bh1=hash1;bh2=hash2;b=1:signature1:selector1;b=1:signature2:selector2;b=2:signature3:selector3
There seems to be some confusion on
On Wed 23/Jul/2025 20:40:14 +0200 Tero Kivinen wrote:
Alessandro Vesely writes:
On Sun 20/Jul/2025 16:43:35 +0200 Tero Kivinen wrote:
If you count in emails inside big companies, it seems that every
single email is CC'ed to dozen of people [...]
I am not sure if that kind of email
On Sun 20/Jul/2025 16:43:35 +0200 Tero Kivinen wrote:
If you count in emails inside big companies, it seems that every
single email is CC'ed to dozen of people [...]
I am not sure if that kind of emails are intended to use DKIM2, but if
so that kind of traffic might not be vanishingly small,
On Tue 22/Jul/2025 22:37:44 +0200 Murray S. Kucherawy wrote:
On Mon, Jul 21, 2025 at 1:13 PM Alessandro Vesely wrote:
That's right. Ed25519 signatures are often reported as an error rather than
ignored, which is a reason to stop them. Instead, the RFC could have stated
that signers
On Sun 20/Jul/2025 00:58:32 +0200 Dave Crocker wrote:
*Adding mechanisms that are intended to support vanishingly small portions of
cases -- and especially where that support only provides efficiency rather than
necessary functionality -- is pretty much always a terrible idea for a global
stand
On Sun 20/Jul/2025 18:55:58 +0200 Wei Chuang wrote:
On Sun, Jul 20, 2025 at 2:56 AM Alessandro Vesely wrote:
On Sat 19/Jul/2025 21:41:27 +0200 Wei Chuang wrote:
My sense is that over the lifetime of "DKIM2" there will be more algorithm
introductions than circumstances where t
On Mon 21/Jul/2025 12:33:23 +0200 Bron Gondwana wrote:
Let's discuss the merits of the different approaches.
Yes please!
Best
Ale
--
___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
On Sun 20/Jul/2025 09:26:34 +0200 Bron Gondwana wrote:
On Sun, Jul 20, 2025, at 00:58, Dave Crocker wrote:
On 6/18/2025 2:15 PM, Bron Gondwana wrote:
But also, did a lot of thinking about how to support multiple RCPT-TO in a
single SMTP transaction.
Bron, Hi.
Simple question: Why?
Simple
On Sat 19/Jul/2025 21:41:27 +0200 Wei Chuang wrote:
My sense is that over the lifetime of "DKIM2" there will be more algorithm
introductions than circumstances where there is an algorithm breakage, and the
algorithm introductions need to be supported and encouraged for algorithm
diversity. I s
On Thu 17/Jul/2025 15:27:53 +0200 John R Levine wrote:
On Thu, 17 Jul 2025, Alessandro Vesely wrote:
Or we could slice it the other way as I suggested a few messages back,
However, what about:
... s=sel; ab=alg1:hash1, alg2:hash2, alg3:hash3 ...?
The header parser only handles a list
On Thu 17/Jul/2025 01:45:45 +0200 Bron Gondwana wrote:
On Wed, Jul 16, 2025, at 17:05, Barry Leiba wrote:
What's wrong with something like this:
The verifier MUST support at least one of the signature algorithms.
The verifier SHOULD check all the algorithms it supports.
The signature MUST be val
On Wed 16/Jul/2025 16:43:54 +0200 John R Levine wrote:
On Wed, 16 Jul 2025, Alessandro Vesely wrote:
I don't think I've ever seen a message with two headers that differed only
in case and I know don't ever want to see one.
May I ask if it makes sense to sign fields with mul
On Thu 17/Jul/2025 11:41:15 +0200 John Levine wrote:
It appears that Bron Gondwana said:
Tags with duplicate names MUST NOT occur within a single tag-list; if
a tag name does occur more than once, the entire tag-list is invalid.
So if we want to allow multiple b= keys, we would have to c
On Tue 15/Jul/2025 19:05:38 +0200 John Levine wrote:
It appears that Hannah Stern said:
Just do a case-insensitive sort of all of the header fields that
go into the hash.
I'd be fine with that with one caveat: We'd need to specify how to break
the ties between, for example,
Foo: bar
fo
On Tue 15/Jul/2025 17:01:14 +0200 Hannah Stern wrote:
Hi!
How about multiple b=, like this:
DKIM2-Signature: i=1; d=example.com; b=hash1:signature1:selector1;
b=hash2:signature2:selector2; ...
I.e. allow multiple b= and combine bh and selector into the signature (bh too
as to allow for diff
On Fri 11/Jul/2025 17:48:06 +0200 John R Levine wrote:
On Fri, 11 Jul 2025, Alessandro Vesely wrote:
But why multiple signatures? Is it to let verifiers choose what algorithm
they prefer?
No, it's so that signers can sign without having to know what algorithm(s) the
verifiers can h
On Thu 10/Jul/2025 19:52:50 +0200 John Levine wrote:
When we added a new crypto algorithm we realized that you can only have one
key per selector.I gather the plan is to allow multiple signatures
in the same dkim2-signature header so the key records will need to allow
that.
What is the purpo
On Mon 07/Jul/2025 20:07:47 +0200 John R. Levine wrote:
On Mon, 7 Jul 2025, Alessandro Vesely wrote:
On Mon 07/Jul/2025 19:02:14 +0200 internet-drafts wrote:
Internet-Draft draft-gondwana-dkim2-header-01.txt is now available. It is a
work item of the Domain Keys Identified Mail (DKIM) WG of
On Mon 07/Jul/2025 19:02:14 +0200 internet-drafts wrote:
Internet-Draft draft-gondwana-dkim2-header-01.txt is now available. It is a
work item of the Domain Keys Identified Mail (DKIM) WG of the IETF.
It states:
Note that we have not included a version number. Experience from [IMF]
on
On Wed 25/Jun/2025 22:44:11 +0200 Bron Gondwana wrote:
DKIM2-Delta-Body: i=2; c=4-12; b=VGhhbmtzLA==; c=14-35;
b=ZmFtaWx5OkFyaWFsOyI+PGJyPjwvZGl2PjxkaXYgc3R5bGU9M0QiZm9udC1mYW1pbHk6QXJpYWw7Ij5UaGFua3MsPGJyPjwvPQ==; c=37-44
That real example shreds much light. Thanks.
I'd suggest (attempt):
On Wed 18/Jun/2025 23:09:30 +0200 internet-drafts wrote:
https://datatracker.ietf.org/doc/html/draft-gondwana-dkim2-modification-alegbra-02
May I note that the text is hard to grok? In particular:
It is a simple program describing ranges of data
to copy from the output to recreate
On Fri 20/Jun/2025 21:36:53 +0200 Bron Gondwana wrote:
On Fri, Jun 20, 2025, at 14:08, Alessandro Vesely wrote:
On Fri 20/Jun/2025 18:00:10 +0200 Bron Gondwana wrote:
On Fri, Jun 20, 2025, at 03:00, Alessandro Vesely wrote:
On Wed 18/Jun/2025 23:15:37 +0200 Bron Gondwana wrote:
Note that
On Fri 20/Jun/2025 18:00:10 +0200 Bron Gondwana wrote:
On Fri, Jun 20, 2025, at 03:00, Alessandro Vesely wrote:
On Wed 18/Jun/2025 23:15:37 +0200 Bron Gondwana wrote:
Note that we're still signing each recipient individually. Then if Sheila has
a forwarding rule, it only keeps her i=1 h
On Wed 18/Jun/2025 23:15:37 +0200 Bron Gondwana wrote:
Note that we're still signing each recipient individually. Then if Sheila has
a forwarding rule, it only keeps her i=1 header, so that forwarded message
would contain:
DKIM2: i=1; mf=al...@example.com rt=she...@example.org; d=example.com
On Sat 14/Jun/2025 20:53:37 +0200 Steffen Nurpmeso wrote:
(But yes, email address parsing is a hairy thing, if to be done
really right. With fingers pointing everywhere.)
My take, after Murray's:
http://www.tana.it/svn/zdkimfilter/trunk/libopendkim/dkim-mailparse.h
http://www.tana.it/svn/zdki
On Thu 12/Jun/2025 20:04:55 +0200 Bron Gondwana wrote:
On Thu, Jun 12, 2025, at 09:36, Alessandro Vesely wrote:
On Thu 12/Jun/2025 05:41:53 +0200 Bron Gondwana wrote:
From a programmer's point of view, yes. I'm not 1000% sold that we MUST
restrict to a single rt=; there's n
On Thu 12/Jun/2025 18:03:51 +0200 Bron Gondwana wrote:
(duplicate i=1)
DKIM2: i=1;mf=droc...@bbiw.net;rt=c...@fastmailteam.com;
d=bbiw.net*(correctly signed as above)
*DKIM2:*i=1*;mf=dkim-bou...@badguy.com; rt=p...@episteme.net;
d=*badguy.com*
(duplicate i=2, one of each align
On Thu 12/Jun/2025 17:01:33 +0200 John Levine wrote:
It appears that Alessandro Vesely said:
Is that a thing? A message with multiple "From"?
https://www.rfc-editor.org/rfc/rfc6854.html
We beat this to death a few years ago. While it is possible to put two addresses
in the From
On Thu 12/Jun/2025 05:41:53 +0200 Bron Gondwana wrote:
On Wed, Jun 4, 2025, at 05:42, Alessandro Vesely wrote:
On 03/06/2025 23:08, John Levine wrote:
It appears that Alessandro Vesely said:
This may be the norm in discussions, but in practice it is not. I
just sent a message from Gmail
On Mon 09/Jun/2025 18:20:23 +0200 Dave Crocker wrote:
On 6/9/2025 8:30 AM, Alessandro Vesely wrote:
Here DKOR is going to differ from DKIM2 as the older signatures, once broken,
can no longer be verified. DKOR is more similar to ARC in this respect.
I don't understand this assessment
On Mon 09/Jun/2025 18:44:05 +0200 Bron Gondwana wrote:
On Mon, Jun 9, 2025, at 11:30, Alessandro Vesely wrote:
[...] As Dave said, there always will be legitimate scenarios
that match replay abuse scenarios.
I think this is the root of our disagreement. I fundamentally disagree that
there
On Thu 05/Jun/2025 18:37:06 +0200 Allen Robinson wrote:
I haven't had time to read the DKOR drafts so I'm not sure how it would
work in this case. From the discussion on the list, it seems like it would
be similar to the DKIM2 proposal though, from the perspective of replay
mitigation.
AFAIU
On 03/06/2025 00:18, Bron Gondwana wrote:
On Mon, May 26, 2025, at 18:15, Dave Crocker wrote:
[...]
If it detected DKIM Replay in the general case, it would not be trivial -
however it only detects DKIM Replay in the direct case.
Given that Replay is about actions involving an intermediary,
On 03/06/2025 23:08, John Levine wrote:
It appears that Alessandro Vesely said:
This may be the norm in discussions, but in practice it is not. I just sent a
message from Gmail to three of my addresses, two on tana.it and the third to a
different domain
with the same MX. The were received
On 02/06/2025 23:29, Dave Crocker wrote:
On 6/2/2025 2:07 PM, Alessandro Vesely wrote:
So an implementation can either apply DKOR only to messages that have
a single recipient, or split messages to multiple recipients so as to
force them to be sent to a single recipient at a time. The latter
On 02/06/2025 21:18, Dave Crocker wrote:
On 6/2/2025 3:08 AM, Alessandro Vesely wrote:
On 01/06/2025 22:28, Dave Crocker wrote:
On 6/1/2025 4:58 AM, Alessandro Vesely wrote:
Basically, we can assume that all To:/Cc: addresses are legit, since
that's what the author intended.
2. H
On 01/06/2025 22:28, Dave Crocker wrote:
On 6/1/2025 4:58 AM, Alessandro Vesely wrote:
Basically, we can assume that all To:/Cc: addresses are legit, since
that's what the author intended.
1. Unless a to or cc has been replaced along the way.
That invalidates the signature; it'
On 30/05/2025 17:36, Dave Crocker wrote:
- It is technically false to claim that single-recipient is
necessary.
Please provide examples that provide similar benefits with multiple
envelope addressees.
This topic was discussed in the /Multiple rcpt-to's/ thread. Basically,
we can assu
Section 8, Evaluating Behavior, seems to require an exact match. It says:
3. Compare the values to the corresponding DKOR header field
attribute values.
4. If either value does not match, then DKOR fails.
And the example in appendix A3 is wrong; it says:
Routed through a mai
On 27/05/2025 01:15, Dave Crocker wrote:
* A normative practice to have only one recipient per message. This
is needed for O/R signing, but does not need a change to DKIM, per se.
This requirement can be almost entirely relaxed, as rt= is actually only needed
for Bcc:.
See e.g.
https:/
On 15/05/2025 16:30, John R Levine wrote:
On Thu, 15 May 2025, Alessandro Vesely wrote:
The SMTP extension is unsuitable in this case, ...
We gave up on the SMTP extension ages ago when someone pointed out that
large mail systems handle mail for many domains, some of which might do
DKIM2
On 14/05/2025 18:44, John R Levine wrote:
On Wed, 14 May 2025, Wei Chuang wrote:
Another alternate method is to support both DKIM2 and DKIM1 as implied
throughout this thread. Forwarders that modify messages with a DMARC
consequence will also have to DKIM1 resign and rewrite the From to take
On 13/05/2025 17:15, John R Levine wrote:
On Tue, 13 May 2025, Alessandro Vesely wrote:
Let us not forget that one of the goals of DKIM2 is to make this kind
of munging unnecessary.
I also thought this was the desired solution to the mailing list
problem. In fact, since a DKIM2 verifier can
On 12/05/2025 17:50, John Levine wrote:
It appears that Alessandro Vesely said:
When you deliver a message, if you want to undo that particular change to make
it easier to reply to list messages, that's not a bad idea, and it's something
I've been doing for years on my mai
On Sun 11/May/2025 21:11:52 +0200 John Levine wrote:
It appears that Alessandro Vesely said:
The real case is lists writing weihaw=40google@dmarc.ietf.org. When I can
revert the MLM transformation, I restore the original From: field, especially
for the recipient's use. For reports
On Sat 10/May/2025 22:35:44 +0200 Wei Chuang wrote:
On Wed, May 7, 2025 at 5:42 AM Alessandro Vesely wrote:
On Wed 07/May/2025 00:18:41 +0200 Wei Chuang wrote:
forwarders will likely also want a say in what happens to a message that fails
validation.
In order to keep it simple, I'd con
On Fri 09/May/2025 03:03:22 +0200 John Levine wrote:
It appears that Bron Gondwana said:
So if there's anything ARC currently does better, I'd want to see if we
can implement that into DKIM2 as well. One case that has already been
discussed is the signed Authentication-Results headers, and I
On Wed 07/May/2025 00:18:41 +0200 Wei Chuang wrote:
forwarders will likely also want a say in what happens to a message that fails
validation.
In order to keep it simple, I'd conceive the author domain, the one in From:,
to be the "owner" of the message.
we propose that the forwarder doma
On Mon 05/May/2025 20:29:40 +0200 Wei Chuang wrote:
Security gateways may modify the message in complex ways that message algebra
cannot cover
If changes cannot be described, how can DKIM2 be used?
The old version (-01) of the motivation draft had a "complex" value for m=,
described as "This
On Tue 29/Apr/2025 21:27:30 +0200 John Levine wrote:
It appears that Bron Gondwana said:
I'm not clear about the logic by which we can assume that IETF MLs will
promptly adopt DKIM2 but will ignore DKOR. Since DKOR is much simpler, it
sounds more likely people will adopt it more quickly than
On Mon 28/Apr/2025 22:41:03 +0200 Bron Gondwana wrote:
On Mon, Apr 28, 2025, at 15:37, Tero Kivinen wrote:
Bron Gondwana writes:
[...]
With DKIM2, the second message would have on its copy from me:
DKIM2-Signature: i=1; mf=br...@fastmailteam.com; rt=ietf-dkim@ietf.org; d=
fastmailteam.com
On Tue 22/Apr/2025 17:17:34 +0200 Murray S. Kucherawy wrote:
On Tue, Apr 22, 2025 at 11:12 AM Alessandro Vesely wrote:
On Tue 22/Apr/2025 16:49:29 +0200 Murray S. Kucherawy wrote:
On Tue, Apr 22, 2025 at 4:56 AM Alessandro Vesely wrote:
On Tue 15/Apr/2025 21:21:58 +0200 Bron Gondwana wrote
On Mon 21/Apr/2025 23:51:05 +0200 Richard Clayton wrote:
In message , Dave Crocker
writes
I've drafted a specification intended to provide a DKIM-based means of
controlling DKIM Replay, based on community discussions of what is needed.
I think you may have overlooked some aspects of what is
On Mon 21/Apr/2025 19:29:10 +0200 Allen Robinson wrote:
I agree that a large number of recipients is not a requirement for replay
attacks. Abusers that target many mailboxes tend to get more attention than
those that target small numbers (or one) due to their ability to negatively
impact a send
On Tue 22/Apr/2025 16:49:29 +0200 Murray S. Kucherawy wrote:
On Tue, Apr 22, 2025 at 4:56 AM Alessandro Vesely wrote:
On Tue 15/Apr/2025 21:21:58 +0200 Bron Gondwana wrote:
So I'm very interested in a discussion of *"should we have an exclude-list
rather than an include-list
On Mon 21/Apr/2025 21:05:03 +0200 Murray S. Kucherawy wrote:
On Mon, Apr 21, 2025 at 2:14 PM Alessandro Vesely wrote:
While it is relatively easy to detect mime-wrap, footer or similar
transformation, changes in encodings, quotes and comments are difficult or
impossible to guess. Quoted
On Tue 15/Apr/2025 21:21:58 +0200 Bron Gondwana wrote:
So I'm very interested in a discussion of *"should we have an exclude-list
rather than an include-list of signed headers?"*
Don't sign MIME-Version: especially if it has comments.
Best
Ale
--
On Mon 21/Apr/2025 09:39:22 +0200 Wei Chuang wrote:
On Sat, Apr 19, 2025 at 6:03 AM Alessandro Vesely wrote:
Transparent transformations, such as base64 encoding, must be recognized as
such by the algebra. Alternatively, we could require that hashing be performed
on the decoded content, but
On Sun 20/Apr/2025 17:42:58 +0200 Allen Robinson wrote:
On Sun, Apr 20, 2025, 7:09 a.m. Alessandro Vesely wrote:
In practice, what should I do in such a scenario when I receive a message From:
arob...@google.com whose author domain signature is not verified because the
message has been
On Mon 21/Apr/2025 09:37:35 +0200 Wei Chuang wrote:
On Sun, Apr 20, 2025 at 4:10 AM Alessandro Vesely wrote:
I would prefer to use a class of "good" transformations, such as the subject,
footer, mimeify, add-part and mime-wrap of draft-kucherawy-dkim-transform,
I also like the id
On Sat 19/Apr/2025 18:51:38 +0200 Allen Robinson wrote:
On Sat, Apr 19, 2025, 9:02 a.m. Alessandro Vesely wrote:
[...]
* I base64 decoded this MIME part.
* I inserted bytes N-M
* I trimmed the text "foobar" starting at byte N
* I base64 encoded the MIME part
I would prefer to use
Hi,
one thing the draft doesn't explain is that the presence of both MAIL-FROM: and
RCPT-TO: allows a chain to be constructed where the domain of the previous
RCPT-TO matches the next MAIL-FROM. Since DKIM does not mark the sequence of
signatures, this should be inferred from the position of
On Fri 18/Apr/2025 23:59:35 +0200 Allen Robinson wrote:
On Fri, Apr 18, 2025, 2:10 p.m. Alessandro Vesely wrote:
Not evil could be summarized in a few rules, such as:
* Can modify the Subject: by adding a tag. It must be in square brackets and
shorter than 20 chars.
* Can add a footer
On Wed 16/Apr/2025 21:04:27 +0200 Richard Clayton wrote:
In message , Larry M. Smith
writes
Experience has shown that threat actors are willing to go to great
lengths to have access to a large pool of resources to abuse and then
rapidly discard.[1] Knowing what object to apply poor reputati
On Mon 14/Apr/2025 19:01:35 +0200 Wei Chuang wrote:
Instead I think we need a better way that can describe the originator, when a
message was forwarded and when a participant tries to spoof the forwarding
description. DKIM2 does this. With that we can more easily see abusive
scenarios like re
On Wed 16/Apr/2025 17:20:19 +0200 Murray S. Kucherawy wrote:
On Sat, Apr 12, 2025 at 12:28 AM Dave Crocker wrote:
On 4/11/2025 12:56 PM, Richard Clayton wrote:
[...]
I agree we need to get the history right here. I don't necessarily agree
that this is fatal to adoption.
[...]
If a
On Sat 12/Apr/2025 09:52:21 +0200 Dave Crocker wrote:
On 4/11/2025 12:57 PM, Richard Clayton wrote:
The term forwarding is ambiguous. It is used to mean very different types of
behavior.
*If 'forwarding' means every MTA, this is a massive infrastructure
change to the entire Internet Mai
On Wed 09/Apr/2025 06:15:16 +0200 Dave Crocker wrote:
On 4/8/2025 5:43 AM, Alessandro Vesely wrote:
Although different, DKIM2 shares a huge amount of concepts developed
alongside DKIM, from the tag=value specification, to underscored domains and
key distribution, to hashing and signing. The
On Sun 06/Apr/2025 20:56:35 +0200 Dave Crocker wrote:
The goals for the new effort are for a very different set of services. There
is nothing wrong with wanting those services, but really, they are not DKIM.
The semantics of the new effort really are orthogonal to DKIM. (And that is
one of t
On Thu 20/Mar/2025 09:57:26 +0100 Bron Gondwana wrote:
On Wed, Mar 19, 2025, at 08:24, Wei Chuang wrote:
On Tue, Mar 18, 2025 at 3:51 AM Bron Gondwana
wrote:
I'll take this as a review comment that I need to be much more clear on how it
works! This text from section 2 tried to describe how
On Mon 24/Mar/2025 20:19:29 +0100 Richard Clayton wrote:
In message , Alessandro Vesely
writes
BTW, is dkim2=fail different from "failing DKIM2 signatures from a 100% DKIM2
mail chain"? I mean, do verifiers always check all the signatures along the
chain or can sometimes chec
On Sat 05/Apr/2025 18:58:02 +0200 John R Levine wrote:
On Sat, 5 Apr 2025, Alessandro Vesely wrote:
If we could just say these headers only occur once, if you see two just give
up, it makes the process somewhat simpler and more importantly ends the
argument about oversigning.
This argument
On Mon 24/Mar/2025 14:13:01 +0100 Richard Clayton wrote:
In message <04daef5f-46a1-4393-8f42-677d2d375...@tana.it>, Alessandro Vesely
writes
Accommodating multiple recipients in the signature would have the added value
of confirming to whom a message is destined. There are companie
On Wed 02/Apr/2025 18:01:40 +0200 John Levine wrote:
It appears that Murray S. Kucherawy said:
Most (all?) non-trace headers are defined to occur only once, like From:
and Subject:
I think this could work also and agree it would shorten the list of header
fields that have to be oversigned.
On Wed 02/Apr/2025 10:45:43 +0200 Steve Atkins wrote:
On 2 Apr 2025, at 00:26, Michael Thomas wrote:
On 4/1/25 3:19 PM, Richard Clayton wrote:
In message , Michael Thomas
writes
Two different code paths, two different places for screw ups and
maintenance. I'm with Murray that there is a lot
On Sun 30/Mar/2025 21:12:25 +0200 Dave Crocker wrote:
On 3/30/2025 12:10 PM, Murray S. Kucherawy wrote:
I seem to recall previous discussions have suggested that the "v" tag
shouldn't have been included in the first place; if things are so different
that you need to change the version, you may
On Wed 02/Apr/2025 23:48:23 +0200 Jim Fenton wrote:
Section 2.3: I’m wondering how sending bounces in reverse along the same path
will work for large domains. Presumably it does an MX lookup of the sending
domain? There might be incoming third-party mail handlers, and the domain
itself may have
On Wed 02/Apr/2025 18:03:31 +0200 John Levine wrote:
It appears that Alessandro Vesely said:
No, it's not so much the interpretation of pass/fail, which I think will be
expressed by policies anyway, but the checks you perform to achieve that
result. DKIM2 checks the envelope, for ex
On Tue 01/Apr/2025 19:45:10 +0200 Murray S. Kucherawy wrote:
On Tue, Apr 1, 2025 at 10:26 AM Alessandro Vesely wrote:
The resulting DKIM verifier is not semi-broken, it's DKIM2-tolerant. And
it's not just a library change, it's also the MTA interface.
First you said: "a
On Mon 31/Mar/2025 18:40:30 +0200 John Levine wrote:
It appears that Murray S. Kucherawy said:
On Mon, Mar 31, 2025 at 1:56 AM Alessandro Vesely wrote:
There is room for a lot of compatibility. If we don't change the
canonicalizations, a DKIM1 verifier will be able to verify a
On Tue 01/Apr/2025 19:07:40 +0200 John R Levine wrote:
On Tue, 1 Apr 2025, Alessandro Vesely wrote:
Sorry for being unclear. What I meant was that, given DKIM2, a DKIM1 verifier
could be updated to handle DKIM2 signatures —if DKIM2 signatures were
specified with compatibility in mind.
That
On Mon 31/Mar/2025 21:32:54 +0200 John Levine wrote:
Most (all?) non-trace headers are defined to occur only once, like From: and
Subject:
How about we say that if a signer or verifier sees more than one of them, stop
and the result is failure, no oversigning needed.
+1, make this part of
On Mon 31/Mar/2025 18:37:58 +0200 Al Iverson wrote:
On Mon, Mar 31, 2025 at 11:30 AM Murray S. Kucherawy
wrote:
On Mon, Mar 31, 2025 at 1:56 AM Alessandro Vesely wrote:
There is room for a lot of compatibility. If we don't change the
canonicalizations, a DKIM1 verifier will be ab
On Mon 31/Mar/2025 14:30:27 +0200 Taavi Eomäe wrote:
On 31/03/2025 15:25, Brotman, Alex wrote:
I have a hard time believing that all the libraries focusing on DKIMv1 will
go back and create some code to handle this case.
Indeed, they probably won't. Which is exactly why it might be better to h
On Sun 23/Mar/2025 20:16:20 +0100 Allen Robinson wrote:
By having two independent headers, DKIM2 systems can continue to participate in
DKIM1 however they do now, so DKIM1 verifiers would observe no change in the
signatures they are being presented as a result of DKIM2 adoption.
I agree. Yet
On Mon 24/Mar/2025 19:21:23 +0100 Murray S. Kucherawy wrote:
On Mon, Mar 24, 2025 at 10:53 AM Michael Thomas wrote:
Out of curiosity would, say, a mailing list that breaks the original
signature but signs on the mailing list's behalf count as "signed"? At some
level DKIM is about taking respo
On Wed 26/Mar/2025 17:31:54 +0100 Wei Chuang wrote:
On Wed, Mar 26, 2025 at 9:08 AM Alessandro Vesely wrote:
Hmm... Delivered-To: doesn't seem to be a significant element. [...]
It's meant to be illustrative of some header updates during forwarding
where someone e.g. a mailin
On Wed 26/Mar/2025 20:09:33 +0100 Richard Clayton wrote:
In message , Alessandro Vesely
writes
On Mon 24/Mar/2025 20:19:29 +0100 Richard Clayton wrote:
Of course, If I trust the signer of the last signature, it would be fine to
check only that. Bat that would be too similar to ARC
On Wed 26/Mar/2025 16:13:23 +0100 John Levine wrote:
It appears that Wei Chuang said:
the "rt=" or in the RFC5322 address headers. Which of these is easier to
adopt by open source DKIM and SMTP packages? Might splitting all
recipients be a simple config already in those open source SMTP?
On Wed 26/Mar/2025 09:23:19 +0100 Wei Chuang wrote:
FORWARDED MESSAGE: From header rewritten and Delivered-to added
DKIM2-Signature: i=2; h=list-unsubscribe-post:delivered-to
From: list@mailinglist.example
Wasn't the purpose to keep the author's real address in the From: field?
Delivered-to
On 26/03/2025 09:18, Wei Chuang wrote:
On Tue, Mar 25, 2025 at 9:43 AM Wei Chuang wrote:
On Tue, Mar 25, 2025 at 3:06 AM Alessandro Vesely wrote:
On Mon 24/Mar/2025 20:49:32 +0100 Wei Chuang wrote:
To support that use case and other scenarios where the recipient is not
explicitly declared
On Mon 24/Mar/2025 20:49:32 +0100 Wei Chuang wrote:
To support that use case and other scenarios where the recipient is not
explicitly declared in the RFC5322 message e.g. some mailing lists, the sender
can populate a DKIM2-Signature "rt=" tag. Note that "rt=" here still only
supports a single
On Fri 21/Mar/2025 19:13:47 +0100 Tobias Herkula wrote:
As a receiver, I already reject some portions of traffic if it is unsigned or
an existing signature does not verify. I would vote for a clear statement that
failing DKIM2 signatures from a 100% DKIM2 mail chain should provoke a reject,
as
On Sun 23/Mar/2025 16:13:12 +0100 Allen Robinson wrote:
On Sun, Mar 23, 2025, 7:13 a.m. Alessandro Vesely wrote:
On Thu 20/Mar/2025 19:54:02 +0100 Allen Robinson wrote:
I don't think DKIM2 helps at all in that case.
A sender is well within their rights to put in a new header that spec
ly be considered less disruptive to SMTP
than one that does.
Best
Ale
On Thu, Mar 20, 2025 at 12:48 PM Alessandro Vesely wrote:
On Wed 19/Mar/2025 17:22:06 +0100 Michael Thomas wrote:
On 3/18/25 12:30 PM, Richard Clayton wrote:
In message <746bd827-77d0-4991-ba67-507d84566...@mtcc.com&
On Fri 21/Mar/2025 15:41:27 +0100 Todd Herr wrote:
I am of the belief that if and when DKIM2 reaches a state of widespread
adoption, there is no longer a need for Domain Owners signing with DKIM2 to
participate in DMARC, a belief I expressed during the IETF 122 meeting.
I wasn't at the meetin
On Wed 19/Mar/2025 17:22:06 +0100 Michael Thomas wrote:
On 3/18/25 12:30 PM, Richard Clayton wrote:
In message <746bd827-77d0-4991-ba67-507d84566...@mtcc.com>, Michael
Thomas writes
simplicity ... at the point at which an email is being signed it is not
possible to know how many recipients t
On Mon 17/Mar/2025 20:08:04 +0100 Richard Clayton wrote:
In message , Michael Thomas
writes
On 3/16/25 5:34 PM, Richard Clayton wrote:
PPS: I'm don't understand why this requires the rt= to be limited
to just one address.
simplicity ... at the point at which an email is being signe
On Sun 16/Mar/2025 04:59:57 +0100 Bron Gondwana wrote:
On Sun, Mar 16, 2025, at 04:50, Alessandro Vesely wrote:
I think an argument could be made that this definition doesn't apply to all
relays. Systems that don't need to change 821.From or 821.To and don't modify
th
1 - 100 of 216 matches
Mail list logo
