starred/anonaddy

Fork 0

mirror of https://github.com/anonaddy/anonaddy.git synced 2026-04-24 21:55:52 +03:00

subject details) + faster email composition #1106

New issue

Open

opened 2026-03-14 11:44:49 +03:00 by kerem · 4 comments

kerem commented

2026-03-14 11:44:49 +03:00

Owner

Originally created by @lawmanuk on GitHub (Nov 8, 2025).
Original GitHub issue: https://github.com/anonaddy/anonaddy/issues/787

At the moment, to create an email address we have to put email 1 into the addy app to create email 1a (which adds the email prefix/suffix). then copy/paste that into our email client.

Its quite an inefficient process when you have several emails to add.

Could you following be considered instead:

Add a header start/end at top of outgoing email. eg.
--- addy start ---
--- addy end ---
Then everything inbetween can have specific instructions to confirm which alias to use and which email address to send to (with auto translate)
eg.
--- addy start ---
alias: xxx@xxx.addy.io
to: aaa@aaa.com
cc: bbb@bbb.com
bcc: ccc@ccc.com
read receipt: yes
deliver receipt: yes
--- addy end ---

then send above encrypted to mailer@anonaddy.com

subject can be left as is if recipient has pgp key and using encrypted subject in thunderbird.
If recipient doesn't have pgp key then additional line which can be inserted into subject when forwarding to external recipient:
subject: this is the subject

mailer could then do the email formatting translation itself and delete everything inbetween 'addy start' and 'addy end'. It already does this when removing addy header showing which alias is being used.

Additionally, when we recieve incoming emails stating which alias has been used, I have to manually deleted these in my response.
If they were between 'addy start' and 'addy end', then they could automatically be deleted by addy mailer.
This is also more private, as my google mail server would only then see in sent items:
a) all messages going to mailer@addy.io without knowing which further emails they are going to - hiding the metadata
b) all messages in sent would be encrypted to mailer@addy.io

Please let me know if this is an option you would consider.

thanks

Originally created by @lawmanuk on GitHub (Nov 8, 2025). Original GitHub issue: https://github.com/anonaddy/anonaddy/issues/787 At the moment, to create an email address we have to put email 1 into the addy app to create email 1a (which adds the email prefix/suffix). then copy/paste that into our email client. Its quite an inefficient process when you have several emails to add. Could you following be considered instead: 1. Add a header start/end at top of outgoing email. eg. --- addy start --- --- addy end --- 2. Then everything inbetween can have specific instructions to confirm which alias to use and which email address to send to (with auto translate) eg. --- addy start --- alias: xxx@xxx.addy.io to: aaa@aaa.com cc: bbb@bbb.com bcc: ccc@ccc.com read receipt: yes deliver receipt: yes --- addy end --- then send above encrypted to mailer@anonaddy.com subject can be left as is if recipient has pgp key and using encrypted subject in thunderbird. If recipient doesn't have pgp key then additional line which can be inserted into subject when forwarding to external recipient: subject: this is the subject mailer could then do the email formatting translation itself and delete everything inbetween 'addy start' and 'addy end'. It already does this when removing addy header showing which alias is being used. 3. Additionally, when we recieve incoming emails stating which alias has been used, I have to manually deleted these in my response. If they were between 'addy start' and 'addy end', then they could automatically be deleted by addy mailer. 4. This is also more private, as my google mail server would only then see in sent items: a) all messages going to mailer@addy.io without knowing which further emails they are going to - hiding the metadata b) all messages in sent would be encrypted to mailer@addy.io Please let me know if this is an option you would consider. thanks

kerem commented

2026-03-14 11:44:55 +03:00

Author

Owner

@Nexus6 commented on GitHub (Nov 10, 2025):

I think this would be interesting to think about. I like the idea of moving metadata that is essentially instructions to Addy, out of plaintext headers and out of SMTP protocol exchanges ("RCPT TO: ...") and into encrypted bodyparts. What you're suggesting would create a small out-of-band API for telling Addy what you want it to do with a particular outgoing email, but might be generalized to a control protocol of sorts. For example, you might imagine using something like this to tell Addy to delete an alias.

I can imagine the objection that rummaging through the outbound message body complicates the code, will be a source of end-user errors, and that Addy shouldn't be allowed to interpret/act on message body content. As for the latter, Addy already does this in a way when it injects error messages/warnings into inbound email. Another objection would be that an implementation of this feature would come with new security risks which is no doubt true. It's still interesting to think about - what "control" functions could be implemented and how security issues could be mitigated.

@Nexus6 commented on GitHub (Nov 10, 2025): I think this would be interesting to think about. I like the idea of moving metadata that is essentially instructions to Addy, out of plaintext headers and out of SMTP protocol exchanges ("RCPT TO: ...") and into encrypted bodyparts. What you're suggesting would create a small out-of-band API for telling Addy what you want it to do with a particular outgoing email, but might be generalized to a control protocol of sorts. For example, you might imagine using something like this to tell Addy to delete an alias. I can imagine the objection that rummaging through the outbound message body complicates the code, will be a source of end-user errors, and that Addy shouldn't be allowed to interpret/act on message body content. As for the latter, Addy already does this in a way when it injects error messages/warnings into inbound email. Another objection would be that an implementation of this feature would come with new security risks which is no doubt true. It's still interesting to think about - what "control" functions could be implemented and how security issues could be mitigated.

kerem commented

2026-03-14 11:45:00 +03:00

Author

Owner

@lawmanuk commented on GitHub (Jan 15, 2026):

Just bumping this up for attention. thanks

@lawmanuk commented on GitHub (Jan 15, 2026): Just bumping this up for attention. thanks

kerem commented

2026-03-14 11:45:05 +03:00

Author

Owner

@lawmanuk commented on GitHub (Feb 10, 2026):

Bumping to get Will's view on this. thx

@lawmanuk commented on GitHub (Feb 10, 2026): Bumping to get Will's view on this. thx

kerem commented

2026-03-14 11:45:10 +03:00

Author

Owner

@willbrowningme commented on GitHub (Feb 10, 2026):

Thanks, interesting idea that would require a fair bit of work to implement.

I have too much on my todo list to look at this properly right now.

@willbrowningme commented on GitHub (Feb 10, 2026): Thanks, interesting idea that would require a fair bit of work to implement. I have too much on my todo list to look at this properly right now.

No labels

bug

pull-request

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/anonaddy#1106

No description provided.

Rows
Columns