Ahoj! I’m hoping to do to SMTP servers something similar that you do to email clients. I’ve got a basic SMTP server working - written in Rust and many ideas how to leverage existing SMTP infrastructure and standards. A social network or micro blogging could be built on top of emails. Federating e-mail with the Fediverse could be the last drop to win people away from the established corporate solutions. And delta chat looks great. Installing now on tablet and desktop.
One feature I’d like to configure is instant contact request on the server. You have that feature on the client, now I think it could work on the server too. Scenario… Someone is sending me a message. SMTP server rejects politely for policy reasons (as in graylist), but the client is notified about the attempt, if on-line then instantly. User can chose to welcome or refuse the contact. He can refuse verbosely or quietly. Later, delivery is retried - as required by SMTP standards - and either received if welcome, refused if not, or again temporarily refused if the user hasn’t done anything.
Another feature I have in mind is encryption at rest. Client shares the public key to the SMTP server and the server encrypts all incoming mail for that key automatically. I imagine this could be done transparently to be compatible with existing mail clients. With a clever support from the client it could be completely seamless to the user.
Another feature I have in mind is automatic account creation. You’ll send a signed message to say accounts@mydomain.chat with a command to claim the addresses included. The server automatically provisions an account for you and you could even authenticate using the private key… Registration fee could be included. In response to the claim message, the server could ask the user to send some bitcoins or what not otherwise drop the account after a week
Another feature I have in mind is that everyone runs their own mail server for their own domain on their tiny mobile devices or desktops + have a traditional SMTP for times offline. This could be coupled with dynamic DNS and standard MX prioritization. Providers would handout subdomains for this purpose.
Ideas are many, developer only one. Opinions, hints?
Thank you
Do you know about DIME? The idea is very similar. But just saving the key from outgoing Autocrypt headers and encrypting everything that is not encrypted seems more realistic than replacing email protocols both in servers and clients of course.
First time I hear about it. It is a huge spec and an ambicious project. From the first look it seems like out with the old, in with the new. I like the simplicity of SMTP along with it’s nuisance. There are indeed serious security flaws built in, slowly being addressed (DANE or MTA-STS or STARTTLS everywhere…) Well, I I think an incremental change is more likely to succeed. For instance, the next step for me personally is to refuse any relayed mail if not sent after STARTTLS. Small step for me, huge leap for mankind. I will say “Are you nuts? Out there in the plain text?”
Nice, got down to it. I’ve added consistent streaming API which could be used in Samotop. There was a possibility to send body as a reader, but there were still big memory copies in some Transport implementations. And it wouldn’t suit the model in Samotop where mail service return a sink to write to. Taking the reader in would mean taking the incoming TCP stream and I need that Please review, I can adjust. It is bulky, I had to move a few things around to actually maintain the current API and fit the new one. Feature/jo/#33 streaming api by jocutajar · Pull Request #34 · async-email/async-smtp · GitHub
Please review, I can adjust. It is bulky, I had to move a few things around to actually maintain the current API and fit the new one.