someone flagged/reported it as spam, so it was hidden at first until a moderator rejected the flag.
Hi @Simon! The scenario @gerryfrancis described seems it could be a pretty common one actually (and one that I have encountered as well), lets call it “single account, multiple address, single identity”. This is different from what is described in “using delta chat with sub-addresses”, which would allow you to consider only emails sent to a special email alias as valid conversations by leveraging server configured filters. I should point out that this use case is also different from being able to have multiple identities as described by @Eric2602, who has a “single account, multiple address, multiple identities” need.
I’ll give an example to clarify @gerryfrancis’s request. Say you’re a student who graduated from a school and your school provides you with email forwarding for life from an alumni address (gerry@alumni.example.edu) and an SMTP server for sending from that address.
Under this example gerry would configures alumni email at alumni.example.edu to forward to personal inbox (gerry@example.com) and it should be considered “same identity, different address”. On example.com’s web interface, gerry sets up outgoing configuration to either send from gerry@example.com or gerry@alumni.example.edu.
On the web interface, gerry receives emails sent to both gerry@example.com and gerry@alumni.example.edu and can reply as either address.
Right now, if Delta connects to gerry@example.com, an email sent from sender@example.org to gerry@alumni.example.edu will be considered as a group chat with three addresses (sender@example.org, gerry@example.com, gerry@alumni.example.edu). Additionally, Delta can only send as gerry@example.com.
To provide proper support for aliases in the Delta interface the following changes would need to be made:
- on the receiving end, Delta would understand that for emails sent to gerry@alumni.example.edu, it should consider that address as “me” and would show as conversation between “me” and sender@example.org.
- on the sending end (please keep in mind this is an assumption given my limited understanding of the smtp protocol), Delta would send to smtp.example.com with from email address gerry@alumni.example.edu but as identity of gerry@example.com. the server would understand that the user was sending AS gerry@alumni and connect with the alumni.example.edu server to properly send the email, or send on behalf of it with the appropriate headers depending on configuration. If a new conversation is started, the user should, under this design, be able to select the appropriate from address to start a conversation.
If the outgoing configuration isn’t tied deeply to the Delta interface (I haven’t tried it yet but I assume it is given email address as identity interface) its possible for outgoing the user could add additional sender configurations where Delta connects directly to the SMTP server of choice with user provided configuration instead of using the “alias” approach described above, which relies on the example.com server to do the legwork.
I hope this helps!