On Thu, May 23, 2024 at 11:13 AM John Levine wrote:
> On the other hand, I see that the perl and python DKIM modules sign
> the MIME Content-* headers by default. Do you remember what opendkim
> does? A quick look at the code wasn't too enlightening.
>
It signs them all unless you configure it
On Thu, May 23, 2024 at 7:44 AM Wei Chuang wrote:
> Just specifically in regards authenticating mailing list modifications:
> fair enough that the ideas should be implemented first before any sort of
> IETF publication for it. Still there ought to be a place for informal,
> early discussion of
On Tue, May 21, 2024 at 10:05 AM Jim Fenton wrote:
> One thing that hasn’t been clear to me:
>
> On 21 May 2024, at 9:48, Murray S. Kucherawy wrote:
>
> > * Prior to accepting any Standards Track document for development, there
> must
> > be a commitment to imple
. The
only constraint being established is: If you want this particular working
group to process your work, there's a specific minimum you need to meet.
On Sun, May 19, 2024 at 7:22 PM Dave Crocker wrote:
> On 5/10/2024 2:33 PM, Dave Crocker wrote:
>
> On 5/10/2024 10:54 AM, Murray S. Kucher
On Sun, May 19, 2024 at 9:27 AM Wei Chuang wrote:
> As many of you know there was a DKIM security vulnerability disclosure
> Friday around the signature header body length tag "l=". The blog post is
> here: https://www.zone.eu/blog/2024/05/17/bimi-and-dmarc-cant-save-you/
> The authors state
FYI
-- Forwarded message -
From: IESG Secretary
Date: Thu, May 9, 2024 at 1:01 PM
Subject: WG Action: Formed Mail Maintenance (mailmaint)
To: IETF Announcement List
Cc: , ,
A new IETF WG has been formed in the Applications and Real-Time Area. For
additional information,
On Mon, Mar 11, 2024 at 2:04 PM David Harris
wrote:
> Thank you for taking the time to answer my questions - most appreciated.
>
> Your answer has addressed questions 1 and 2 for me. I'm still unclear on
> certain aspects of question 3, though:
>
> [...]
>
> The pseudocode for "sig-alg" says:
>
On Mon, Mar 11, 2024 at 6:50 AM David Harris
wrote:
> Question 1:
>
> My first question is the exact meaning of this piece of pseudocode:
>
>body-hash= hash-alg (canon-body, l-param)
>
> Does this mean:
>
> 1: Pass the canonicalized body to the hash algorithm, then pass the value
> of
On Thu, Mar 7, 2024 at 1:05 PM A. Schulze wrote:
> I enabled double signing years ago on my personal domain and last year at
> an medium scale ESP.
> So far, we didn't noticed negative effects.
> Intentionally I removed SPF on my personal domain last year, also without
> any delivery issues.
>
>
On Mon, Feb 5, 2024 at 1:39 PM Steffen Nurpmeso wrote:
> If a graphical user interface gives you a green "ok" button to
> click, or "red" otherwise, that is even better as in browser URL
> lines. Then pop up a tree-view of message modifications and
> alertize where it broke, checkbox for
On Mon, Feb 5, 2024 at 8:50 AM Dave Crocker wrote:
> OpenDKIM will not sign a message that fails basic RFC5322 header checks
> (e.g., "From" or "Date" is missing), but will place an
> Authentication-Results field indicating the message is malformed. At some
> point, though, someone talked me
On Sat, Feb 3, 2024 at 1:54 PM John R Levine wrote:
>
> > It also optionally does LF to CRLF translation. I'm fairly certain this
> is
> > to accommodate local/human SMTP injections since humans can't be expected
> > to type CRLFs when entering manual tests from a shell. ...
>
> Unix MTAs strip
On Sat, Feb 3, 2024 at 5:40 AM Dave Crocker wrote:
> Having a DKIM module check for one aspect of RFC5322 conformance -- raises
> a need to make it a full RFC5322 compliance engine.
>
> If it doesn't, then the attention to compliance is a random walk through
> whatever concerns are fashionable
On Thu, Feb 1, 2024 at 10:03 AM John Levine wrote:
> It appears that Murray S. Kucherawy said:
> >-=-=-=-=-=-
> >
> >On Wed, Jan 31, 2024 at 5:44 PM Steffen Nurpmeso
> wrote:
> >
> >> But i cannot read this from RFC 6376.
> >
> >Secti
On Wed, Jan 31, 2024 at 5:44 PM Steffen Nurpmeso wrote:
> But i cannot read this from RFC 6376.
>
Sections 2.8 and 3.4.4 don't answer this?
-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
On Wed, Jan 31, 2024 at 9:35 AM Hector Santos wrote:
> First time I have come across the term (“oversign”) and it appears to be
> a feature with several products in the market. But checking the RFC, unless
> I missed it, it’s not a RFC defined term. Replay is the term used.
>
You won't find
Hi all, welcome back from the holidays.
It's been about ten weeks since Laura posted about the status of the WG,
and a final plea was made for energy and activity. Since then, despite a
handful of people expressing interest at the M3AAWG meeting in Brooklyn,
there has been no activity of any
On Sun, Oct 1, 2023 at 1:50 AM Jan Dušátko
wrote:
> I would like to ask to consider the possibility of defining a DKIM
> signature using Ed448. [...]
Which DKIM implementations are known to be willing to support this if it
were added?
ED25519 support was added by a working group called DCRUP.
On Fri, Oct 27, 2023 at 6:33 AM
wrote:
> Appreciate all the work and effort you’ve put into this. I would like to
> help out as much as I can. I know Monitoring isn’t part of this from IETF
> POV, however, I think it’s something that is important and I will bring
> this up on the M3AAWG side.
>
I'm betting the chairs would want this not to consume any of the
so-far-meager energy this WG is showing. I can imagine that ietf-smtp
would be a reasonable place to at least announce that you're working on
this. I don't know that that's a good home for ongoing discussion either
though.
We
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 attacker.
>
>
> Has anyone (else) implemented it?
>
>
> That's what I want to understand. Or, more specifically, if no
On Thu, Sep 7, 2023 at 9:38 PM 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 attacker.
>
Has anyone (else) implemented it?
-MSK
___
Ietf-dkim mailing list
On Thu, Sep 7, 2023 at 3:15 PM Evan Burke wrote:
> To be clear, for us x= was one of the most effective defenses against
> large-scale replay attacks. Not perfect, obviously, but applied carefully
> and in conjunction with header oversigning, it created a significantly
> narrower window for
On Thu, Sep 7, 2023 at 10:03 AM Dave Crocker wrote:
>
> The "new header field" (or similar) approach alone would not open any
> doors for revocation/invalidation of the fact that the signature was
> applied on that first single message. Relying solely on fast key
> rotation/invalidation would
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 it does not provide the affirmative
On Tue, Aug 29, 2023 at 11:10 AM Dave Crocker wrote:
> Two thoughts:
>
>1. If the substance of the message should fail a quality assessment,
>why does it pass at the outbound (sending) site?
>2. If the problem is reasonable content, but sent to many unintended
>(or, rather,
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 to believe that people understand what it means to sign something,
>
On Wed, Aug 16, 2023 at 11:19 AM Dave Crocker wrote:
> On 8/16/2023 10:48 AM, Murray S. Kucherawy wrote:
> > Yet, an open
> > signer is for DKIM the equivalent of what an open relay is for SPF.
>
> It is nothing of the sort.
>
> [...]
>
For the record,
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 2023, at 09:57, Alessandro Vesely wrote:
>
On Sun, Aug 13, 2023 at 8:34 PM Jesse Thompson wrote:
> If I understand based on my limited view of history, DKIM was designed for
> authentication between two hops. Signature survival across intermediaries
> was only achievable by encouraging intermediaries to not make any changes
> to the
On Sat, Aug 12, 2023 at 12:31 PM Steffen Nurpmeso
wrote:
> |> The aspect of DKIM-subsignatures revealing Bcc: presence (of 1+
> |> recipients of a domain) if a Bcc: recipient replies to a message
> |> that Murray Kucherawy adduced i obviously have not fully addressed
> |> with my response.
>
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 header, and that will be
> covered by a further DKIM signature.
>
Aren't you
On Wed, Aug 9, 2023 at 9:07 AM Steffen Nurpmeso wrote:
> All these problems are long known to (and "solved" by) the OpenPGP
> (and S/MIME) communities, no?
> In OpenPGP you can either encrypt-to a single or many recipients.
> (With at least GnuPG you can also "hide" those recipients:
>
>
On Wed, Aug 9, 2023 at 2:54 AM Laura Atkins wrote:
> If there are multiple BCCs that implies that whatever is creating the mail
> must make individual copies of the message with only the BCC recipient in
> that line before it’s signed with DKIM. So for a message with 3 BCCs, there
> are 4
On Wed, Aug 9, 2023 at 2:54 AM Laura Atkins wrote:
> It seems to me there is a lot of heavy lifting to be done to make sure
> that the individual recipient only sees a copy of the message with their
> address in the BCC header.
>
> If there are multiple BCCs that implies that whatever is
On Tue, Aug 8, 2023 at 8:21 PM Jesse Thompson wrote:
>
> As you cited, RFC 5322 describes three ways that the "Bcc" field is
> typically used. You're talking about just one of those, and I'm not sure
> it's the most common one. In any case, I suggest that "should" is a bit of
> a leap,
On Tue, Aug 8, 2023 at 9:25 AM Alessandro Vesely wrote:
> On Tue 08/Aug/2023 14:47:37 +0000 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
&
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 the description in the document is
accurate.
-MSK
On Tue, Aug 8, 2023 at 2:16 AM Alessandro Vesely wrote:
> 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
>
On Mon, Aug 7, 2023 at 9:23 PM Jesse Thompson wrote:
> On Mon, Aug 7, 2023, at 10:54 PM, Murray S. Kucherawy wrote:
>
> On Mon, Aug 7, 2023 at 8:00 PM Emanuel Schorsch 40google@dmarc.ietf.org> wrote:
>
> If there are not that many BCC recipients for a message
On Mon, Aug 7, 2023 at 8:00 PM Emanuel Schorsch wrote:
> If there are not that many BCC recipients for a message then it is likely
> not necessary as the duplicate message counting is unlikely to have a
> negative impact. If there are a large number of BCC recipients for a given
> message then I
On Mon, Aug 7, 2023 at 7:43 PM Jesse Thompson wrote:
> Similar to what Emmanuel is saying about detecting SPF/DKIM zone
> misalignment, the solution to DKIM replay is for receivers to maintain some
> state and feed it into bespoke replay detection algorithms. If all
> receivers can maintain this
On Mon, Aug 7, 2023 at 3:58 PM Scott Kitterman
wrote:
> On Monday, August 7, 2023 6:53:19 PM EDT Murray S. Kucherawy wrote:
> ...
> > (2) Throughout the document, the proper term "Replay Attack" (and
> sometimes
> > "Replay") is used, but it's never di
Hi,
Some comments after a review of the adopted document:
(1) I find the abstract is more readable if broken into three paragraphs,
with the second starting "DKIM survives ..." and the third "This document
discusses ...".
(2) Throughout the document, the proper term "Replay Attack" (and
On Fri, Aug 4, 2023 at 2:46 PM Michael Thomas wrote:
> Well, for starters ARC doesn't have broad deployment. But the author
> doesn't say why ARC is needed or relevant. That is the point here. *All*
> changes need to be justified including any imported mechanisms. The less
> rat holes the
Colleagues,
On Fri, Aug 4, 2023 at 12:08 PM Michael Thomas wrote:
> Exactly. Any proposed modifications to DKIM should be based on DKIM
> itself. Anything else is off-topic. It's not like you can't propose the
> ARC modifications to DKIM in terms of DKIM itself, though all of those
>
On Thu, Aug 3, 2023 at 10:01 AM Suresh Ramasubramanian
wrote:
> Would this effort be better targeted at the various open source as well as
> proprietary implementations of DKIM libraries, to flag if not eliminate the
> various edge cases that are being gamed by the spammers?
>
>
>
> Rolling out
On Tue, Aug 1, 2023 at 8:29 AM Laura Atkins wrote:
> We have a current version of the draft problem statement available on the
> data tracker. Murray and a few others made a few comments that were added
> in the -03 version.
>
>
>
On Tue, May 16, 2023 at 7:00 AM Jan Dušátko wrote:
> 1) At this moment, the use of the tag "v=DKIM1;" is only RECOMMENDED and
> if this tag is used, it must be the first. Unlike, for example, SPF and
> DMARC, this is not a REQUIRED (MANDATORY) record. In case of an attempt
> to identify DKIM
On Mon, Apr 10, 2023 at 11:24 AM Scott Kitterman
wrote:
> On Monday, April 10, 2023 2:05:28 PM EDT Laura Atkins wrote:
> ...
> > There is currently an active Call for Adoption for a draft.
> ...
>
> What's the plan for closing this out? I haven't seen any objections to
> the
> idea and as of
Colleagues,
Things have gotten somewhat heated in here. I think we need to take a step
back.
While I have no doubts whatsoever that the participants and chairs are
well-intentioned and would like to see this working group make progress in
an appropriate direction, even if we may not all agree
On Tue, Mar 28, 2023 at 1:05 AM Michael Thomas wrote:
> Lastly: cutting off debate because of time is bogus. Murray already said
> that the milestone dates were fairly arbitrary. Using them as a tool to
> get the chair's preferred result is... disingenuous.
>
The milestones are negotiable, but
On Sat, Mar 25, 2023 at 10:29 AM Michael Thomas wrote:
> On 3/24/23 6:19 PM, Barry Leiba wrote:
> > I don't agree with the premise. I think what was tried and didn't
> > work should be documented in the result that the working group comes
> > out with, but not in the problem statement.
>
>
On Fri, Mar 24, 2023, 10:10 Michael Thomas wrote:
> On 3/24/23 9:58 AM, Laura Atkins wrote:
>
>
> On 24 Mar 2023, at 16:48, Michael Thomas
> wrote:
>
>
> On 3/24/23 6:14 AM, Laura Atkins wrote:
>
> Please, let’s focus on the current issue with is addressing and refining
> the problem
On Fri, Mar 24, 2023 at 9:59 AM Dave Crocker wrote:
> On 3/24/2023 9:38 AM, Murray S. Kucherawy wrote:
> > I think I concur with the suggestion that wa should drop discussion of
> > ARC. This WG, or the DMARC WG, can develop an update to ARC based on
> > the outcome
Informal comments only here. I know a merger with Dave's draft is in
progress, so some of these may not apply by the time you're done.
Section 1.1:
It feels a little presumptuous to assume any DKIM receiver has also built
out a reputation system, or has access to one. I guess it might depend
On Sun, Mar 19, 2023 at 11:04 PM 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
>
On Tue, Mar 21, 2023 at 8:37 PM Scott Kitterman
wrote:
>
> >>1. Do receivers keep tabs on which users are using things like
> >>mailing lists to differentiate users who expect to get indirect mail
> vs
> >>those who don't?
> >>
> >> The large mailbox operators might have hints about
There was one prior answer to this. Here's another.
There's a claim here that the problem statement(s) is/are too vague. I'm a
little worried that tightening up the problem definition along these 20
vectors will give us such a tight problem statement that any solution is so
targeted as to be of
On Fri, Mar 10, 2023 at 11:19 AM Michael Thomas wrote:
> On 3/10/23 7:46 AM, Laura Atkins wrote:
>
>
> On 10 Mar 2023, at 00:30, Michael Thomas
> wrote:
>
> Now that we have a chair, I have a question about process wrt to the
> charter. The charter states that either the working group will
On Fri, Mar 10, 2023 at 10:48 AM Jan Dušátko wrote:
> I got recommendation to propose changes in that mailing group.
> My work depend on appropriate protection of our brand, however this
> tasks require also management of records required for that protection.
> We have huge problem with
On Sun, Feb 19, 2023 at 11:49 AM Dave Crocker wrote:
> This is a very basic point about protocols vs. implementations. A
> protocol defines the 4 walls of its sandbox. It owns that sandbox and
> defines whatever it needs to, within the confines of that space.
>
> [...]
>
> But again, this is
On Sat, Feb 18, 2023 at 8:27 PM Michael Thomas wrote:
>
>
>> Beyond this SHOULD, I think we need to consider whether the caller needs
>> to be told specifically when a failure occurs for this reason. Right now
>> an implementation might return just a PERMFAIL without noting that it's
>> because
On Sat, Feb 18, 2023 at 12:10 PM Michael Thomas wrote:
>
>
> Beyond this SHOULD, I think we need to consider whether the caller needs
> to be told specifically when a failure occurs for this reason. Right now
> an implementation might return just a PERMFAIL without noting that it's
> because of
On Fri, Feb 17, 2023 at 9:35 AM Scott Kitterman
wrote:
> Currently RFC 6376 says, "Signatures MAY be considered invalid". I think
> the practical effect as described in protocol terms would be to change the
> MAY to SHOULD under X conditions and SHOULD NOT under !X conditions. Not
> that I'd
On Thu, Feb 16, 2023 at 2:13 PM Barry Leiba wrote:
> I like this approach: if the issue is that an "expired" signature is
> treated as unsigned, I think we have an unacceptable level of false
> positives. But if the fact that a signature is valid but expired is
> simply another factor in the
On Wed, Feb 15, 2023 at 10:49 PM Evan Burke
wrote:
>
>> I don't think we're saying different things. I remember the point of the
>> answer I got in that session being that most, but not all, implementations
>> check or enforce signature expiration. But that means if "x=" is the
>> solution we
On Wed, Feb 15, 2023 at 2:21 PM Michael Thomas wrote:
>
> There's also the question of whether "x=" is properly enforced. RFC 6376
> says verifiers "MAY" choose to enforce it. I think I asked about this at a
> conference recently and was told that it's not universally supported by
>
On Wed, Feb 15, 2023 at 5:39 AM Scott Kitterman
wrote:
> Any reputation based solution does have down scale limits. Small mail
> sources
> (such as your random Nebraska forwarder) generally will have no reputation
> vice a negative one and so wouldn't get penalized in a scheme like the one
> I
On Tue, Feb 14, 2023 at 11:44 AM Michael Thomas wrote:
> At maximum, isn't it just the x= value? It seems to me that if you don't
> specify an x= value, or it's essentially infinite, they are saying they
> don't care about "replays". Which is fine in most cases and you can just
> ignore it.
On Tue, Feb 14, 2023 at 11:18 AM Michael Thomas wrote:
> Have you considered something like rate limiting on the receiver side for
> things with duplicate msg-id's? Aka, a tar pit, iirc?
>
As I recall that technique is sometimes not suggested because (a) we can't
come up with good advice about
On Sun, Feb 12, 2023 at 11:19 AM Michael Thomas wrote:
>
> It's certainly possible to collect data that might correlate something
> like "Subject signed vs. not signed" with a spam score, and that could feed
> in to a best practices document. I don't know who might be up for
> investing the
On Sun, Feb 12, 2023 at 12:16 PM Dave Crocker wrote:
> There appears to be no perfect way to distinguish a Replay attack from a
> legitimate re-posting by an Alias or even a Mailing list (that preserves
> the original DKIM signature.)
>
> The only 'signal' that is valid, also is ambiguous. The
On Sun, Feb 12, 2023 at 1:21 PM Dave Crocker wrote:
> One of the continuing problems with anti-abuse discussions is that
> discussion always goes to detecting bad actors. While of course there need
> to be discussions about them, the problem is that there seem to be no
> discussions about good
On Fri, Feb 10, 2023 at 2:13 PM Michael Thomas wrote:
> Another thing that should probably be discussed is outbound spam
> filtering. At a high level, this is really about the sender sending spam.
> But email afaik is silent on whether senders or receivers should filter for
> spam (and if there
On Sat, Feb 11, 2023 at 2:35 PM Michael Thomas wrote:
> It's never been especially clear to me whether deployments do their
> filtering up front, ie at the MX, or farther down the line. There are
> certainly advantages to do it right at the MX with less burden on using AR
> to signal all of what
On Sat, Feb 11, 2023 at 4:48 PM Stephen Farrell
wrote:
> FWIW, as this discussion has a bit of a flavour of one person
> arguing with a bigger bunch of people, I'd like to say that
> Mike is asking good questions that deserve consideration.
>
Have they not been getting consideration? I know
On Fri, Feb 10, 2023 at 12:06 PM Evan Burke wrote:
>
> On Fri, Feb 10, 2023 at 11:47 AM Dave Crocker wrote:
>
>> On 2/10/2023 11:35 AM, Wei Chuang wrote:
>> > ARC is a tool to help support modern Indirect Mail Flows, and I
>> > believe belongs in the solution space to be explored.
>>
>> Since
On Fri, Feb 10, 2023 at 8:09 PM Michael Thomas wrote:
> I've always thought that the likelihood of a protocol level solution for
> this issue is pretty close to zero if not zero. The various proposed
> solutions in the problem draft haven't given me any reason to dissuade
> me of that notion.
>
On Sat, Feb 4, 2023 at 11:11 AM Michael Thomas wrote:
> There are architectural ramifications regardless of whether it's mandatory
> or not. It would be a lot more reassuring if this were a common and
> accepted practice. I don't know the answer to that. If it's uncommon, there
> needs to be
On Thu, Feb 2, 2023 at 3:26 PM Michael Thomas wrote:
> I guess my concern is more along the lines of what solutions *aren't*.
> There are a bunch of drafts trying to tie the envelope to the email and I
> think there needs to be a meta discussion of whether that is a good idea or
> not in
On Fri, Feb 3, 2023 at 5:14 PM Michael Thomas wrote:
> That said, I don't know why we didn't make To:, Cc: and Subject:
> mandatory signed fields. But even if it's not mandatory, that should be
> a signal that the message should be given increased scrutiny.
>
RFC 4871 included those as SHOULD
Colleagues,
The IESG is prepared to approve the charter overall. There was one
blocking point about publishing the problem statement, which is that the
IESG would like that not to be a "maybe". I think that's a reasonable
change to make.
There is also the fact that I have not secured
On Tue, Jan 31, 2023 at 2:12 PM Michael Thomas wrote:
> Also: the date on the problem statement seems awfully aggressive. My
> thinking is that the problem statement should at least discuss (as is
> mentioned in the charter) how "replays" are completely legitimate uses
> of DKIM, and thus limit
On Mon, Jan 9, 2023 at 12:57 AM Alessandro Vesely wrote:
> 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.
> >
On Sat, Dec 31, 2022 at 3:02 PM Murray S. Kucherawy
wrote:
> On Sat, Dec 31, 2022 at 2:43 PM Dave Crocker wrote:
>
>> The initial effort to form a working group in the IETF was pretty casual
>> and surfaced a lack of sufficient consensus among advocates. The IETF
>> sa
On Sat, Dec 31, 2022 at 2:43 PM Dave Crocker wrote:
> The initial effort to form a working group in the IETF was pretty casual
> and surfaced a lack of sufficient consensus among advocates. The IETF
> said go away until there's more agreement.
>
> We went away for a year, during which we
On Sat, Dec 31, 2022 at 1:09 PM Michael Thomas wrote:
>
> On 12/29/22 7:20 PM, Murray S. Kucherawy wrote:
>
> On Sun, Dec 25, 2022 at 4:14 PM Michael Thomas wrote:
>
>>
>>
>> Done, and thanks for that text.
>>
>> One nit, Barry's text should be above
On Sun, Dec 25, 2022 at 4:14 PM Michael Thomas wrote:
>
>
> Done, and thanks for that text.
>
> One nit, Barry's text should be above the proposals not below. It makes it
> look like those are the only proposals on the table which I'm nearly
> certain is not your intent.
>
One other thing
On Sun, Dec 25, 2022 at 6:31 AM Barry Leiba wrote:
> I agree with Mike and Scott on the point that it’s worth explicitly
> allowing the result to be a “can’t do it” publication. Implicit “couldn’t
> do it” is fine in most cases, but here we might say something like, “If the
> working group
On Sat, Dec 24, 2022 at 9:12 PM Michael Deutschmann
wrote:
> On Mon, 12 Dec 2022, you wrote:
> > > Blind-carbon-copy is already a sign of spam.
> >
> > Except when it's not, like this very mailing list.
>
> Only if you don't whitelist *all* forwarders you set up and mailing lists
> you have
On Fri, Dec 23, 2022 at 1:17 PM Michael Thomas wrote:
> Shouldn't the problem statement explore whether there is a plausible
> tractable solution before it moves on to protocol work? That is, if there
> isn't a tractable solution the wg should go into hibernation again. I'm
> pretty sure that I
On Sun, Dec 11, 2022 at 7:25 PM Murray S. Kucherawy
wrote:
>
> I've synthesized the feedback to date into a new update to the charter
> text. It calls out the order of operations the group seems to prefer, and
> makes explicit the possible output of a "best practices"
On Tue, Dec 13, 2022 at 5:00 PM Michael Thomas wrote:
> On 12/13/22 6:35 AM, Murray S. Kucherawy wrote:
>
>
> This tactic appears to me to have three problems: (1) negative reputations
> are of little value to receivers, because attackers can easily shed them;
> (2) if
On Tue, Dec 13, 2022 at 2:54 AM Alessandro Vesely wrote:
> Perhaps they could devise better methods than asking _accountable? (Y/N)_
> on a
> questionnaire. Linking to bank accounts is an example.
>
Would you link a free email account to your bank account for any reason? I
don't think I
On Mon, Dec 12, 2022 at 5:03 PM Michael Thomas wrote:
> Note that in both cases it requires the good will of the receiver (or
> client in the web case). We already have the equivalent of expired certs
> with the x= option. If senders are concerned about this, there is
> already solution in the
On Sun, Dec 11, 2022 at 2:43 PM Michael Thomas wrote:
> But I want to return to my previous point of whether reputation is even
> quantifiable, and whether somebody has actually gone out and researched it.
> We can say that this is a problem in theory, but do we have any data to
> back it up? I
On Mon, Dec 12, 2022 at 1:13 AM Alessandro Vesely wrote:
> > The alternative is to say: Well, if you can't make at least one of those
> > two quantities bulletproof, then don't sign your mail. That, though,
> > sounds a lot to me like tossing DKIM in the bin.
>
> On the opposite, if Gmail
On Thu, Dec 8, 2022 at 11:52 AM Jim Fenton wrote:
>
> >> I think a checkpoint / review is a good goal for the group.
> >>
> >
> > This seems like something reasonable and easy to add.
> >
> > Any objections?
>
> I’m fine if the revision to best practices is scoped to the replay
> problem. This
is (currently, at least) decoupled from the envelope, I
think we're also taking across layers here.
-MSK
On Sun, Dec 11, 2022, 14:46 Michael Deutschmann wrote:
> On Sun, 11 Dec 2022, Murray S. Kucherawy wrote:
> > Then from that other account I can spray it to as many recipients as I
> &g
1 - 100 of 307 matches
Mail list logo
