Proof-of-work is unusable in a world where the Bad Guys(TM) already run
botnets doing bitcoin mining - and people even willingly visit websites
that
are quite open about using the CPU of the visitor to do mining while the
visitor
is looking around the site.
That's the problem with proof-of-work - it only proves that *somebody* did
the work.
Proof-of-Work is one of our injection methods. All the injection methods
(e.g. CAPTCHA, Proof-of-Work etc.) in our system is applicable only to
"verified strangers". So this *somebody* somehow tied to a domain. Abusing
the system means, domain reputation takes a hit.
And yes bad guys already mining bitcoin via botnet. If you tell them, they
have to give away some CPU, then they are not gonna worry about that much.
But if you tell them, they have to give away 1 cent worth of bitcoin that's
when they start to see the value.
Also, if you do the math, it turns out that using a proof-of-work that's
challenging
enough to dissuade Bad Guys(TM) is also so high as to totally cripple
outbound
mail servers for many legitimate uses.
For example, vger.kernel.org hosts a number of Linux kernel related
mailing
lists. The main linux-kernel list alone has 5,000 subscribers and 1,000
posts per
day. Even if you ask for only 1 CPU second as a proof-of-work, that's
keeping
60 cores busy 24/7 doing nothing but proof-of-work for one mailing list.
And one CPU second is trivial to owners of a botnet, even if the botnet
isn't what's
doing the actual mailing.
You are talking about bulk mailing here. Our "injection" phase is not
designed for bulk mails. That's why we throw this warning when the user
enabled restricted mode.
Caution:
You are about to enter a sensitive zone.
“Restricted Mode” is intended for the boxes that deals with only
conversational mails.
So offload all website related mails to the Domboxes before you enable
this mode.
When the Restricted Mode is ON, we will send a challenge mail to the
Sender if the
sender is not found in your “Address Book”.
Real users can respond to those challenges. e.g. CAPTCHA. But automated
and bulk
mailers cannot. So their mails never gonna reach your inbox when the box
is Restricted.
Do you understand what you are signing up for?
(a) Yes, I know what I’m doing
(b) No, Get me out of here.
So the problem here is not with the system I designed. But with the "user
education". Every new system requires some kind of learning curve. So you
can't blame me for that.
I certainly don't want the end user to enable restricted mode and give out
their email address to ietf.org mailing list. I want them to create an
isolated mail address which would look like
ietf(_dot_)org(_at_)test123(_dot_)example(_dot_)com
and then give this address while signing up to ietf mailing list. That
address gives exclusive mailing privilege to ietf.org. No captcha, No
proof-of-work etc.
You're confusing "authentication" with "authorization"
I coined terminologies differently for my system.
Authorization Layer (SPF) - Checks whether the “Sending IP / Client IP” is
*authorized* to send mails for the “Envelope
Domain”.
Authentication Layer (DKIM) - This layer checks whether the mail is
digitally signed
Alignment Layer (DMARC) - Checks whether the domains are aligned
I even created a story to explain these layers to end users.
https://medium.com/@Viruthagiri/the-kings-story-6df87b32b80f
(Wait till you start digging in to fast-flux A records, and even worse,
fast-flux NS
records for DNS - the Bad Guys have been known to flip DNS records every
few
seconds, so half the time an A record points at something that has a
matching PTR
entry that looks legitimate, and the other half the time it points at a
pwned machine
that's part of the botnet. And they'll even do this with their NS
records, just to make
it hard to figure out what's going on.)
Before you ask: Yes, they've been seen to fast-flux SPF records as well.
And has has been pointed out *several* times, "send from MX" is often
unworkable
as well.
I don't have any experience with fast-flux. I have to educate myself on
this. Thanks for guiding me.
On Sat, Sep 28, 2019 at 11:19 PM Valdis Klētnieks
<valdis(_dot_)kletnieks(_at_)vt(_dot_)(_dot_)edu>
wrote:
On Sat, 28 Sep 2019 15:35:25 +0530, Viruthagiri Thirumavalavan said:
I have used C/R only as an example. C/R part is optional. I have provided
other methods for C/R alternatives. e.g. Proof-of-Work.
Proof-of-work is unusable in a world where the Bad Guys(TM) already run
botnets doing bitcoin mining - and people even willingly visit websites
that
are quite open about using the CPU of the visitor to do mining while the
visitor
is looking around the site.
That's the problem with proof-of-work - it only proves that *somebody* did
the work.
Also, if you do the math, it turns out that using a proof-of-work that's
challenging
enough to dissuade Bad Guys(TM) is also so high as to totally cripple
outbound
mail servers for many legitimate uses.
For example, vger.kernel.org hosts a number of Linux kernel related
mailing
lists. The main linux-kernel list alone has 5,000 subscribers and 1,000
posts per
day. Even if you ask for only 1 CPU second as a proof-of-work, that's
keeping
60 cores busy 24/7 doing nothing but proof-of-work for one mailing list.
And one CPU second is trivial to owners of a botnet, even if the botnet
isn't what's
doing the actual mailing.
On Sat, 28 Sep 2019 15:35:25 +0530, Viruthagiri Thirumavalavan said:
If neither verified nor authorized in the address book, that's when we
reject the mail with an error message like "550 Restricted Box.
Unauthorized and Unverified Sender. Please configure SPF or Send this
mail
from one of your MX server IP address"
Again, if you're trying to prevent spam, this doesn't work in a world
where the
spammers often have more squeaky-clean SPF and DKIM and DMARC than actual
production mail servers.
You're confusing "authentication" with "authorization" - the fact that
you've
"identified" the "source" of the mail doesn't tell you if you should
actually accept
mail from that address. And strictly speaking, this is pretty weak
"identification",
as it relies entirely on credentials created by the entity trying to
convince you of
their identity.
(Wait till you start digging in to fast-flux A records, and even worse,
fast-flux NS
records for DNS - the Bad Guys have been known to flip DNS records every
few
seconds, so half the time an A record points at something that has a
matching PTR
entry that looks legitimate, and the other half the time it points at a
pwned machine
that's part of the botnet. And they'll even do this with their NS
records, just to make
it hard to figure out what's going on.)
Before you ask: Yes, they've been seen to fast-flux SPF records as well.
And has has been pointed out *several* times, "send from MX" is often
unworkable
as well.
--
Best Regards,
Viruthagiri Thirumavalavan
Dombox, Inc.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp