On Sat 25/May/2024 19:02:04 +0200 Dave Crocker wrote:
1) It appears that the issue with l= is that implementers are not doing
it correctly, and that there's even lazy-unto-hostile use of it. If this
is the case, that implementers are not doing the spec properly, I don't
see that changing
On Tue 28/May/2024 21:08:26 +0200 Hector Santos wrote:
On May 25, 2024, at 12:49 PM, John R Levine wrote:
On Fri, 24 May 2024, Jon Callas wrote:
1) It appears that the issue with l= is that implementers are not doing it
correctly, ...
If there ever was a correct way to use l=, there sure
On Thu 23/May/2024 20:13:07 +0200 John Levine wrote:
I guess this isn't as obvious as the authors of 6376 thought since we still
have at least one person on this list insisting that you don't need to sign C-T.
It's ill-conditioned to use l=. Not signing C-T is fine.
Best
Ale
--
On Thu 23/May/2024 16:44:07 +0200 Wei Chuang wrote:
On Mon, May 20, 2024 at 7:17 PM Murray S. Kucherawy wrote:
On Sun, May 19, 2024 at 9:27 AM Wei Chuang wrote:
[...]
One idea is to have the forwarder sign with an ARC Message-Signature and
would take ownership of the new message. The
On Tue 21/May/2024 16:41:20 +0200 John Levine wrote:
It appears that Alessandro Vesely said:
I'd be curious to learn why [John would certainly want the signature to
break if someone changed the Content-Type header on a message he sent]. A
mailing list might change it from >>
C
On Mon 20/May/2024 20:10:44 +0200 John Levine wrote:
It appears that Jeremy Harris said:
On 20/05/2024 09:06, Alessandro Vesely wrote:
Content-Type: is a technical field
Not a term I've met before. Is there a formal definition?
As Dave said, no. There isn't even an informal definition
On Sun 19/May/2024 21:28:21 +0200 Jeremy Harris wrote:
On 19/05/2024 17:26, Wei Chuang wrote:
then rewrite the Content-type header mime delimiter
Seems like including this header in the signed set would be
Best Practice?
I hope not. Content-Type: is a technical field, which forwarders
On 05/02/2024 17:02, Hector Santos wrote:
On Feb 3, 2024, at 8:23 AM, Alessandro Vesely wrote:
RFC 5322 specifies lists for From:, To:, Cc:, Bcc:, Reply-To:,
Resent-From:, Resent-To:, Resent-Cc: and Resent-Bcc:.
My comment was regarding the MUA and the order data is read. I wonder
which
On Fri 02/Feb/2024 14:34:22 +0100 Hector Santos wrote:
Of course, the MUA is another issue. What read order should be expected for
Oversign headers? Each MUA can be different although I would think streamed in
data are naturally read sequentially and the first display headers found are
used
On Wed 31/Jan/2024 18:34:46 +0100 Hector Santos wrote:
If I add this feature to wcDKIM, it can be introduced as:
[X] Enable DKIM Replay Protection
That'd be deceptive, as DKIM replay in Dave's sense won't be blocked, while
there can be other effects on signature robustness. A better
On 16/01/2024 17:52, Mike Hillyer wrote:
One example of this documented is Brian Godiksen's blog post at
https://www.socketlabs.com/blog/dkim-replay-attacks-preventive-measures-to-protect-email-deliverability
The post explicitly mentions subject, to, from, date and reply-to
headers. I
On Mon 30/Oct/2023 20:44:20 +0100 Steffen Nurpmeso wrote:
I still think ED25519 is not gracefully supported by all DKIM implementations
because you cannot use a stream based approach, but must load the entire data
"in memory", it is a one-off algorithm.
Irrespective of what the advantage of
On 9/27/23 16:47, Brotman, Alex wrote:
Some senders use a different selector when sending from different ESPs while
they use the same d= in the DKIM signature.
Don't same d= mean they don't want to differentiate? Using a different
selector is an a artifact of keys distribution; it doesn't
On 9/27/23 13:36, Brotman, Alex wrote:
I've attached a draft that uses attributes of a passing DKIM
signature to create a DNS label that can be used to discover an FBL
address. This feedback address can be used by message receivers to
provide a copy of FN (and potentially FP) (Spam/Not-Spam)
On Thu 21/Sep/2023 22:27:30 +0200 Brotman, Alex wrote:
Including that data in a DMARC report may not be very useful if it's going
to the domain holder instead of the DKIM signer. For example, SES signs all
of their messages, but unless that 5322 owner shares the data, they wouldn't
see any
On Sun 10/Sep/2023 18:44:00 +0200 Jesse Thompson wrote:
On Fri, Sep 8, 2023, at 9:23 AM, Murray S. Kucherawy wrote:
On Fri, Sep 8, 2023 at 7:17 AM Jesse Thompson wrote:__
Is rfc6651 a lost cause? It looks like it defines a reporting mechanism in
control of the signer, as opposed to the
On Wed 30/Aug/2023 14:14:41 +0200 Dave Crocker wrote:
On 8/30/2023 1:21 AM, Alessandro Vesely wrote:
On Wed 30/Aug/2023 07:35:08 +0200 Murray S. Kucherawy wrote:
On Tue, Aug 29, 2023 at 8:11 PM Dave Crocker wrote:
On 8/29/2023 7:46 PM, Grant Taylor wrote:
On 8/29/23 9:02 PM, Dave Crocker
On Wed 30/Aug/2023 06:20:47 +0200 Steve Atkins wrote:
On 30 Aug 2023, at 03:38, Grant Taylor
wrote:
On 8/29/23 3:15 PM, Steve Atkins wrote:
Any attempt by senders to filter outbound emails based solely on content is
going to have a lot of false negatives and positives, wherever you decide
On Wed 30/Aug/2023 07:35:08 +0200 Murray S. Kucherawy wrote:
On Tue, Aug 29, 2023 at 8:11 PM Dave Crocker wrote:
On 8/29/2023 7:46 PM, Grant Taylor wrote:
On 8/29/23 9:02 PM, Dave Crocker wrote:
Why not re-use the existing DKIM solution, just with a different
domain / set of keys?
Because
On Fri 18/Aug/2023 12:21:31 +0200 Emanuel Schorsch wrote:
For example, we have seen very large DKIM Replay attacks of youtube.com
Terms of Service emails. There is no malicious content in these emails,
but spammers still send very large volumes (perhaps using them to
generate affinity with
On Thu 17/Aug/2023 20:12:51 +0200 Emanuel Schorsch wrote:
On Thu, Aug 17, 2023 at 2:06 PM Alessandro Vesely mailto:ves...@tana.it>> wrote:
If corporate domains are victims of replay attacks at the same rate as
free mail providers, then my theory is wrong. See below. >
Ale
On Thu 17/Aug/2023 18:21:35 +0200 Murray S. Kucherawy wrote:
On Thu, Aug 17, 2023 at 3:30 AM Alessandro Vesely wrote:
I'm not convinced advice is necessary here. Do you really need signs in
banks that say "Don't put your signature on random financial documents"? I
have
On Thu 17/Aug/2023 04:45:48 +0200 Bron Gondwana wrote:
On Tue, Aug 15, 2023, at 21:36, Alessandro Vesely wrote:
On Tue 15/Aug/2023 08:10:23 +0200 Bron Gondwana wrote:
We've love to not sign spam at all, but short of never allowing users to send email, it's
not actually possible. We're
On Wed 16/Aug/2023 20:19:44 +0200 Dave Crocker wrote:
On 8/16/2023 10:48 AM, Murray^W Ale wrote:
Yet, an open
signer is for DKIM the equivalent of what an open relay is for SPF.
It is nothing of the sort.
Open relays perform a relaying function, which actively moves mail, where the
abuse is
On Wed 16/Aug/2023 19:48:30 +0200 Murray S. Kucherawy wrote:
On Wed, Aug 16, 2023 at 10:25 AM Alessandro Vesely wrote:
On Wed 16/Aug/2023 15:26:43 +0200 Laura Atkins wrote:
On 16 Aug 2023, at 12:59, Alessandro Vesely wrote:
On Wed 16/Aug/2023 11:17:50 +0200 Laura Atkins wrote:
On 16 Aug
On Wed 16/Aug/2023 15:26:43 +0200 Laura Atkins wrote:
On 16 Aug 2023, at 12:59, Alessandro Vesely wrote:
On Wed 16/Aug/2023 11:17:50 +0200 Laura Atkins wrote:
On 16 Aug 2023, at 09:57, Alessandro Vesely wrote:
How about enacting common sense rules such as Never sign anything without reading
On Wed 16/Aug/2023 11:17:50 +0200 Laura Atkins wrote:
On 16 Aug 2023, at 09:57, Alessandro Vesely wrote:
How about enacting common sense rules such as Never sign anything without reading
the small print? In the same way that users agree to any Terms & Conditions
without reading, dom
On Tue 15/Aug/2023 14:59:18 +0200 Laura Atkins wrote:
On 15 Aug 2023, at 12:36, Alessandro Vesely wrote:
On Tue 15/Aug/2023 08:10:23 +0200 Bron Gondwana wrote:
"Problem solved." [...]
Hm.. More than defining the replay attack, we need to define what kind of
solution is
On Tue 15/Aug/2023 08:10:23 +0200 Bron Gondwana wrote:
On Thu, Aug 3, 2023, at 15:50, Michael Thomas wrote:
Barry Leiba Tue, 01 August 2023 18:40 UTC
I do think the background is important to publish separately for this
work, however easy the problem is to describe.
It's because "replay"
On Sat 12/Aug/2023 21:52:13 +0200 Steffen Nurpmeso wrote:
Alessandro Vesely wrote in :
On Fri 11/Aug/2023 23:49:20 +0200 Steffen Nurpmeso wrote:
Alessandro Vesely wrote in <76cede70-0558-ed62-7420-97e2e899e...@tana.it:
On Fri 11/Aug/2023 00:33:46 +0200 Steffen Nurpmeso wrote:
Murra
On Fri 11/Aug/2023 23:49:20 +0200 Steffen Nurpmeso wrote:
Alessandro Vesely wrote in <76cede70-0558-ed62-7420-97e2e899e...@tana.it>:
On Fri 11/Aug/2023 00:33:46 +0200 Steffen Nurpmeso wrote:
Murray S. Kucherawy wrote in
:
On Wed, Aug 9, 2023 at 3:14 PM Steffen Nurpmeso wrote:
And co
On Fri 11/Aug/2023 00:33:46 +0200 Steffen Nurpmeso wrote:
Murray S. Kucherawy wrote in
:
On Wed, Aug 9, 2023 at 3:14 PM Steffen Nurpmeso wrote:
And couldn't it become standardized that verification results then
must be included in future DKIM signatures?
So then a verifier inserts a RFC 7001
On Tue 08/Aug/2023 16:47:23 + Murray S. Kucherawy wrote:
On Tue, Aug 8, 2023 at 9:25 AM Alessandro Vesely wrote:
On Tue 08/Aug/2023 14:47:37 + Murray S. Kucherawy wrote:
On Tue, Aug 8, 2023 at 7:17 AM Scott Kitterman wrote:
That's true of all indirect mail flows. It's
On Tue 08/Aug/2023 14:47:37 + Murray S. Kucherawy wrote:
On Tue, Aug 8, 2023 at 7:17 AM Scott Kitterman wrote:
That's true of all indirect mail flows. It's not a distinguishing feature
of the attack.
Quite right, making this harder to pin down.
But, to Alessandro's point, I do think
On Mon 07/Aug/2023 23:52:02 + Scott Kitterman wrote:
On Monday, August 7, 2023 7:47:47 PM EDT Murray S. Kucherawy wrote:
I think the document does describe the attack. An instance of the attack
is when a replayed message lands someplace it wasn't originally intended to
land, assuming
On Sun 06/Aug/2023 18:07:15 + Jesse Thompson wrote:
On Sat, Aug 5, 2023, at 6:50 AM, Laura Atkins wrote:
[...]
The replay attackers aren’t sending what we commonly think of as spam
through the signers - as the message is sent to one recipient (not
bulk) and it is opt-in (that recipient
On Tue 01/Aug/2023 16:09:03 + Tim Wicinski wrote:
Problem Statements may be published but are more importantly considered
working documents with consensus from the working group.
We should get more "what didn't work" - people should send text !
I agree what-didnt-work can efficiently
On Thu 13/Jul/2023 05:33:44 +0200 Grant Taylor wrote:
On 7/12/23 9:26 AM, Wei Chuang wrote:
Being able to reverse mailing-list message modifications to repair the
message and enable digital signature verification, would resolve a
significant roadblock for further DMARC deployment.
On Fri 30/Jun/2023 19:22:28 +0200 Barry Leiba wrote:
Ale, you're venue-shopping; please don't do that.
Sorry, I understood the discussion was banned from the dmarc list.
In fact, messages that would only be blocked by auth=dkim+spf are either
messages that pass DKIM but fail SPF, or
Hi,
for those of you who don't subscribe to dm...@ietf.org, I resume this proposal,
which was aired there last week.
The idea is to let a domain specify which mechanisms to consider when
validating DMARC alignment. The default would be auth=dkim/spf, meaning that
either an aligned
On Fri 24/Mar/2023 18:42:28 +0100 Dave Crocker wrote:
On 3/24/2023 6:45 AM, Dave Crocker wrote:
On 3/24/2023 6:42 AM, Laura Atkins wrote:
We currently have two problem statements to discuss for adoption.
Wei is merging 'mine' into his. (Note mine was done as a variant of his.)
For folks
On Thu 23/Mar/2023 01:21:55 +0100 Dave Crocker wrote:
My understanding is that the term DKI MReplay Attack refers to a very specific
scenario.
The scenario is re-posting a message such that the original DKIM signature
remains valid.
Any other sort of re-posting does not qualify, under
On Wed 22/Mar/2023 20:31:51 +0100 Michael Thomas wrote:
On 3/21/23 8:01 PM, Murray S. Kucherawy wrote:
1. What percent of incoming email to a mailbox is through
resenders and of that what percent resign?
By "resign" you mean something that has signatures from two domains,
On Mon 20/Mar/2023 07:04:11 +0100 Emanuel Schorsch wrote:
In my mind, there are two important things I would like to see achieved:
1) Distinguish indirect from direct flows (encode in some way which server /
mailingList the original DKIM message was intended to come from). This is
needed for
Just a couple of comments on Jim's comments. I don't quote the text on which I
agree, unless I have to add to it.
On Tue 07/Mar/2023 23:46:18 +0100 Jim Fenton wrote:
To get things going, here are a few comments on
draft-chuang-dkim-replay-problem-01:
Section 1.1:
[...]
“Bcc header field”:
On Thu 16/Feb/2023 21:56:52 +0100 Barry Leiba wrote:
Okay. What's the value for X - T that prevents this problem, but doesn't cause DKIM
signatures of "normal" mail to fail?
There's not one "right" value; we're talking about distributions
of timings for normal mail vs. replay, and yes,
On Tue 14/Feb/2023 23:42:36 +0100 Scott Kitterman wrote:
On Tuesday, February 14, 2023 4:16:00 PM EST Evan Burke wrote:
On Tue, Feb 14, 2023 at 11:44 AM Michael Thomas wrote:
On Tue, Feb 14, 2023 at 11:18 AM Michael Thomas wrote:
Have you considered something like rate limiting on the
On Tue 14/Feb/2023 06:43:22 +0100 Evan Burke wrote:
On Fri, Feb 10, 2023 at 2:31 PM Michael Thomas wrote:
On 2/10/23 2:10 PM, Evan Burke wrote:
The M3AAWG BCP will cover recommended header signing/oversigning policies.
I'll make sure that's shared here when it's published.
Any idea when
On Sun 12/Feb/2023 22:51:25 +0100 Dave Crocker wrote:
On 2/12/2023 1:44 PM, Murray S. Kucherawy wrote:
Would this work if it passes through more than one layer of aliasing? That
is, can this work if "Separate-Envelope" appears more than once? Do they all
have to be signed, order preserved,
On Fri 03/Feb/2023 01:06:27 +0100 Scott Kitterman wrote:
There is an existing draft of a problem statement, so there's at least a
starting point to consider. I think discussion about what's needed is probably
more useful relative to a specific draft than in the abstract:
On Sat 04/Feb/2023 00:44:35 +0100 Michael Thomas wrote:
On 2/2/23 4:06 PM, Scott Kitterman wrote:
There is an existing draft of a problem statement, so there's at least a
starting point to consider. I think discussion about what's needed is
probably more useful relative to a specific draft
On Sat 04/Feb/2023 04:45:15 +0100 Michael Thomas wrote:
On 2/3/23 6:25 PM, Murray S. Kucherawy wrote:
But with respect to replay: Even if To and Cc are signed, there's nothing in
DKIM requiring that they reflect any identities present in the envelope.
That's not the point. The point is that
On Thu 05/Jan/2023 22:26:32 +0100 Dave Crocker wrote:
On 1/5/2023 9:20 AM, Alessandro Vesely wrote:
How about "replay-resistant protocol"?
btw, it isn't clear that 'protocol' is what a solution will be. might be.
might not. might be purely operational conventions, for example.
On Thu 05/Jan/2023 20:35:00 +0100 Dave Crocker wrote:
On 1/5/2023 11:03 AM, Wei Chuang wrote:
2. Are there any other kinds of replay scenarios that are an issue now?
I suspect there aren't.
While not exactly ARC replay, we've seen recently that spammers are exploring
munging the ARC
Here's another idea to tell legitimate vs. abusive forwarding:
https://datatracker.ietf.org/doc/draft-vesely-email-agreement/
Best
Ale
--
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
On Thu 05/Jan/2023 17:33:36 +0100 Murray S. Kucherawy wrote:
I've added a few proposed milestones with dates
I wouldn't call "replay-resistant DKIM enhancement(s)" the deliverable. I
understand the WG name is DKIM, but two of the proposed drafts don't even
mention it. We may call ARC a
On Thu 15/Dec/2022 00:46:42 +0100 Jim Fenton wrote:
On 13 Dec 2022, at 17:00, Michael Thomas wrote:
Which brings up a question: even though they pass on DKIM they should fail on
SPF, right? For transactional email that seems like a big old red flag, right?
Some people use receive-side
On Tue 13/Dec/2022 18:06:55 +0100 Evan Burke wrote:
On Tue, Dec 13, 2022 at 8:45 AM Jim Fenton wrote:
Is there anything that you can say about the types of domains whose
reputations are suffering as a result of replay attacks? Are they, for
example, small consumer mailbox providers, email
On Mon 12/Dec/2022 15:50:44 +0100 Laura Atkins wrote:
On 12 Dec 2022, at 14:34, Murray S. Kucherawy wrote:
On Mon, Dec 12, 2022 at 1:13 AM Alessandro Vesely mailto:ves...@tana.it>> wrote:
The alternative is to say: Well, if you can't make at least one of those
two quantities bulle
On Sun 11/Dec/2022 21:52:46 +0100 Murray S. Kucherawy wrote:
On Sun, Dec 11, 2022 at 12:34 PM Michael Thomas wrote:
As for resolution: the first obvious one is to not send spam in the first
place. That is the root of the problem. The second is that Bcc's can be
treated with more suspicion.
On Fri 09/Dec/2022 16:47:47 +0100 Grant Taylor wrote:
On 12/8/22 5:17 AM, Alessandro Vesely wrote:
Those who do so are neatly classified as spammers.
On one hand I agree. But on the other hand I disagree.
One benign case is that webmas...@example.com is configured to forward to
al
On Wed 07/Dec/2022 18:49:47 +0100 Laura Atkins wrote:
On 7 Dec 2022, at 17:16, Barry Leiba wrote:
The purpose of a DKIM signature is, as our original statement put it, to make sure that a message from your
bank actually came from your bank, even if it passed through your alumni association.
On Wed 07/Dec/2022 16:49:55 +0100 Grant Taylor wrote:
On 12/7/22 2:59 AM, Alessandro Vesely wrote:
ARC is a good forwarding tool.
I question the veracity of that. Mostly around -- what I consider to be --
the priming problem of getting a receiving system to trust an upstream
system's ARC
On Tue 06/Dec/2022 22:52:33 +0100 Michael Thomas wrote:
I think that any charter should specifically call out the need for a
problem statement. The problem is far more nuanced than the few lines in
the proposed charter and I think that the charter should be neutral about
whether the problem
On Sat 03/Dec/2022 07:38:24 +0100 Murray S. Kucherawy wrote:
I've placed what I believe is the text that is closest to consensus in the
datatracker:
https://datatracker.ietf.org/doc/charter-ietf-dkim/
Please provide comments or criticism soon.
Please add the other Wei's I-D:
On Tue 22/Nov/2022 01:21:00 +0100 Murray S. Kucherawy wrote:
Just for the sake of being complete, we should probably come up with
something to say about this, which is in RFC 4686, the DKIM "threats"
document:
DKIM operates entirely on the content (body and selected header
fields) of
While I like the terseness of Dave's text, its limiting the focus on DKIM may
mislead. It is natural to blame DKIM, but someone suggested that DKIM is
working as intended even in replay attacks. Indeed, differentiating a mailing
list from a replay attack on the basis of signatures is
On Thu 17/Nov/2022 00:56:12 +0100 Roland Turner wrote:
On 17/11/22 04:59, Alessandro Vesely wrote:
I fancied an experiment where a MLM offers a per-subscriber choice on whether
to munge From: or not. The way I envisaged it was to have users whitelist the
ARC/ DKIM signing domain
On Thu 17/Nov/2022 00:48:51 +0100 Roland Turner wrote:
On 17/11/22 04:34, Alessandro Vesely wrote:
On Wed 16/Nov/2022 05:35:52 +0100 Roland Turner wrote:
[ARC seals are] Not quite [enough], because they're not usually applied
when a message is forwarded intact. One outcome of the proposed WG
On Wed 16/Nov/2022 05:32:24 +0100 Roland Turner wrote:
On 15/11/22 03:01, Alessandro Vesely wrote:
The exception is a standardised mechanism to allow a sender/signer to
indicate the [approximate] number of intended recipients, with which
receivers might make fact-based decisions about when
On Wed 16/Nov/2022 05:35:52 +0100 Roland Turner wrote:
On 15/11/22 23:10, Alessandro Vesely wrote:
On Mon 14/Nov/2022 18:54:33 +0100 Wei Chuang wrote:
> On Mon, Nov 14, 2022 at 8:03 AM Alessandro Vesely wrote:
> >> BTW, we all know that mailing lists send one message at a time, do
On Mon 14/Nov/2022 18:54:33 +0100 Wei Chuang wrote:
On Mon, Nov 14, 2022 at 8:03 AM Alessandro Vesely wrote:
BTW, we all know that mailing lists send one message at a time, doing
VERP for each subscriber. They can more easily include the recipient in
the ARC signature. However, any spammer
On Mon 14/Nov/2022 05:50:42 +0100 Roland Turner wrote:
I'd point out that all but one of those things is either redundant (vs. say
ARC), unacceptably harmful (we use DKIM *in the first place* to facilitate
forwarding outside of the domain-registrant/sender's control), or both.
+1, Scott is
On Mon 14/Nov/2022 01:26:29 +0100 Scott Kitterman wrote:
Because of DKIM’s broad deployment, compatibility with existing
deployments will be a critical factor, and it is unlikely that proposals
that lack compatibility will proceed to publication.
Is compatibility with DKIM sufficient for
On Sat 12/Nov/2022 19:46:13 +0100 Wei Chuang wrote:
On Fri, Nov 11, 2022 at 9:31 PM Scott Kitterman wrote:
On Friday, November 11, 2022 5:18:57 PM EST Wei Chuang wrote:
> On Thu, Nov 10, 2022 at 4:42 AM Scott Kitterman wrote:
If a domain is signing spam and their reputation suffers as a
On Fri 11/Nov/2022 12:42:26 +0100 Laura Atkins wrote:
On 11 Nov 2022, at 11:33, Alessandro Vesely wrote:
On Fri 11/Nov/2022 10:23:44 +0100 Laura Atkins wrote:
On 11 Nov 2022, at 05:04, Scott Kitterman wrote:
[...]
For those that have been around for awhile this reminds me of the now long
On Thu 10/Nov/2022 14:32:16 +0100 Steve Atkins wrote:
The other (more common?) case is that the original recipient is in the signed
822.To, while the new recipient is not in the To: or Cc: headers at all. While
that’s just the same as old-school alias forwarding, and you might not be able
to
On Wed 09/Nov/2022 13:08:15 +0100 Barry Leiba wrote:
[...]
Current proposals include the following drafts:
- draft-bradshaw-envelope-validation-extension-dkim
- draft-chuang-replay-resistant-arc
- draft-gondwana-email-mailpath
- draft-kucherawy-dkim-anti-replay
The working group will
On Tue 04/Oct/2022 02:01:12 +0200 Scott Kitterman wrote:
Many normal email operations seem difficult to distinguish from the case you
are trying to address. Signing fields in the envelope may be enough to break
replaying, although it would have other negative consequences.
Scott is right.
On Thu 25/Aug/2022 01:36:21 +0200 Wei Chuang wrote:
On Tue, Aug 23, 2022 at 11:07 AM Alessandro Vesely wrote:
On Mon 22/Aug/2022 23:53:16 +0200 Wei Chuang wrote:
All the while, using ARC as a framework may allow future support
for another long standing issue, which is working on message
On Mon 22/Aug/2022 23:53:16 +0200 Wei Chuang wrote:
All the while, using ARC as a framework may allow future support for
another long standing issue, which is working on message modification while
forwarding, in particular for mailing lists. The proposal
draft-kucherawy-dkim-list-canon-01
On Wed 01/Dec/2021 15:00:36 +0100 Dave Crocker wrote:
On 12/1/2021 5:05 AM, Barry Leiba wrote:
The original text says exactly what it was intended to say, and is not
in error. This is a suggestion for a change, not an errata report,
The reason to call it an error is that if a reader
On 2020-08-07 5:53 a.m., Mark Delany wrote:
> On 06Aug20, Dave Crocker allegedly wrote:
>> M3AAWG DKIM Key Rotation Best Common Practices
>> (revised March 2019)
>>
>> https://www.m3aawg.org/DKIMKeyRotation
>
> Luckily the tl;dr is in the first line. Phew! Quite the read :-)
Section 5.1.3
On Wed 13/May/2020 08:03:27 +0200 Murray S. Kucherawy wrote:
> On Tue, May 12, 2020 at 11:14 AM Alessandro Vesely wrote:
>> On Tue 12/May/2020 19:09:55 +0200 Murray S. Kucherawy wrote:
>>> On Tue, May 12, 2020 at 9:30 AM Alessandro Vesely wrote:
>>>> On Tue 12/Ma
On Tue 12/May/2020 19:09:55 +0200 Murray S. Kucherawy wrote:
> On Tue, May 12, 2020 at 9:30 AM Alessandro Vesely wrote:
>> On Tue 12/May/2020 17:48:38 +0200 Murray S. Kucherawy wrote:
>>> On Tue, May 12, 2020 at 1:20 AM Alessandro Vesely wrote:
>>>> On Mon 11/Ma
On Tue 12/May/2020 17:48:38 +0200 Murray S. Kucherawy wrote:
> On Tue, May 12, 2020 at 1:20 AM Alessandro Vesely wrote:
>> On Mon 11/May/2020 20:23:12 +0200 Murray S. Kucherawy wrote:
>>> Indeed; why would I believe what any given domain claims in this tag?
>>
>> If
On Tue 12/May/2020 00:08:15 +0200 Dave Crocker wrote:
> On 5/11/2020 1:33 PM, Jim Fenton wrote:
>
>> There might also be the situation where a domain wants to delegate a key
>
> Hence my suggestion that figuring out such details is where discussion could
> get interesting, if only because people
Hi all,
consider the famous incipit:
DomainKeys Identified Mail (DKIM) permits a person, role, or
organization to claim some responsibility for a message by
associating a domain name [RFC1034] with the message [RFC5322], which
they are authorized to use.
The question is, what
On Mon 17/Dec/2018 19:18:58 +0100 Fazzina, Angelo wrote:
> Sounds like my testing method may be flawed. L
There are a number of sites for testing DKIM, for example:
sa-t...@sendmail.net
check-a...@verifier.port25.com
autorespond+d...@dk.elandsys.com
Hi!
On Fri 17/Aug/2018 23:48:34 +0200 Dilyan Palauzov wrote:
>
> I cannot provide very useful experience:
Thank you for the overview. Albeit low-volume, it confirms my feeling that
rfc6651 is not widely adopted.
> [...]
> - state explicitly that providers who want reports about mismatched
>
On Sat 18/Aug/2018 23:45:40 +0200 Murray S. Kucherawy wrote:
>
> OpenDKIM still implements RFC6651 and finds it useful for debugging
> problems with new implementations, so at least from that perspective I
> don't think historical status for it is warranted. If an update is needed
> to cover the
Hi all!
On Sat 11/Aug/2018 05:38:40 +0200 Dilyan Palauzov wrote:
>
> RFC6651 (Extensions to DomainKeys Identified Mail (DKIM) for Failure
> Reporting)
> adds to DKIM-Signature the couple r=y - when an existing DKIM-Signature does
> not validate, the signing server is notified that something
On Wed 02/Oct/2013 16:52:38 +0200 John Levine wrote:
The IESG has received a request from an individual participant to make
the following status changes:
- RFC5617 from Proposed Standard to Historic
The supporting document for this request can be found here:
On Tue 20/Aug/2013 07:27:12 +0200 David Conrad wrote:
On Aug 19, 2013, at 10:14 PM, Randy Bush ra...@psg.com wrote:
one lesson i might take from this is, if i want to deploy a new
hack which needs an rrtype, not to use txt in the interim.
Nor the same format, IMHO.
My personal belief is
On Tue 30/Apr/2013 20:02:11 +0200 Edward Lewis wrote:
On Apr 30, 2013, at 12:28, Alessandro Vesely wrote:
...The basic fact that killed the SPF type is the ability to use
TXT as a replacement. There must be an analogous of Gresham's
law: Bad types drive out good ones.
I disagree
On Wed 01/May/2013 03:04:52 +0200 Mark Andrews wrote:
In message 517ff144.5040...@tana.it, Alessandro Vesely writes:
On Tue 30/Apr/2013 01:07:42 +0200 Mark Andrews wrote:
SPF is techically superior to TXT is lots of ways.
[...]
For TXT you need to lookup the existing RRset, extract
On Mon 29/Apr/2013 05:14:50 +0200 John Levine wrote:
The Patently-O blog has a new guest post by Jorge Contreras, who among
other things is the IETF's lawyer, on a recent court decision about
how to determine what's an appropriate RAND royalty rate for
standard-essential patents. The patents
On Tue 30/Apr/2013 21:54:11 +0200 David Conrad wrote:
On Apr 30, 2013, at 11:12 AM, Dave Crocker d...@dcrocker.net wrote:
What is the IETF-approved timeframe in which the market is
allowed to accept/reject a particular technology?
I've no idea what the lower limit is or should be, but I'm
On Tue 30/Apr/2013 19:11:15 +0200 Doug Barton wrote:
On 04/30/2013 09:28 AM, Alessandro Vesely wrote:
While it's too late for SPF, we can learn this lesson.
As has been repeatedly pointed out in the discussion on both dnsext
and spfbis, it is NOT too late for SPF. The way forward is simple
On Tue 30/Apr/2013 01:07:42 +0200 Mark Andrews wrote:
The really annoying thing is that SPF is techically superior
to TXT is lots of ways.
1. It uniquely identifies the roll of the record.
2. As SPF records are singletons you don't need to identify
and
1 - 100 of 195 matches
Mail list logo
