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 11:42 PM, Murray S. Kucherawy wrote:
> 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?
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 12:02 PM, Dave Crocker wrote:
> On 9/2/2023 7:29 AM, Jesse Thompson wrote:
>> On Tue, Aug 29, 2023, at 9:02 PM, Dave Crocker wrote:
>>> DKIM, SPF, et al, are all 'collaborative' mechanisms. Originators and
>>> receivers opt in to use them. Both sides are necessary. So
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 Sep 7, 2023, at 6:15 PM, Evan Burke
wrote:
On Thu, Sep 7, 2023 at 10:17 AM Murray S. Kucherawy
mailto:superu...@gmail.com>> wrote:
On Thu, Sep 7, 2023 at 10:03 AM Dave Crocker
mailto:d...@dcrocker.net>> wrote:
Keys cannot be rotated fast enough to be useful within the time frame that
On Thu, Sep 7, 2023 at 10:17 AM Murray S. Kucherawy
wrote:
> On Thu, Sep 7, 2023 at 10:03 AM Dave Crocker wrote:
>
>> Keys cannot be rotated fast enough to be useful within the time frame
>> that attackers work in.
>>
>> Key rotation works in a timeframe of days or weeks. Attackers work in
>>
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 9/2/2023 7:29 AM, Jesse Thompson wrote:
On Tue, Aug 29, 2023, at 9:02 PM, Dave Crocker wrote:
DKIM, SPF, et al, are all 'collaborative' mechanisms. Originators
and receivers opt in to use them. Both sides are necessary. So I'm
wondering about looking for something the furthers the
On Tue, Aug 29, 2023, at 9:02 PM, Dave Crocker wrote:
> DKIM, SPF, et al, are all 'collaborative' mechanisms. Originators and
> receivers opt in to use them. Both sides are necessary. So I'm wondering
> about looking for something the furthers the collaboration.
The lack of reporting to the
> On 1 Sep 2023, at 18:31, Grant Taylor
> wrote:
>
> On 9/1/23 3:32 AM, Laura Atkins wrote:
>> You don’t know that they don’t do spamfiltering on outbound messages. You
>> don’t see what they catch and don’t send. What you do see is when that spam
>> filtering fails.
>
> I do know that a
On 9/1/23 3:32 AM, Laura Atkins wrote:
You don’t know that they don’t do spamfiltering on outbound messages.
You don’t see what they catch and don’t send. What you do see is when
that spam filtering fails.
I do know that a small number of operators don't do any outbound spam
filtering
> On 1 Sep 2023, at 03:49, Grant Taylor
> wrote:
>
> On 8/31/23 8:02 PM, Bron Gondwana wrote:
>> The classic case was that spam about V*gra was very common, but blocking
>> that word in every anti-spam filter would create something that was really
>> not fit for purpose for Pfizer to use
On Fri, Sep 1, 2023, at 12:49, Grant Taylor wrote:
> On 8/31/23 8:02 PM, Bron Gondwana wrote:
> > The classic case was that spam about V*gra was very common, but blocking
> > that word in every anti-spam filter would create something that was
> > really not fit for purpose for Pfizer to use for
On 8/31/2023 7:23 PM, Bron Gondwana wrote:
Now - there is a fact known to my system that's not known to yours (my
signed-in identity, which isn't br...@fastmailteam.com, and may not
appear at all other than an opaque header that other systems can't
parse). So that's a fair call, there's
On 8/31/23 8:02 PM, Bron Gondwana wrote:
The classic case was that spam about V*gra was very common, but blocking
that word in every anti-spam filter would create something that was
really not fit for purpose for Pfizer to use for their email system.
The sender and recipient really make a
On Fri, Sep 1, 2023, at 11:33, Stephen Farrell wrote:
>
> Hi Bron,
>
> On 01/09/2023 02:02, Bron Gondwana wrote:
> > Fact: recipient spam filter has more information than sender spam filter
>
> I've no axe to grind here, but wondered - is there e.g. a
> peer-reviewed publication that
On 8/31/2023 6:02 PM, Bron Gondwana wrote:
Fact: recipient spam filter has more information than sender spam filter
The key bit, I think, is that more has happened, by the time of
receiving. Namely more copies sent through bots, etc.
Anyhow, the limitations at the sending side is why I am
Hi Bron,
On 01/09/2023 02:02, Bron Gondwana wrote:
Fact: recipient spam filter has more information than sender spam filter
I've no axe to grind here, but wondered - is there e.g. a
peer-reviewed publication that conclusively demonstrates
that?
Not saying that that's necessary, but I
On Wed, Aug 30, 2023, at 12:38, Grant Taylor wrote:
> On 8/29/23 3:15 PM, Steve Atkins wrote:
> > Any attempt by senders to filter outbound emails based solely on
> > content is going to have a lot of false negatives and positives,
> > wherever you decide to draw the line.
>
> I find the idea
On Wed 30/Aug/2023 14:14:41 +0200 Dave Crocker wrote:
On 8/30/2023 1:21 AM, Alessandro Vesely wrote:
On Wed 30/Aug/2023 07:35:08 +0200 Murray S. Kucherawy wrote:
On Tue, Aug 29, 2023 at 8:11 PM Dave Crocker wrote:
On 8/29/2023 7:46 PM, Grant Taylor wrote:
On 8/29/23 9:02 PM, Dave Crocker
On Wed, Aug 30, 2023 at 1:18 AM Laura Atkins
wrote:
>
>
> On 29 Aug 2023, at 19:07, Dave Crocker wrote:
>
> Not that this is all that new a question, but I think it might be worthy
> of more (and maybe different focus)...
>
> When a message is used in a DKIM Replay Attack:
>
>1. It
On 8/30/2023 9:58 AM, Laura Atkins wrote:
On 30 Aug 2023, at 14:52, Grant Taylor
wrote:
On 8/30/23 12:35 AM, Murray S. Kucherawy wrote:
And I've never understood why people get enamored of the idea of
relying on bad reputations to spot bad actors.
I think of it as the other way around;
> On 30 Aug 2023, at 14:52, Grant Taylor
> wrote:
>
> On 8/30/23 12:35 AM, Murray S. Kucherawy wrote:
>> And I've never understood why people get enamored of the idea of relying on
>> bad reputations to spot bad actors.
>
> I think of it as the other way around; good reputation to spot good
On 8/30/23 12:35 AM, Murray S. Kucherawy wrote:
And I've never understood why people get enamored of the idea of relying
on bad reputations to spot bad actors.
I think of it as the other way around; good reputation to spot good actors.
Much like a brand new domain is effectively neutral
On 8/30/2023 1:21 AM, Alessandro Vesely wrote:
On Wed 30/Aug/2023 07:35:08 +0200 Murray S. Kucherawy wrote:
On Tue, Aug 29, 2023 at 8:11 PM Dave Crocker wrote:
On 8/29/2023 7:46 PM, Grant Taylor wrote:
On 8/29/23 9:02 PM, Dave Crocker wrote:
Why not re-use the existing DKIM solution, just
On 8/29/2023 10:35 PM, Murray S. Kucherawy wrote:
On Tue, Aug 29, 2023 at 8:11 PM Dave Crocker wrote:
On 8/29/2023 7:46 PM, Grant Taylor wrote:
> On 8/29/23 9:02 PM, Dave Crocker wrote:
>
Rather than doing it in a header field, though, could it be done
simply with a new tag?
> On 30 Aug 2023, at 09:21, Alessandro Vesely wrote:
>
> On Wed 30/Aug/2023 06:20:47 +0200 Steve Atkins wrote:
>>> On 30 Aug 2023, at 03:38, Grant Taylor
>>> wrote:
>>> On 8/29/23 3:15 PM, Steve Atkins wrote:
Any attempt by senders to filter outbound emails based solely on content
On Wed 30/Aug/2023 06:20:47 +0200 Steve Atkins wrote:
On 30 Aug 2023, at 03:38, Grant Taylor
wrote:
On 8/29/23 3:15 PM, Steve Atkins wrote:
Any attempt by senders to filter outbound emails based solely on content is
going to have a lot of false negatives and positives, wherever you decide
On Wed 30/Aug/2023 07:35:08 +0200 Murray S. Kucherawy wrote:
On Tue, Aug 29, 2023 at 8:11 PM Dave Crocker wrote:
On 8/29/2023 7:46 PM, Grant Taylor wrote:
On 8/29/23 9:02 PM, Dave Crocker wrote:
Why not re-use the existing DKIM solution, just with a different
domain / set of keys?
Because
> On 29 Aug 2023, at 19:07, Dave Crocker wrote:
>
> Not that this is all that new a question, but I think it might be worthy of
> more (and maybe different focus)...
>
> When a message is used in a DKIM Replay Attack:
>
> It originates from a domain name having good reputation
> It passes
> On 30 Aug 2023, at 06:35, Murray S. Kucherawy wrote:
>>
>
> This also presumes that operators currently develop reputation based on (d=,
> s=) pairs. Is that so? I thought it was mostly just the d= that matters.
That some major consumer mailbox providers use s= to track reputation is
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
Sent from my iPhone
> On 30 Aug 2023, at 03:38, Grant Taylor
> wrote:
>
> On 8/29/23 3:15 PM, Steve Atkins wrote:
>> Any attempt by senders to filter outbound emails based solely on content is
>> going to have a lot of false negatives and positives, wherever you decide to
>> draw the
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 information that I am
postulating/guessing the originating platform can
On 8/29/23 9:02 PM, Dave Crocker wrote:
A possible way to think about how to approach this:
1. Use the mechanism for messages deemed spammy by the originating
platform, or for new users who do not yet have an established
quality record, or...
2. Add a header field that has
On 8/29/23 3:15 PM, Steve Atkins wrote:
Any attempt by senders to filter outbound emails based solely on
content is going to have a lot of false negatives and positives,
wherever you decide to draw the line.
I find the idea of using different, probably less stringent, filtering
on outbound
On 8/29/2023 1:15 PM, Steve Atkins wrote:
Many, many people sign up to receive content that is, by any objective
content-filtering standard, as spammy as an incredibly spammy thing.
Seriously, people sign up for things you would not believe.
Any attempt by senders to filter outbound emails
Sent from my iPhone
> On 29 Aug 2023, at 20:54, Dave Crocker wrote:
>
> On 8/29/2023 12:30 PM, Murray S. Kucherawy wrote:
>> For (1), I presume the outbound site did not make a quality assessment that
>> identified the message as "likely to be replayed". Does this reduce to the
>> "don't
On 8/29/2023 12:30 PM, Murray S. Kucherawy wrote:
For (1), I presume the outbound site did not make a quality assessment
that identified the message as "likely to be replayed". Does this
reduce to the "don't sign spam" argument?
I have no idea what the current levels of outbound filtering
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,
Not that this is all that new a question, but I think it might be worthy
of more (and maybe different focus)...
When a message is used in a DKIM Replay Attack:
1. It originates from a domain name having good reputation
2. It passes quality checks from that sending domain
3. It goes to a
42 matches
Mail list logo
