>, you could have a request mechanism. It’s a link, you go there, and it requires one-time auth from _any site at all of note_. Some sort of social proof. And that gives you a link.

Sure but as I previously mentioned, that proposal is another variation of a "solution" where you must do some non-email activity first such as ... authorize with login credentials from LinkedIn/Facebook/Google/Github/Apple/etc ... and then receive the generated rolling email address.

Yes, if the solution space is opened up to include doing non-email activity as a prerequisite to later communicating via email, there are many ideas. But many SMTP email decentralized purists think having to use centralized "social proof" sites such as Facebook for single-sign-on credentials is not an acceptable solution.

That's why the (failed) Hashcash idea had appeal for email enthusiasts that wanted the "proof" to reside _within_ the SMTP ecosystem. E.g. the extra Hashcash email header row would be something like "X-Hashcash: 1:20:1303030600:anni@cypherspace.org::McMybZIhxKXu57jd:ckvi"

The "sudoku-solving" hashcash "proof" as one might call it... is generated by the email sender and verified by the receiver without relying on a non-email entity. The "legitimacy score" of new emails from new unknown users can be calculated and assessed within the SMTP ecosystem. ... But it's not a solution that pleases everyone because there are inevitable tradeoffs: (1) cpu heat "killing polar bears" and (2) home computers (instead of spammers' computers) inadvertently expend the cpu because of infection by malware to become part of a bot army

So to go back to your idea of a non-email activity as a requirement to open up a new email communication link... this is not an unreasonable scenario as this was the way SMTP email in 1981 used to work. Before the general public accessed the internet in the 1990s, the email system didn't have a massive spam problem because the non-email activity to prevent it was being hired by University of XYZ that was part of the network linked by National Science Foundation. (That researcher had ".edu" address.) Or the person wanting to send an email was a government worker in the Department of Defense. (That government worker had a ".mil" address.) So any new email users were already vetted by the hiring procedures of universities and United States government. It's like an ancient form of "social proof" without Facebook/LinkedIn/etc. As a consequence, a researcher "bob@xyz.edu" sending a new email to "alice@darpa.mil" -- was not likely to be spam. (Similar to users noticing that their company Slack channel doesn't have spam. Yes, it's because the people talking to you on Slack had to be hired first and therefore, your coworkers are unlikely to send you spam.)

But now that email is "opened up to everybody" -- including the spammers, the "hiring procedures" as the non-email activity to prevent spam doesn't scale up for a billion new users. So your proposal tries to re-create a barrier again... instead of University of Illinois vetting you before giving you an ".edu" email address, the similar idea for modern times is to have something like Facebook "vet" you with their sign-on credentials before revealing some random generated per-contact email address.

To summarize the meta categories of solutions for email spam:

- outside of email universe solutions: non-SMTP non-email activity prerequisite such as 3rd-party entity "social proof": e.g. 1980s old days of being hired by USA government or educational institution, or today's proposal of 3rd-party SSO credentials from centralized websites such as Facebook

- inside the email universe solutions: proof-of-work, Bayesian text filtering, domain and ip reputation blacklists, etc

(But domain and ip reputation blacklists solutions can arguably be categorized as "outside" of email system because it requires a big entity that can scan millions/billions of email traffic to create the blacklists. A residential SMTP server sending a new email to another residential SMTP server won't have that reputation list.)