On Tue, Jun 21, 2022 at 5:34 PM John Levine wrote: > I think you underestimate the persistence and bad faith of spammers.
I certainly don't. > That also doesn't scale. There are at least 100,000 mail systems on > the Internet. How many complaints per second are you prepared to > investigate and respond to? I actually don't see how this is any different from what we have now. The problem is that you cannot automate reputation repairs. We recently had to change IPs, and we got a couple of "bad" ones. To correct the problems involved lots of emails, including to this list. If we assume there are 10,000 people on this list, that's 10,000 people who were disturbed by my request to have my IP cleared. That's not quite an N^2 problem but close. If there are only 1,000, it still doesn't matter. It's not an efficient way to get problems fixed. Dave Crocker writes similarly: > 1. Please explain what you mean by a "public trust model". Right now, someone can send a million messages to abuse@, postmaster@, etc., and all those complaints are unauthenticated. Switch to a cheaper, authenticated method that requires the sender to connect to an out-of-band port with a valid public/private key pair. This is expensive to generate, even in the cheapest way, so it would slow down the senders who try to generate a key per complaint or message. Require the sender to authenticate the first time via this port through a challenge-reponse that includes a delay, say, to slow down registrations further. As to the size of the database, 100K per ADMD is tiny in comparison to the amount of spam sent to our servers. Every message must be signed, or it goes through old style reputation analysis, or it could be just rejected. The From: domain must point to the public key just like ARC and DKIM. Each sender has a reputation of some sort. The receiving server can choose to initialize it at any level. There could be bootstrap reputation services that receivers trust, similar to the web of trust, to allow you to buy a higher reputation. Currently, services like the SES and SendGrid do this in a way, but you can't transfer reputation, because it is attached to their IPs. If the message is rejected, there's a link in the message that says how to correct the error. One of the errors is "low reputation", possibly with a score. To improve the reputation, the sender returns the message to the originator or postpones it like it was greylisted. The receiver is expected to operate in good faith as they are today to accept and deliver mail. When a user complains to the receiver, the key gets docked. No need to send an FBL, although that could be still in place. Spam analysis can dock reputation. Whatever the receiver wants, really, as long as they support the reputation protocol to allow for complaints and ways to improve reputation (web of trust). The main difference with the current system is that a sender can check their reputation quickly and easily. There might even be a way to check reputation for any sender. A sender can issue a complaint against their key with an explanation. This happens today, but it's a different out-of-band protocol for each receiver, or you sign up for a service to fix it for you. Perhaps this has been discussed and discarded. I am not a domain expert. Please tear it apart. Dave Crocker continues: > The existing repertoire of relevant email tech specs are for > authentication, except for SPF, which includes authorization of SMTP > client engines, and DMARC, which include rfc5321.From field domain name > authorization. Here's how NIST defines authentication <https://csrc.nist.gov/glossary/term/authentication>: "Verifying the identity of a user, process, or device, often as a prerequisite to allowing access to resources in an information system." I don't want to quibble on semantics, but I bring this up to point out that a key verifies a "process" (a mail server). The sending process is authorized if the key is registered, passes challenge-response, and has a good reputation in the receiver's system. If you are naive, you accept all messages from Google. If you aren't, you process all messages through complex reputation analysis. Or, you ask a reputation service, programmatically, just like today, but with true authentication. What about system compromises? Same as today. You better keep your key private. If your key gets stolen, you can cancel all your registrations. That works today, but it depends on a TTL instead of being transactional. There are at most 100K ADMD's according to one poster. That's expensive but doable, and again, agencies could offer this service, because it wouldn't require a gaggle of people to accumulate the knowledge. You would know programmatically which ADMD's you registered with and how to deregister, because it is based on a public protocol. Dave Crocker continues: > These are not intended to solve a more general need for > trust, but to lay a foundation for useful reputation analysis. This assumes one has enough data. We don't. We use Postgrey, SpamAssassin, and a few other simple tricks. Anything more sophisticated would sink my business, because email is ancillary but required for what we do. With this solution, the server can ask around about the reputation when the spammer registers. Maybe Google would offer its reputation database for free for limited api requests like it does for Maps. There would be reputation trackers for a fee, like today. The difference is that reputation would be protocol-based. Again, I am not an expert. Just my $.02. Rob
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
