# SMTP server Samotop **URL:** \ **Category:** Uncategorized\ **Created:** [August 25, 2020, 7:48pm UTC](https://support.delta.chat/t/smtp-server-samotop/1177 "2020-08-25T19:48:29Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![jocutajar](https://support.delta.chat/letter_avatar_proxy/v4/letter/j/5f8ce5/32.png) [@jocutajar](https://support.delta.chat/u/jocutajar)\ **Post date:** [August 25, 2020, 7:48pm UTC](https://support.delta.chat/t/smtp-server-samotop/1177/1 "2020-08-25T19:48:29Z")
Ahoj! I’m hoping to do to SMTP servers something similar that you do to email clients. I’ve got a basic [SMTP server](https://crates.io/crates/samotop-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](mailto: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 ---
**Author:** ![link2xt](https://support.delta.chat/user_avatar/support.delta.chat/link2xt/32/1971_2.png) [@link2xt](https://support.delta.chat/u/link2xt)\ **Post date:** [August 25, 2020, 9:28pm UTC](https://support.delta.chat/t/smtp-server-samotop/1177/2 "2020-08-25T21:28:55Z")
> [@jocutajar](#): > > 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. Do you know about [DIME](https://darkmail.info/)? The idea is very similar. But just saving the key from outgoing [Autocrypt](https://autocrypt.org/) headers and encrypting everything that is not encrypted seems more realistic than replacing email protocols both in servers and clients of course. > [@jocutajar](#): > > Another feature I have in mind is automatic account creation. You’ll send a signed message to say [accounts@mydomain.chat](mailto: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 🙂 Delta Chat already has “burner accounts” feature, which is essentially an automatic creation of accounts via HTTPS request to URL encoded in QR-code. Server side code is in [GitHub - deltachat/mailadm: mail account administration tool for temporary and other account creation/modification](https://github.com/deltachat/mailadm) > [@jocutajar](#): > > 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. There is another thread with a similar idea: > [@LAN-decentralized-no-internet setup: mDNS + SMTP-server (postfix) + delta.chat (+ IMAP-server (dovecot)?)](https://support.delta.chat/t/lan-decentralized-no-internet-setup-mdns-smtp-server-postfix-delta-chat-imap-server-dovecot/583): > > I managed to run host1 .local and host2 .local using mDNS and each participant using its own simple-lightweight SMTP mail server, some details [1] Then, now there is a possible setup-use case where you can use email in the same LAN, because thunderbird and claws mail allow to use a localhost mailbox (specifically, in file /var/mail/myuser). Next think I thought was to have a “decentralized chat” that would be possible if delta .chat manages the localhost mailbox. I tried to login with myuser@l… ---
**Author:** ![link2xt](https://support.delta.chat/user_avatar/support.delta.chat/link2xt/32/1971_2.png) [@link2xt](https://support.delta.chat/u/link2xt)\ **Post date:** [August 25, 2020, 9:35pm UTC](https://support.delta.chat/t/smtp-server-samotop/1177/3 "2020-08-25T21:35:23Z")
> [@jocutajar](#): > > I’ve got a basic [SMTP server](https://crates.io/crates/samotop-server) working - written in Rust and many ideas how to leverage existing SMTP infrastructure and standards. Delta Chat SMTP (and IMAP) networking code is in [async-email · GitHub](https://github.com/async-email/), and there is [GitHub - rpgp/rpgp: Pure rust implementation of OpenPGP](https://github.com/rpgp/rpgp) library for OpenPGP built for Delta Chat, maybe you can use some of this code for SMTP relaying and at rest encryption. ---
**Author:** ![jocutajar](https://support.delta.chat/letter_avatar_proxy/v4/letter/j/5f8ce5/32.png) [@jocutajar](https://support.delta.chat/u/jocutajar)\ **Post date:** [August 26, 2020, 12:00am UTC](https://support.delta.chat/t/smtp-server-samotop/1177/4 "2020-08-26T00:00:25Z")
> [@link2xt](#): > > Do you know about [DIME](https://darkmail.info/)? 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](https://tools.ietf.org/html/rfc7672) 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?” ---
**Author:** ![jocutajar](https://support.delta.chat/letter_avatar_proxy/v4/letter/j/5f8ce5/32.png) [@jocutajar](https://support.delta.chat/u/jocutajar)\ **Post date:** [August 29, 2020, 2:11am UTC](https://support.delta.chat/t/smtp-server-samotop/1177/5 "2020-08-29T02:11:38Z")
> [@link2xt](#): > > Delta Chat SMTP (and IMAP) networking code is in [https://github.com/async-email/](https://github.com/async-email/) 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](https://github.com/async-email/async-smtp/pull/34) ---
**Author:** ![robertnn](https://support.delta.chat/letter_avatar_proxy/v4/letter/r/9f8e36/32.png) [@robertnn](https://support.delta.chat/u/robertnn)\ **Post date:** [January 15, 2025, 1:30pm UTC](https://support.delta.chat/t/smtp-server-samotop/1177/6 "2025-01-15T13:30:39Z")
The **instant contact request feature** with SMTP graylisting is a clever way to give users control. **Encryption at rest** using public keys is a solid privacy enhancement. **Automatic account creation** with signed messages and fees could streamline registration. Lastly, running **personal mail servers on mobile devices** and desktops is a fascinating idea for decentralizing email. It’s a lot to work through, but these ideas could change the way email is managed with **SMTP servers** like **SMTPmart** , **Brevo** and **SMTPget**! ---
**Author:** ![link2xt](https://support.delta.chat/user_avatar/support.delta.chat/link2xt/32/1971_2.png) [@link2xt](https://support.delta.chat/u/link2xt)\ **Post date:** [January 15, 2025, 1:33pm UTC](https://support.delta.chat/t/smtp-server-samotop/1177/7 "2025-01-15T13:33:03Z")
[Samotop](https://gitlab.com/BrightOpen/Samotop) is deprecated in favor of [Stalwart](https://stalw.art/). > [@robertnn](#): > > It’s a lot to work through, but these ideas could change the way email is managed with **SMTP servers** like **SMTPmart** , **Brevo** and **SMTPget**! These “SMTP servers” are actually SMTP _services_ that allow you to send but not receive messages. ---
**Author:** ![Minim](https://support.delta.chat/letter_avatar_proxy/v4/letter/m/ccd318/32.png) [@Minim](https://support.delta.chat/u/Minim)\ **Post date:** [January 21, 2025, 6:14pm UTC](https://support.delta.chat/t/smtp-server-samotop/1177/9 "2025-01-21T18:14:44Z")
I haven’t heard about DIME for about a decade. Hope it’s doing well… As I recall, it opportunistically upgrades e-mail comms to a form onion routing, when the sender’s server knows the sender and the receiving server, but doesn’t know the recipient, the recipient’s server similarly doesn’t know the sender, and neither server knows the header. This would work well for Chatmail servers, which often talk to each other and E2EE clients.