On Fri, Aug 17, 2018 at 4:15 AM, Alessandro Vesely wrote:
> > The DKIM aggregate reports show whether a server signs correctly all
> mails or
> > not. If the aggregate reports show that this is sometimes (let's say in
> 1%)
> > not done correctly, the signer has no way to find for which email th
On Sat, Aug 18, 2018 at 2:45 PM, Murray S. Kucherawy
wrote:
> On Fri, Aug 17, 2018 at 4:15 AM, Alessandro Vesely wrote:
>
>> > The DKIM aggregate reports show whether a server signs correctly all
>> mails or
>> > not. If the aggregate reports show that this i
On Fri, Aug 10, 2018 at 8:38 PM, Dilyan Palauzov
wrote:
> I suggest here in to suggest in a more formal manner, that MLMs modifying
> a message are supposed to remove the r=y part of just invalidated
> DKIM-Signature and this logic is also applied for ARC, if relevant (I don't
> know ARC). Fixin
On Sat, Aug 18, 2018 at 8:30 PM, Dilyan Palauzov
wrote:
> Two out of two responders were against removing r=y from the
> DKIM-Signature.
>
> I am fine with removing the invalidated DKIM-Signatures, but mailman
> developers are not (https://gitlab.com/mailman/mailman/issues/500) as
> this were inc
On Sat, Aug 18, 2018 at 10:42 PM, Dilyan Palauzov wrote:
> I suggested to write in ARC to alter the existing signature.
>
As I said before, I suspect you will have a hard time selling an "alter the
existing signature" idea no matter what document you propose to create or
update.
-MSK
__
DKIM verifiers are not required to generate reports. It's completely
optional. Does the place you're sending to advertise somehow that they
will be generated?
On Mon, Dec 17, 2018 at 8:36 AM Fazzina, Angelo
wrote:
> Hi, I am trying to test my TXT records for the ability to report failures..
>
On Mon, May 11, 2020 at 10:30 AM Dave Crocker wrote:
> On 5/11/2020 10:21 AM, Alessandro Vesely wrote:
> > The question is, what responsibility is being claimed?
>
> > Tagging keys with aim= would allow senders to choose an appropriate
> selector
> > under different circumstances.
>
> If sig
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 you trust the domain, you can as well trust their tagging.
>
If you tru
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/May/2020 20:23:12 +0200 Murray S. Kucherawy wrote:
> >>> Ind
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/May/2020 17:48:38 +0200 Murray S. Kucherawy wrote:
> >>>
On Thu, Nov 10, 2022 at 12:42 PM Scott Kitterman
wrote:
> I agree that we don't want too much detail in the charter about the
> technical
> nature of the problem, but I would like to understand it in more detail in
> order to better assess the appropriateness of what is there.
>
> If a domain is
On Thu, Nov 10, 2022 at 12:54 PM Laura Atkins
wrote:
> In many cases, the reason the mail isn’t going out through the signing
> domain is because the signing domain’s anti-spam heuristics are good enough
> that the sender couldn’t maintain an account there long enough to send out
> any volume of
[offlist]
On Thu, Nov 10, 2022 at 1:21 PM Laura Atkins
wrote:
>
> On 10 Nov 2022, at 13:17, Murray S. Kucherawy wrote:
>
> On Thu, Nov 10, 2022 at 12:54 PM Laura Atkins
> wrote:
>
>> In many cases, the reason the mail isn’t going out through the signing
>>
On Thu, Nov 10, 2022 at 1:24 PM Murray S. Kucherawy
wrote:
> [offlist]
>
> ...
>
Actually I didn't intend for it to be offlist, sorry for the confusing tag.
-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mail
On Fri, Nov 11, 2022 at 5:05 AM Scott Kitterman
wrote:
> > A heuristic I’ve suggested previously is “If the recipient’s email
> address
> > is not in the To: or Cc: header then treat the mail as unsigned”.
>
> Which is a fancy way of making DKIM only work for direct mail flows.
>
That's part of
On Fri, Nov 11, 2022 at 11:42 AM Laura Atkins
wrote:
>
> The MP limits the volume of messages that a user can send out. However,
> by signing even one message, it takes the responsibility for its content.
>
>
> This appears to be the disconnect. The MP takes responsibility for the
> *MESSAGE* -
On Sat, Nov 12, 2022 at 7:32 AM Roland Turner wrote:
> On 11/11/22 23:09, Murray S. Kucherawy wrote:
>
> More concerning to me: The IETF has previously taken the position that the
> market will figure out spam and phishing, and therefore consideration of
> protocol solutions shou
On Mon, Nov 14, 2022 at 12:26 AM Scott Kitterman
wrote:
> Is compatibility with DKIM sufficient for the charter or should there be
> broader language about compatibility with existing email architecture?
> I'm
> inclined to say "Yes", but I'm unsure about wording.
I also assume "Yes". I'm hav
On Mon, Nov 14, 2022 at 12:42 AM Scott Kitterman
wrote:
>
> I don't think there's any point in pursuing solutions that require a human
> to read/understand anything about header fields.
>
> Having reviewed the proposals again, it seems like anything that actively
> makes replays harder without ad
On Mon, Nov 14, 2022 at 11:04 AM Laura Atkins
wrote:
> Does it make sense to add in a brief discussion of ‘responsibility for the
> message'? As I see it, responsibility implies able to do something against
> the originator of the message or act to stop the message if it turns out to
> be a probl
On Sun, Nov 20, 2022, 11:08 Dave Crocker wrote:
> Seriously. DKIM is intended as a transit-time mechanism. When delivery
> occurs, transit is done. So DKIM has done its job and can (safely?) be
> removed.
One of the informational RFCs the original working group produced discussed
this. A rea
On Sun, Nov 20, 2022 at 11:08 AM Dave Crocker wrote:
> On 11/11/2022 7:19 AM, Murray S. Kucherawy wrote:
> > I think you've hit on possibly the most interesting part of this: In
> > RFC 6376, we said "You're taking some responsibility for this
> > message
Hey Miles,
On Mon, Nov 21, 2022 at 10:29 AM Miles Libbey
wrote:
> - the (signed) Date: header would get further in the past the longer a
> replay is used, which would/could be a sign of misbehavior
>
I think this is a decent theory, but with automation, the delta between
"Date" and/or the signa
Hi Jon,
On Mon, Nov 21, 2022 at 4:07 PM Jon Callas wrote:
> As another original author, it was hard for me to understand what this was
> talking about when the discussion first came up. I even considered replying
> to this thread asking something like, "isn't replay just sending the
> message ag
On Mon, Nov 21, 2022 at 2:01 PM Dave Crocker wrote:
> On 11/21/2022 1:56 PM, Murray S. Kucherawy wrote:
> > I don't want to get into implementation discussions before we even
> > have a charter, but I'm curious about how this could be made effective.
>
> I'd
On Sat, Nov 26, 2022 at 4:31 PM Dave Crocker wrote:
> On 11/26/2022 3:20 PM, Barry Leiba wrote:
> > I will say that the use case that is broken by removing the signature
> > is the "re-send" case, where the MUA or some other post-delivery agent
> > (perhaps a sieve script) re-introduces the messa
On Sun, Nov 27, 2022 at 6:01 PM Dave Crocker wrote:
> On 11/27/2022 5:48 PM, Murray S. Kucherawy wrote:
>
> Post-delivery survival of the signature is not only not a goal, it is
>> arguably (or possibly demonstrably) a problem.
>>
>
> Can we say more about this
Hi folks,
Area Director hat on here:
The discussion Barry kicked off has been interesting, but it has strayed
(and mea culpa, in part, because the material is interesting) from the work
of discussing a charter.
I've set the stage for re-chartering in the system, and now we need some
charter text
On Sun, Nov 27, 2022 at 6:50 PM Dave Crocker wrote:
> On 11/27/2022 6:30 PM, Murray S. Kucherawy wrote:
> > Domain Keys Identified Mail (DKIM, RFC 6376) defines a mechanism for
> > using a digital signature to associate a domain identity with an email
> > message in a secu
On Sun, Nov 27, 2022 at 9:34 PM Scott Kitterman
wrote:
> I would add mention of the problem statement draft. I think it may turn
> out
> to be the most important of the ones we have now.
>
Do you mean: Mention it as a mandatory deliverable?
Should we still produce that document even if we conc
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. Once it appears to be stable
relative to this audience, I'll send it on its way for internal (IESG) and
then full
On Sat, Dec 3, 2022 at 12:20 PM Jon Callas wrote:
> > On Dec 3, 2022, at 11:42, Dave Crocker wrote:
> >
> > On 12/3/2022 11:35 AM, Jon Callas wrote:
> >> Agreed, and we need some other weasel word than "lightweight" because
> there are lots of people working on "lightweight" symmetric ciphers.
>
On Tue, Dec 6, 2022 at 4:20 PM Dave Crocker wrote:
> DKIM was developed to facilitate delivery handling decisions. The
> language in the RFC 4871 and RFC 6376 doesn't make this as explicit as I'd
> wish, given the perspective I'm advocating, but it's got some implicating
> language. References
On Wed, Dec 7, 2022 at 2:06 PM Dave Crocker wrote:
> As appealing as the AS concept is, I've never been clear how operationally
> useful they are.
>
> More to the current point, if the anti-replay work to be done benefits
> from a position on transit vs. non-transit, then including it directly in
On Thu, Dec 8, 2022 at 12:56 AM Laura Atkins
wrote:
>
> Fair enough. Does the charter need to say that a revision to best
> practices, relative to the replay problem, might be a possible output?
> It's within the realm of possibility that no protocol work comes out of
> this, but a "checkpoint"
On Fri, Dec 9, 2022 at 7:08 PM Barry Leiba wrote:
> I have no formal role here, so please just take this as a plea from a
> participant:
>
> Let's please stop bickering: it's simply hindering a productive
> discussion of a charter, and it's clear that we can have endless
> back-and-forth messages
On Sat, Dec 10, 2022 at 7:42 PM Michael Deutschmann
wrote:
> It's a bit annoying that after almost two weeks, the only responses in
> this thread have been about this side issue, with my main point
> unaddressed.
>
As I read your original post, it was about DKIM+DMARC being an anti-forgery
tool,
On Sun, Dec 11, 2022 at 12:34 PM Michael Thomas wrote:
> Re: stripping signatures, all the attacker needs to do is either send it
> to a service that doesn't strip signatures or use their own MTA. Trivially
> avoidable, and a Maginot Line of epic narrowness.
>
Right, I think this is an aspect of
On Sun, Dec 11, 2022 at 1:11 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. Neither of these needs the working group to do
>> anythi
On Sun, Dec 11, 2022 at 1:41 PM Michael Thomas wrote:
>
> But the BCC aspect is interesting too. Don't providers already view things
>> with massive rcpt-to (bcc's) suspiciously?
>>
> That's easy to evade: Send a spam message to yourself only. That has the
> signature. Now capture that from you
On Sun, Dec 11, 2022 at 1:55 PM Murray S. Kucherawy
wrote:
> In the transaction where the signature is applied, there's only one
> envelope recipient. When I'm executing the attack, I could do one envelope
> per recipient if I'm worried about being detected that way.
ce DKIM 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
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 wa
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 restri
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 k
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 cu
On Mon, Dec 12, 2022 at 12:36 PM Michael Thomas wrote:
> I have good reason to be suspicious. That Google was one of the major
> proponents of ARC which was supposedly to deal with the mailing list
> problem but all boiled down to reputation that could already be done with
> plain old DKIM sugges
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 would.
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 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 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 b
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 joine
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
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 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 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 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 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 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
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 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
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
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 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
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
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 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
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 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 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
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 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
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 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 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
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 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.
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 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
1 - 100 of 276 matches
Mail list logo
