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
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.
>
> If M
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
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
>>
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
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
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
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 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
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 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.
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
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
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
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
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
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
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 count it as a s
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
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
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... and oh
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
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
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
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
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 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 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 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/mailman/l
[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 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
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 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 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 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
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 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
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
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).
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
101 - 142 of 142 matches
Mail list logo
