Re: [ietf-smtp] Dombox - A Zero Spam Mail System

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.

pgpC561zjfiBa.pgp
Description: PGP signature

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp