> The server-hosted software would never see the actual emails; it would just manage the provision of email service

...

> If the service was responsibly run, it could even "vouch" somehow for the email inboxes it provisions. So even though the emails come from, like, Comcast ISP address space, other ISPs would recognize a trustworthy source of email. (Dynamic IP provision would complicate this part.)

If you are willing to to let the server-hosted software have some visibility into your mail traffic (but not the content), there's a way to handle this that would not have problems with dynamic IP addresses [1].

Briefly, whenever your email client needs to send a mail through your Comcast outgoing SMTP service, it would first contact the vouching service and provide a hash of the message ID of the message it is about to send (and maybe the from address?).

The vouching service would verify that it is talking to one of its legitimate customers, and then return a line for the client to put in the header of the outgoing mail. This line would contain a copy of the message ID hash (and from address?), a timestamp, the client IP address, and would be signed using a key of the vouching service.

The client puts that line in the header and sends the mail through Comcast.

The SMTP server that Comcast relays it to can look at that line, check the signature, and if it verifies it can compare the information in that line to the corresponding information in or derived from the rest of the header. If the information all matches and the timestamp is in the recent past, accept that the mail really came from the person it claims to be from.

This would give the vouching service get a good idea of how much email you send and when you send it, and also give them hashes of your message IDs, so it is not ideal.

A problem with this is this it depends on every SMTP service that Comcast might relay your mail to (such as the SMTP server for every domain you send mail to) being set up to verify the signature of the vouching service you use. This would be a pain in the ass.

This could be addressed by having the verification of the signature and header data done at your ISP's (e.g, Comcast's) SMTP service. That way you just have to pick a vouching service that Comcast recognizes.

Comcast would then do the check on your outgoing mail to see that you have used a vouching service they recognize and the data matches. They can then add a header that says they believe the mail is verified. For any mail that they cannot verify thusly, they can add a header that says it is not verified.

Now instead of having to know about and trust your vouching service, the SMTP servers of the domains you mail to just have to trust Comcast. That seems much more likely to come about.

If Comcast (and other residential ISPs) were willing to do this, why bother with third party vouching services? Why not handle the whole thing themselves?

One reason would be that providing vouching service requires getting more involved with the details of the customer's setup than an ISP might want to deal with. They might not want to have to deal with support questions dealing with how to get the vouching plugin or whatever working with the various email clients and operating systems customers use.

[1] Maybe...I've not sat down and tried to actually design the protocols for this. This is just off the cuff.