nanog mailing list archives

RE: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC


From: "Keith Medcalf" <kmedcalf () dessus com>
Date: Mon, 08 Jul 2019 18:54:51 -0600


On Monday, 8 July, 2019 18:08, Michael Thomas <mike () mtcc com> wrote:

when we did DKIM back in the day, almost nobody was requiring SMTP
auth which meant the providers could say "blame me" via the DKIM
signature, >but couldn't really take much action since they didn't
know who has doing it.

This is because DKIM was a solution to a problem that did not exist.  You always know the identity of the MTA sending 
you a message, there never was a need for DKIM.  It was a solution to a problem that does not and did not nor will ever 
exist.

we sort of took a leap of faith that that would happen.
nowadays, almost everybody requires SMTP auth (and tls, ...) afaik. i
have no idea whether DKIM was in any way a motivating factor, but it
did happen in the meantime.

This happened long long long before DKIM was even a wet spot on the sheets.

i know the parallels here are not exact (is it really PRI's that are
the source of most of the spam?) , but it's maybe a little premature to
completely write off the providers for doing the Right Thing. putting
the "blame me" badge on might give them some incentive to clean up
their act. as with email spam, there is no silver bullet of course.

The solution is to disallow spoofing.  If the "pretty overlay information" does not equal the "billing information" 
then do not permit the call to be made.  Easy Peasy.  However, this will interfere with the carriers ability to make 
money since the ability to make money depends on being in cahoots with the fraudsters.  Making it such that the 
Directors and Officers those carriers in cahoots suffer the death penalty (or life imprisonment) will solve the problem 
in an afternoon, but it will not happen because the cahooteers' (those Directors and Officers) own the slimy 
politicians needed to implement the cure.

fwiw, the stir/shaken problem statement is a good read.

https://datatracker.ietf.org/doc/rfc7340/

Not a bad work of complete fiction!

Of course, the "root cause" can be found at the very beginning of the thing where it is pointed out that there are 
reasons for providing false data, and that since "the other guy" allows the presentation of false data, we should too 
otherwise we will go out of business.  Once this "root cause" is accepted, then the inevitable ensues ...

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.





Current thread: