chatmail / chatmail/async-smtp

Streaming API for sending mail body

Open
#33 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Rust
Stars
74
Forks
16
PR merge metrics
No merged PRs in 30d

Description

Ahoj!

I've had the honor to dive into the code. It's great, but I thing putting the whole message into the heap is potentially troublesome. Not so much on the detla.chat client side I suppose, but on a tiny server with at most 500 MB memory, and emails easily as big as 50 MB, this design would not fly. I've checked the Transport implementations briefly and it seems we could add streaming API to all of them without breaking the current big body API which could then be based on the streaming API.

Current signature:

async fn send(&mut self, email: SendableEmail) -> SmtpResult;

Proposal (pseudo code):

async fn send(&mut self, email: SendableEmail) -> SmtpResult {
todo!("with default implementation using send_stream(...)")
}
async fn send_stream(&mut self, email: SendableEmailWithoutBody) -> Result, Error>;

pub trait MailStream : AsyncWrite {
/// this will take care of flushing, collecting the response and closing
async fn done(self) -> Resul;
}

It might work out without a breaking change. To back the case, here's my WIP [LMTP output for Samotop](https://gitlab.com/BrightOpen/BackYard/Samotop/-/blob/feature/lmtp/samotop-to-lmtp/src/lib.rs). Anyone can implement the `MailQueue`, it is part of the API. `MailQueue.mail(Envelope)` returns a sink for the mail data. This is then used by the server to write incoming mail body to. It is already implemented for the primitive `SimpleDirMail` and I'm dropping `futures::Sink` in favor of `AsyncWrite`. The traits are very similar, especially when it comes to bytes.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by reviewing the Transport implementations and the current send(&mut self, email: SendableEmail) API described in the issue. Compare the proposed streaming shape with the linked Samotop LMTP implementation and its MailQueue sink. Done means agreeing on and implementing a non-breaking streaming API across the transports, with the existing body API still supported.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
backend-api-design
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.