On Thu, Nov 7, 2024 at 4:26 PM Franck Martin wrote:
> A last nit, many standardized on opendkim, because of interoperability.
> There were too many weird things happening between different
> implementations of DKIM1. I don’t know if interoperability should be better
> addressed (better debugging,
On Thu, Nov 7, 2024 at 12:27 AM Bron Gondwana wrote:
> We have a draft charter here:
> https://notes.ietf.org/YGynIPpYS7yqg5G7ZeSQeA
>
I've loaded that text into the datatracker for DKIM, and move it to "Draft
Charter" state:
https://datatracker.ietf.org/doc/charter-ietf-dkim/
Comments from peo
On Sat, Aug 17, 2024 at 3:05 PM Steffen Nurpmeso wrote:
> Since then myriads of possibilities have been added to generate
> "more identification value" of an email's source, even "over the
> corner", and what not.
>
Myriads? Which ones are those?
> |indirect mail flows. I think you'd need t
On Sun, Aug 18, 2024 at 10:18 PM Jan Dušátko wrote:
> I would like to correct to the "signed part of message is unchanged",
> because of problematic length tag in DKIM-Signature header.
>
Are you observing widespread use of "l="? I seem to recall it had almost
completely fallen out of use.
As
On Sat, Aug 17, 2024 at 12:36 PM Steffen Nurpmeso
wrote:
> |> Instead there should be a (yet another) DNS entry that notifies
> |> whether a host DKIM-signs its emails, or not.
> |> Then receivers can peek that state.
> |> This idea in several forms was posted here in the past, without
> |>
On Fri, Aug 16, 2024 at 3:14 PM Steffen Nurpmeso wrote:
> Instead there should be a (yet another) DNS entry that notifies
> whether a host DKIM-signs its emails, or not.
> Then receivers can peek that state.
> This idea in several forms was posted here in the past, without
> responses.
>
Why do
On Thu, May 30, 2024 at 9:13 AM Alessandro Vesely wrote:
> z= saves all fields, which would be too much in most cases. Moreover,
> doing so
> suggests treating all fields as a whole, rather than dealing with each
> one's
> peculiarity.
>
That's not what the RFC says.
Of course, if an Original-
On Thu, May 30, 2024 at 3:30 AM Alessandro Vesely wrote:
> z= is a valuable tool for debugging and learning why signatures fail. For
> reversing purposes, instead, Original-* fields are preferable as they can
> be
> individually added and possibly signed also by different operators.
> Reversal
>
On Wed, May 29, 2024 at 11:09 AM Alessandro Vesely wrote:
> On Wed 29/May/2024 19:29:27 +0200 John Levine wrote:
> > It appears that Alessandro Vesely said:
> >>My verifier, in particular, works every time on my messages. It doesn't
> mean
> >>it doesn't work at scale.
> >
> > Nor, of course,
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 t
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 i
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
ing group. 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
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 that
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, please
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 is-this
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 int
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 a
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.
> >
> >Sections 2.8
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 it
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 kind
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.
>
On Thu, Oct 26, 2023 at 12:03 PM Wei Chuang wrote:
> I was there at M3AAWG and concur with the chair's observations. I should
> also note I was part of the group who proposed restarting the DKIM WG at
> Dispatch IETF-115. My hope back then was that solving DKIM replay
> systematically could be
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 don't
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 one
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 attac
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 mea
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 informatio
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, undecl
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,
> and
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, the attrib
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:
> H
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 messa
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 basically
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 separat
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 creating
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, especial
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 distin
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 then
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 nev
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 sometime
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 better.
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
> modificatio
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 s
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.
>
>
> https://mailarchive.ietf.org/arch/msg/ietf-dkim/Q5ybHiYkMlg5QFaFp2
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 reco
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 tom
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 ye
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 i
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.
>
> There
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 statement
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
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
> needed
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 prod
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 identific
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 pro
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 ex
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 dec
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 l
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
> implementat
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. Somet
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 h
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 time
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 s
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 a
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 i
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 I'v
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 AR
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 wide
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 general.
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 wh
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 co-chairs.
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 t
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.
> > mi
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 develop
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
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 though,
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 decid
1 - 100 of 152 matches
Mail list logo
