Re: [Ietf-dkim] Taking Responsibility

[Evan Burke]

On Mon, Dec 12, 2022 at 8:49 PM Murray S. Kucherawy 
wrote:

> At a recent meeting where I heard some mass senders talk about this
> problem, the use of "x=" as a mitigation technique was raised.  I was
> curious to know what their experience was in terms of (a) success overall,
> but also (b) how broadly they found "x=" to have been properly implemented
> by receivers.  I have to admit that was some months ago and now I forget
> the answer; maybe someone else who was there can fill in that blank.
>
> But I'm not sure that "x=" by itself is enough, given that it takes only a
> matter of seconds for the attack to succeed, and it seems unlikely to me
> that the "t=" and "x=" values would ever be that close together.
>


x= is indeed the most effective single defensive technique for many
affected senders whose signatures are getting replayed, but yes - in
practice it's still "not quite enough" even when combined with multiple
other mitigation techniques. That's why we're here; existing solutions come
up short.

I can't speak to support for x= broadly, but as mentioned earlier these
replays were almost exclusively targeted at end recipients at certain large
mailbox providers, and I can confirm those have proper support for x=.
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Taking Responsibility

[Michael Thomas]

On 12/12/22 8:49 PM, Murray S. Kucherawy wrote:

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 current specs.


At a recent meeting where I heard some mass senders talk about this 
problem, the use of "x=" as a mitigation technique was raised.  I was 
curious to know what their experience was in terms of (a) success 
overall, but also (b) how broadly they found "x=" to have been 
properly implemented by receivers.  I have to admit that was some 
months ago and now I forget the answer; maybe someone else who was 
there can fill in that blank.


But I'm not sure that "x=" by itself is enough, given that it takes 
only a matter of seconds for the attack to succeed, and it seems 
unlikely to me that the "t=" and "x=" values would ever be that close 
together.


I too remain skeptical that would help with the problem as well, just 
trying to point out that there exists protocol mechanisms already 
available to have the same effect as stripping signatures. They all rely 
on the good will of the initial receiver, which of course is far from 
guaranteed.


If there is any solution here, it needs to be on the sender's end.

Mike
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Taking Responsibility

[Murray S. Kucherawy]

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 current specs.
>

At a recent meeting where I heard some mass senders talk about this
problem, the use of "x=" as a mitigation technique was raised.  I was
curious to know what their experience was in terms of (a) success overall,
but also (b) how broadly they found "x=" to have been properly implemented
by receivers.  I have to admit that was some months ago and now I forget
the answer; maybe someone else who was there can fill in that blank.

But I'm not sure that "x=" by itself is enough, given that it takes only a
matter of seconds for the attack to succeed, and it seems unlikely to me
that the "t=" and "x=" values would ever be that close together.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Taking Responsibility

[Michael Thomas]

On 12/12/22 4:57 PM, Grant Taylor wrote:

On 12/11/22 8:34 AM, Dave Crocker wrote:
I think a simple -- and hopefully not too simplistic -- question to 
consider in the context of replay and other misuses of DKIM, is when 
is it reasonable to make a fresh validation effort invalid? When 
should a random, remote agent no longer be able to 'validate' the 
signature?


I'd like to draw an analogy to S/MIME signatures on messages. 
Specifically, does the signature of a signed message that validates 
today supposed to fail tomorrow just because of the relatively short 
intervening time when the signing S/MIME certificate expired?


Also, consider the scenario where a signature validates yesterday, but 
will be rejected next week after I revoke the signing certificate 
today.  There is value in re-checking signatures /after/ delivery, 
specifically to subsequently check for revocation /after/ delivery.


I don't know if the concept of my analogy is directly applicable to 
DKIM signatures, but I think it's in the ball park.


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 current specs.


Mike

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Taking Responsibility

[Grant Taylor]

On 12/11/22 8:34 AM, Dave Crocker wrote:
I think a simple -- and hopefully not too simplistic -- question to 
consider in the context of replay and other misuses of DKIM, is when is 
it reasonable to make a fresh validation effort invalid? When should a 
random, remote agent no longer be able to 'validate' the signature?


I'd like to draw an analogy to S/MIME signatures on messages. 
Specifically, does the signature of a signed message that validates 
today supposed to fail tomorrow just because of the relatively short 
intervening time when the signing S/MIME certificate expired?


Also, consider the scenario where a signature validates yesterday, but 
will be rejected next week after I revoke the signing certificate today. 
 There is value in re-checking signatures /after/ delivery, 
specifically to subsequently check for revocation /after/ delivery.


I don't know if the concept of my analogy is directly applicable to DKIM 
signatures, but I think it's in the ball park.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Michael Thomas]

On 12/12/22 1:31 AM, Laura Atkins wrote:




On 11 Dec 2022, at 21:41, Michael Thomas  wrote:
Sure. I guess the question is how much effort would spammers be 
willing to expend before trying some other tactics?


Quite a bit, actually. I remember sitting in a 17th floor conference 
room on market street with a particular sending organization that 
explained to me their business model was to have a boiler room full of 
people iterating through content and trying to deliver it to their own 
mailbox at hotmail.com . When they found text that 
got through, they sent that until the filters caught up, then moved 
onto the next piece of content. They started this at 5pm pacific time 
and would spam all night. They did this every day.  That was 2007 or 
so (said company was sued into oblivion by the FTC not long after that 
conference room meeting).
Doesn't that stink to high heaven as abuse at hotmail? At least the 
sender can take action directly rather than hoping somebody downstream 
will.


The amount of energy spammers expend to bypass filters is significant. 
That includes bypassing port25 blocks. For instance, I’m aware of a 
company using BGP routing tricks to host their outbound spam cannons 
on major cloud providers (that block port25 by default). The IPs are 
treated as throwaway and they burn and turn them when they get too 
blocked.


Can we even quantize what the value of, say, a signed gmail piece of 
email is?  I think that's a basic question that needs to be answered 
before we declare this a problem. I for one am all ears as "DKIM 
gives you better deliverability" has always been a sort of squishy 
statement.


This is one of those questions that is, IMO, unanswerable for a lot of 
reasons. The biggest of which is: the value to whom?
Well, I assume that spammers value some domains over others, so they 
probably have some metric. But it's a tradeoff of how much boiler room 
you need vs. the reputation of the signer they're trying to coattail and 
their efforts to not send spam to keep it.


Mike
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

[Ietf-dkim] x= has been in the spec forever

[Michael Thomas]

If anything we do to prevent the replay attack requires that the 
receiving domain do something for the sending domain, it's going to be a 
heavy lift to get all of those receivers to implement that solution. 
That's doubly true if it takes away functionality that the receiver uses 
which would make them openly hostile to it.


My thinking of x= at the time was a way to not have the signature 
considered immortal. No it does not invalidate it of course, but nothing 
can force a receiver to invalidate a signed message. So any solution 
that involves the receiver is based on their good will. Since x= has 
been in the spec forever, there is a decent chance that receivers 
already implement it though it's really hard to tell from the outside. 
And the receiver actually has a stake in this since it's the sending 
domain giving it advice to protect itself. That is no different than 
expiries in x.509 certs. The receiver implements it because it's in 
their interest to implement it.


We should at least concede the point that asking the receiving domain to 
do something is nothing different than asking them to honor x=. In fact 
it's even better than stripping signatures which is trivially avoidable 
since it gives *signed* advice to the receiver of the sender's intent 
when they signed it. Receivers have a stake in advice that narrows the 
attack surface. They have no stake in just stripping signatures 
because... well, who knows.


Mike

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Michael Thomas]

On 12/12/22 12:11 PM, Evan Burke wrote:


On Mon, Dec 12, 2022 at 11:21 AM Michael Thomas  wrote:

On 12/12/22 6:57 AM, Murray S. Kucherawy wrote:

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
kinda think that should be table stakes before talking about
rechartering.


The industry appears to think it's a factor. This work comes to
us from M3AAWG where there's a critical mass that believes
reputation abuse of this nature is real.  Though I agree it would
be helpful to have metrics to describe it more precisely, it's my
perception that there's enough momentum here to back chartering.


So I take it they haven't quantified it either? This strikes me as
highly susceptible to using anecdotal evidence as proof. I'm not
saying they are wrong, I just would like to see actual evidence.
That's especially true if the end result is telling receivers they
should do something that they have no stake in.


I suspect that most of the organizations affected aren't positioned to 
share the internal metrics that showed impact, but I can tell you from 
experience the effects can be quite dramatic, and I've spoken to more 
than a few people - also with direct experience - who would say the same.


These attacks were very narrowly targeted; the vast majority of DKIM 
replay spam this year has been sent to just a few of the largest 
consumer mailbox providers. In that context, lack of awareness of the 
problem is a poor argument against trying to solve it.



If the solution to the problem results in taking away functionality 
available for 15 years as some are recommending, I'd say that the onus 
is on the people making the claims to actually back it up. From my 
perspective this is all just hearsay. I think the larger community is 
entitled to something more than that before doing anything.


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 suggests that reputation remains an unsolved 
problem. Maybe it is just one side of the company not knowing what the 
other side knows, but I find that rather unlikely. So there is a 
contradiction somewhere here from where I sit.


Mike
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Evan Burke]

On Mon, Dec 12, 2022 at 11:21 AM Michael Thomas  wrote:

> On 12/12/22 6:57 AM, Murray S. Kucherawy wrote:
>
> 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 kinda think that should be table stakes before talking about
>> rechartering.
>>
>
> The industry appears to think it's a factor.  This work comes to us from
> M3AAWG where there's a critical mass that believes reputation abuse of this
> nature is real.  Though I agree it would be helpful to have metrics to
> describe it more precisely, it's my perception that there's enough momentum
> here to back chartering.
>
> So I take it they haven't quantified it either? This strikes me as highly
> susceptible to using anecdotal evidence as proof. I'm not saying they are
> wrong, I just would like to see actual evidence. That's especially true if
> the end result is telling receivers they should do something that they have
> no stake in.
>

I suspect that most of the organizations affected aren't positioned to
share the internal metrics that showed impact, but I can tell you from
experience the effects can be quite dramatic, and I've spoken to more than
a few people - also with direct experience - who would say the same.

These attacks were very narrowly targeted; the vast majority of DKIM replay
spam this year has been sent to just a few of the largest consumer mailbox
providers. In that context, lack of awareness of the problem is a poor
argument against trying to solve it.
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Michael Thomas]

On 12/12/22 6:57 AM, Murray S. Kucherawy wrote:

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 kinda think that should be table
stakes before talking about rechartering.


The industry appears to think it's a factor.  This work comes to us 
from M3AAWG where there's a critical mass that believes reputation 
abuse of this nature is real.  Though I agree it would be helpful to 
have metrics to describe it more precisely, it's my perception that 
there's enough momentum here to back chartering.



So I take it they haven't quantified it either? This strikes me as 
highly susceptible to using anecdotal evidence as proof. I'm not saying 
they are wrong, I just would like to see actual evidence. That's 
especially true if the end result is telling receivers they should do 
something that they have no stake in.


Mike
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Al Iverson]

On Sun, Dec 11, 2022 at 4:46 PM 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
> > want so long as the only thing I change is the envelope.
>
> Since the ISP is doing the signing, you can't stop them from using a
> signature that protects the To: and Cc: from modification, and in practice
> everyone already does that.  That means the bonus messages you get to
> send via the hack will have mismatched 822 and 821 recipients, equivalent
> to a blind-carbon-copy.
>
> Blind-carbon-copy is already a sign of spam.

Except when it's not, like this very mailing list.

Cheers,
Al Iverson

-- 

Al Iverson / Deliverability blogging at www.spamresource.com
Subscribe to the weekly newsletter at wombatmail.com/sr.cgi
DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time)

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Murray S. Kucherawy]

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 kinda think that should be table stakes before talking about
> rechartering.
>

The industry appears to think it's a factor.  This work comes to us from
M3AAWG where there's a critical mass that believes reputation abuse of this
nature is real.  Though I agree it would be helpful to have metrics to
describe it more precisely, it's my perception that there's enough momentum
here to back chartering.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Laura Atkins]

> On 12 Dec 2022, at 14:34, Murray S. Kucherawy  wrote:
> 
> 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 restricted signing to accountable users only, its 
> signatures would gain value.  If they started doing so it would soon be 
> noticed, and signatures would acquire a meaning in delivery decisions.
>  
> Is the cost of imposing a program that vets every user comparable to that of 
> the damage caused by this attack vector?  My impression is that it is not.

I’m not aware of Gmail being a significant victim here - although it’s possible 
they are. 

> Endowing signatures with a significant value increases the overall value of 
> DKIM.
> 
> Presumably they already have significant value.  That's why this attack works 
> already.

They’re an identity of a known sender that invests time and resources into 
building and managing their reputation. Google? Maybe not. But the email 
service providers who do a lot to keep the spammers off their network are a 
common victim. These spammers know that they get better delivery if their mail 
is signed by the email service provider. The email service provider’s detectors 
and defenses are enough to stop the spammer from being able to send through the 
ESP. So the spammer sends one email to an account they own and takes a 
reputation they’ve already been told they shouldn’t be using. 

A DKIM signature is an identity. That identity has a reputation. Attacks that 
borrow the identity belonging to senders with good reputation benefit from that 
reputation. It’s not about any DKIM signature. It’s not about a random DKIM 
signature. It’s about a known entity. Even if Gmail only signed mail from 
accountable users, there is still the possibility of spammers posing as 
accountable users. 

The whole idea of a DKIM replay attack is that this is mail that cannot be 
directly sent through the infrastructure of the domain owner. That, itself, 
implies the domain owners are doing quite a bit to stop the spam from coming 
out of their network. If they weren’t doing a good job then replay attacks 
wouldn’t be happening - the mail would just be sent over that network directly. 

Asking for the domain owners to “stop sending spam” when the whole replay 
process indicates they are stopping spam out of the networks they control seems 
a bit of a non-starter to me. 

> The question is whether we should proclaim that the bar needs to be even 
> higher, maybe even an all-or-nothing proposition.  I'm suggesting that's not 
> a good idea.

Agreed. 

laura 

-- 
The Delivery Experts

Laura Atkins
Word to the Wise
la...@wordtothewise.com 

Email Delivery Blog: http://wordtothewise.com/blog  






___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Murray S. Kucherawy]

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 restricted signing to accountable users only,
> its
> signatures would gain value.  If they started doing so it would soon be
> noticed, and signatures would acquire a meaning in delivery decisions.
>

Is the cost of imposing a program that vets every user comparable to that
of the damage caused by this attack vector?  My impression is that it is
not.

Endowing signatures with a significant value increases the overall value of
> DKIM.
>

Presumably they already have significant value.  That's why this attack
works already.

The question is whether we should proclaim that the bar needs to be even
higher, maybe even an all-or-nothing proposition.  I'm suggesting that's
not a good idea.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Laura Atkins]

> On 11 Dec 2022, at 21:41, Michael Thomas  wrote:
> 
> 
> 
> On 12/11/22 1:16 PM, Murray S. Kucherawy wrote:
>> 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 
>>> anything.
>>> 
>>> 
>>> I think this is easier said than done.  In the example I gave, "don't send 
>>> spam in the first place" reduces to "make sure your users are 100% 
>>> trustworthy or that your outbound spam filters are 100% accurate", which 
>>> strikes me as an impossible bar to meet.
>> I'm going to assume that the attackers will need to iterate to find a piece 
>> of mail that passes their filters. That is signal right there that abuse is 
>> likely. Perhaps an exponential backoff could be employed when outbound spam 
>> is detected. Sort of like a 4xx "try later".
>> 
>> That's easy to evade: Come from a rotating pool of IP addresses, using a new 
>> free account each time.
> Sure. I guess the question is how much effort would spammers be willing to 
> expend before trying some other tactics?

Quite a bit, actually. I remember sitting in a 17th floor conference room on 
market street with a particular sending organization that explained to me their 
business model was to have a boiler room full of people iterating through 
content and trying to deliver it to their own mailbox at hotmail.com 
. When they found text that got through, they sent that 
until the filters caught up, then moved onto the next piece of content. They 
started this at 5pm pacific time and would spam all night. They did this every 
day.  That was 2007 or so (said company was sued into oblivion by the FTC not 
long after that conference room meeting). 

The amount of energy spammers expend to bypass filters is significant. That 
includes bypassing port25 blocks. For instance, I’m aware of a company using 
BGP routing tricks to host their outbound spam cannons on major cloud providers 
(that block port25 by default). The IPs are treated as throwaway and they burn 
and turn them when they get too blocked. 

> Can we even quantize what the value of, say, a signed gmail piece of email 
> is?  I think that's a basic question that needs to be answered before we 
> declare this a problem. I for one am all ears as "DKIM gives you better 
> deliverability" has always been a sort of squishy statement. 

This is one of those questions that is, IMO, unanswerable for a lot of reasons. 
The biggest of which is: the value to whom? 

>> 
>> But the BCC aspect is interesting too. Don't providers already view things 
>> with massive rcpt-to (bcc's) suspiciously? hat's easy to evade: Send a spam 
>> message to yourself only.  That has the signature.  Now capture that from 
>> your inbox and replay it from a different server to any number of 
>> recipients, using any number of envelopes, to your heart's content.  Won't 
>> pass SPF, but it passes DKIM.  If the receiver values DKIM more, or only 
>> cares if one passes, you win
>> 
> No, I mean that the if number of RCPT-TO's is large, it's suspicious. Even if 
> they do individual SMTP transactions it will have the same (signed) 
> Message-Id so that's not evadeable either in theory. 
> 
Interesting thought. 

laura

-- 
The Delivery Experts

Laura Atkins
Word to the Wise
la...@wordtothewise.com 

Email Delivery Blog: http://wordtothewise.com/blog  






___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Laura Atkins]

> On 11 Dec 2022, at 20:52, Murray S. Kucherawy  wrote:
> 
> 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 that proposal that warrants further 
> debate.  I think the argument is compelling, but it's clearly not bulletproof.
>  
> 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 
> anything.
> 
> I think this is easier said than done.  In the example I gave, "don't send 
> spam in the first place" reduces to "make sure your users are 100% 
> trustworthy or that your outbound spam filters are 100% accurate", which 
> strikes me as an impossible bar to meet.

Also, in the case of replay attacks, we’re redefining spam to a point of 
uselessness. Spam is mail that users didn’t ask to receive. But the initial 
message that’s being signed is an opt-in message. The sender knows the 
recipient address wants the message. We’ve spent 25 years trying to block spam, 
I’m not sure that this is even a solveable problem. Even if you made COI the 
default and could only send mail with an actual confirmation message in hand, 
that’s a trivially jumpable hoop for the spammer to negotiate. 

> 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

Agreed. 

laura 

-- 
The Delivery Experts

Laura Atkins
Word to the Wise
la...@wordtothewise.com 

Email Delivery Blog: http://wordtothewise.com/blog  






___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Alessandro Vesely]

On Sun 11/Dec/2022 21:52:46 +0100 Murray S. Kucherawy wrote:

On Sun, Dec 11, 2022 at 12:34 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
anything.


I think this is easier said than done.  In the example I gave, "don't send
spam in the first place" reduces to "make sure your users are 100%
trustworthy or that your outbound spam filters are 100% accurate", which
strikes me as an impossible bar to meet.

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 restricted signing to accountable users only, its 
signatures would gain value.  If they started doing so it would soon be 
noticed, and signatures would acquire a meaning in delivery decisions.


Endowing signatures with a significant value increases the overall value of 
DKIM.



Best
Ale
--






___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim