[GH-ISSUE #123 ] No support for CC/Reply-All? #141

Author

Owner

@willbrowningme commented on GitHub (Jan 27, 2021):

I will look into keeping the original "Cc:" header if it is present on forwarded emails.

However if you were to click "Reply All" on a forwarded email that kept the "Cc:" header then your real email address would be exposed to all those CC'd into the email.

@willbrowningme commented on GitHub (Jan 27, 2021): I will look into keeping the original "Cc:" header if it is present on forwarded emails. However if you were to click "Reply All" on a forwarded email that kept the "Cc:" header then your real email address would be exposed to all those CC'd into the email.

kerem commented

Author

Owner

@vlad-tim commented on GitHub (Jan 27, 2021):

I will look into keeping the original "Cc:" header if it is present on forwarded emails.

That would be helpful. Also, there is an edge case - if AnonAddy email alias itself was it Cc: originally and not in To:, then it's nice to know who was in To:.

However if you were to click "Reply All" on a forwarded email that kept the "Cc:" header then your real email address would be exposed to all those CC'd into the email.

Makes sense. Not sure how feasible it sounds, but I have been imagining encoding CC'ed recipients in To: header like this:

To: alias+to_recipient#first_cc_recipient#second_cc_recipient@example.com

Where to_recipient is something like recipient1=gmail.com, and first_cc_recipient is something like recipient2=gmail.com, etc. And no actual carbon copies are sent when replying from the real email address -- but AnonAddy decodes and rebuilds CC.

Curious to now what you think of this idea.

@vlad-tim commented on GitHub (Jan 27, 2021): > I will look into keeping the original "Cc:" header if it is present on forwarded emails. That would be helpful. Also, there is an edge case - if AnonAddy email alias itself was it `Cc:` originally and not in `To:`, then it's nice to know who was in `To:`. > However if you were to click "Reply All" on a forwarded email that kept the "Cc:" header then your real email address would be exposed to all those CC'd into the email. Makes sense. Not sure how feasible it sounds, but I have been imagining encoding CC'ed recipients in `To:` header like this: ``` To: alias+to_recipient#first_cc_recipient#second_cc_recipient@example.com ``` Where `to_recipient` is something like `recipient1=gmail.com`, and `first_cc_recipient` is something like `recipient2=gmail.com`, etc. And no actual carbon copies are sent when replying from the real email address -- but AnonAddy decodes and rebuilds CC. Curious to now what you think of this idea.

kerem commented

Author

Owner

@willbrowningme commented on GitHub (Jan 28, 2021):

That would be helpful. Also, there is an edge case - if AnonAddy email alias itself was it Cc: originally and not in To:, then it's nice to know who was in To:.

Interesting point, I'll see if I can sort that out.

The above does sound possible although I imagine it could get complicated depending on the number CC'd in etc. and will take a fair bit of testing to figure out the best way to implement. I can't promise anything for this any time soon I'm afraid.

@willbrowningme commented on GitHub (Jan 28, 2021): > That would be helpful. Also, there is an edge case - if AnonAddy email alias itself was it Cc: originally and not in To:, then it's nice to know who was in To:. Interesting point, I'll see if I can sort that out. The above does sound possible although I imagine it could get complicated depending on the number CC'd in etc. and will take a fair bit of testing to figure out the best way to implement. I can't promise anything for this any time soon I'm afraid.

kerem commented

Author

Owner

@akirayamamoto commented on GitHub (Aug 9, 2021):

I am also interested.

@akirayamamoto commented on GitHub (Aug 9, 2021): I am also interested.

kerem commented

Author

Owner

@Coderdude112 commented on GitHub (Oct 12, 2021):

Is there any update on this?

Or even a file I could look into modifying to make CC & Reply-All functionality work?

@Coderdude112 commented on GitHub (Oct 12, 2021): Is there any update on this? Or even a file I could look into modifying to make CC & Reply-All functionality work?

kerem commented

Author

Owner

@willbrowningme commented on GitHub (Oct 14, 2021):

I've got some other tasks I am working on first.

You could try adding $this->ccs = base64_encode($parser->getHeader('CC')); or similar to App/Models/EmailData.php and then access it from App/Mail/ForwardEmail.php adding the CC header to the forwarded message inside the ->withSwiftMessage(function ($message) use ($returnPath) { method.

@willbrowningme commented on GitHub (Oct 14, 2021): I've got some other tasks I am working on first. You could try adding `$this->ccs = base64_encode($parser->getHeader('CC'));` or similar to `App/Models/EmailData.php` and then access it from `App/Mail/ForwardEmail.php` adding the CC header to the forwarded message inside the `->withSwiftMessage(function ($message) use ($returnPath) {` method.

kerem commented

Author

Owner

@willbrowningme commented on GitHub (Nov 3, 2021):

Testing this out now, more complicated than I first thought but got some bits working so far.

@willbrowningme commented on GitHub (Nov 3, 2021): Testing this out now, more complicated than I first thought but got some bits working so far.

kerem commented

Author

Owner

@vlad-tim commented on GitHub (Nov 3, 2021):

I could help with testing.

@vlad-tim commented on GitHub (Nov 3, 2021): I could help with testing.

kerem commented

Author

Owner

@Coderdude112 commented on GitHub (Nov 4, 2021):

Me as well. I had made some progress but a hard dive corruption put a stop to that lol

@Coderdude112 commented on GitHub (Nov 4, 2021): Me as well. I had made some progress but a hard dive corruption put a stop to that lol

kerem commented

Author

Owner

@willbrowningme commented on GitHub (Nov 4, 2021):

On forwarded messages it will need to work like this:

Say the alias in question is alias@anonaddy.me and this alias is sent an email from sender@example.com that has cc@example.com CC'd into it.

AnonAddy will need to forward the message to the real email address of the user and also add in a CC header so that the user can click "reply-all" and see who else was CC'd in.

However the CC header that is added cannot just be cc@example.com otherwise clicking reply-all would send the message directly from their real email and expose it. So AnonAddy must replace the CC header with alias+cc=example.com@anonaddy.me, then when you click reply-all it will be sent to cc@example.com from the alias and not the real email address.

Now let's say the user clicks reply-all, the message will need to go from the user's real email address to alias+sender=example.com@anonaddy.me with alias+cc=example.com@anonaddy.me CC'd in, ensuring that their real email is not exposed.

AnonAddy will need to accept and process these two emails so that sender@example.com and cc@example.com both recieve them with the correct headers.

sender@example.com will need:

To: sender@example.com
Cc: cc@example.com

cc@example.com will also need:

To: sender@example.com
Cc: cc@example.com

That is where AnonAddy will need to swap the incoming CC header alias+cc=example.com@anonaddy.me to cc@example.com.

Can you see any issue with the above?

It obviously can get quite complicated depending on the number of Tos and CCs etc.

@willbrowningme commented on GitHub (Nov 4, 2021): On forwarded messages it will need to work like this: Say the alias in question is `alias@anonaddy.me` and this alias is sent an email from `sender@example.com` that has `cc@example.com` CC'd into it. AnonAddy will need to forward the message to the real email address of the user and also add in a CC header so that the user can click "reply-all" and see who else was CC'd in. However the CC header that is added cannot just be `cc@example.com` otherwise clicking reply-all would send the message directly from their real email and expose it. So AnonAddy must replace the CC header with `alias+cc=example.com@anonaddy.me`, then when you click reply-all it will be sent to `cc@example.com` from the alias and not the real email address. Now let's say the user clicks reply-all, the message will need to go from the user's real email address to `alias+sender=example.com@anonaddy.me` with `alias+cc=example.com@anonaddy.me` CC'd in, ensuring that their real email is not exposed. AnonAddy will need to accept and process these two emails so that `sender@example.com` and `cc@example.com` both recieve them with the correct headers. `sender@example.com` will need: ``` To: sender@example.com Cc: cc@example.com ``` `cc@example.com` will also need: ``` To: sender@example.com Cc: cc@example.com ``` That is where AnonAddy will need to swap the incoming CC header `alias+cc=example.com@anonaddy.me` to `cc@example.com`. Can you see any issue with the above? It obviously can get quite complicated depending on the number of Tos and CCs etc.

kerem commented

Author

Owner

@vlad-tim commented on GitHub (Nov 5, 2021):

I like the idea.

So, in your example, after the user clicks Reply all, anonaddy.me will receive 2 emails, and it will map each of those incoming emails to single, not 2, outgoing emails, right?

It obviously can get quite complicated depending on the number of Tos and CCs

Agree. I would verify the case with multiple Tos and CCs at the same time and alias@anonaddy.me can be within either of those groups.

Also, with this approach, it will be possible to add more people into CC when replying just by adding something this alias+cc2=example.com@anonaddy.me, correct?

@vlad-tim commented on GitHub (Nov 5, 2021): I like the idea. So, in your example, after the user clicks `Reply all`, `anonaddy.me` will receive 2 emails, and it will map each of those incoming emails to single, not 2, outgoing emails, right? > It obviously can get quite complicated depending on the number of Tos and CCs Agree. I would verify the case with multiple Tos and CCs at the same time and `alias@anonaddy.me` can be within either of those groups. Also, with this approach, it will be possible to add more people into CC when replying just by adding something this `alias+cc2=example.com@anonaddy.me`, correct?

kerem commented

Author

Owner

@Iizuki commented on GitHub (Nov 22, 2021):

I haven't used the banner feature for a while, but I take it that CCs are not listed there?

@Iizuki commented on GitHub (Nov 22, 2021): I haven't used the banner feature for a while, but I take it that CCs are not listed there?

kerem commented

Author

Owner

@Coderdude112 commented on GitHub (Nov 22, 2021):

@willbrowningme I don't see an issue with it though it could get very confusing fast. Maybe a helper tool like what is currently used for the "Send From" feature, but a little more versatile. Here are just some ideas

A single send from button instead of it being behind the three dots
Within the send from menu the user selects what alias they want to "send from" through a text box with a search function
A box for the "To" feild where the user can put multiple to addresses
A box for the "CC" feild where the user can put multiple CC addresses
And a convert to internal emails (Don't know of a better name for this, sorry)

Pressing the button at the bottom would change the dialogue to a box instructing the user on how to use the generated email addresses and where to put them.

I would also find it useful for CCs to be listed in the banner if it is not too much of a hassle

@Coderdude112 commented on GitHub (Nov 22, 2021): @willbrowningme I don't see an issue with it though it could get very confusing fast. Maybe a helper tool like what is currently used for the "Send From" feature, but a little more versatile. Here are just some ideas * A single send from button instead of it being behind the three dots * Within the send from menu the user selects what alias they want to "send from" through a text box with a search function * A box for the "To" feild where the user can put multiple to addresses * A box for the "CC" feild where the user can put multiple CC addresses * And a convert to internal emails (Don't know of a better name for this, sorry) Pressing the button at the bottom would change the dialogue to a box instructing the user on how to use the generated email addresses and where to put them. --- I would also find it useful for CCs to be listed in the banner if it is not too much of a hassle

kerem commented

Author

Owner

@willbrowningme commented on GitHub (Nov 26, 2021):

Okay for the first step I have just added new headers to forwarded emails. These headers are:

X-AnonAddy-Original-To
X-AnonAddy-Original-Cc

So you can view these headers which will show you who the original message was sent to and who was CC'd into it.

The next step I need to determine the best way to allow the user to click reply-all without revealing their real email to the other TOs and CCs.

I do like the idea of having the current send from address format able to allow multiple TOs and CCs however I believe the maximum email address length is 254 characters so I'm not sure this would work in practice.

The only other option is to give each TO and CC their own address e.g. alias+to=example.com@anonaddy.me, alias+cc1=example.com@anonaddy.me etc.

@willbrowningme commented on GitHub (Nov 26, 2021): Okay for the first step I have just added new headers to forwarded emails. These headers are: ``` X-AnonAddy-Original-To X-AnonAddy-Original-Cc ``` So you can view these headers which will show you who the original message was sent to and who was CC'd into it. The next step I need to determine the best way to allow the user to click reply-all without revealing their real email to the other TOs and CCs. I do like the idea of having the current send from address format able to allow multiple TOs and CCs however I believe the maximum email address length is 254 characters so I'm not sure this would work in practice. The only other option is to give each TO and CC their own address e.g. `alias+to=example.com@anonaddy.me`, `alias+cc1=example.com@anonaddy.me` etc.

kerem commented

Author

Owner

@vlad-tim commented on GitHub (Nov 26, 2021):

Another advantage of giving each TO and CC their own address instead of encoding multiple TOs and CCs in a single header is that excluding recipients when replying is more natural. Including new recipients is still a challenge anyway.

@vlad-tim commented on GitHub (Nov 26, 2021): Another advantage of giving each TO and CC their own address instead of encoding multiple TOs and CCs in a single header is that excluding recipients when replying is more natural. Including new recipients is still a challenge anyway.

kerem commented

Author

Owner

@leonardosegurat commented on GitHub (Mar 3, 2023):

Any update on this use case?

I was looking for the cc headers and they weren't present in the banner, or other visible info, when reading from a gmail sender account. But going trough the raw email with the "See original" feature led me to the headers, so no information lost.

Is there a way for this info to be added to the banner?

In it's current form, I am unsure whether replying to the email will send a reply to everyone involved, or just the sender address. AFAIK from reading this thread this remains unchanged, so I'm curious what the scenario is.

It would be nice to customize this behavior, but in the meantime, could the current behavior be added to the documentation?

@leonardosegurat commented on GitHub (Mar 3, 2023): Any update on this use case? I was looking for the cc headers and they weren't present in the banner, or other visible info, when reading from a gmail sender account. But going trough the raw email with the "See original" feature led me to the headers, so no information lost. Is there a way for this info to be added to the banner? In it's current form, I am unsure whether replying to the email will send a reply to everyone involved, or just the sender address. AFAIK from reading this thread this remains unchanged, so I'm curious what the scenario is. It would be nice to customize this behavior, but in the meantime, could the current behavior be added to the documentation?

kerem commented

Author

Owner

@leonardosegurat commented on GitHub (May 17, 2023):

Just thought of a way to make it work. Instead of using the actual email's headers, it could be done inside the emai's body in the Anonaddy Banner.

So, instead of the email body containing:

This email was sent to alias@example.com from sender@company.com
Click here to deactivate this alias

It could be implemented like this:

This email was sent to alias@example.com from sender@company.com
With CC: cc1@company.com, cc2@company.com
Click here to deactivate this alias
You may customize your response here:
To: sender@company.com
CC: cc1@company.com, cc2@company.com
BCC:
This fields are populated automatically, with default behavior reply all . Click here to change this behavior

This yields the following benefits:

Only one message needs to be sent from recipient to anonaddy, containing all info
Email body can be encrypted, so CC's are not exposed in transit between reciever email and anonaddy server
There's already an implementation for adding and removing Anonaddy banners to the email's body, so managing them would be simple
This implementation works regardless of the recipient client, as any email client can modify the body of the email

The issue I find with this approach is a user accidentally deleting the start or the end of the Anonaddy banner, making it look like part of the email and exposing info about the alias, such as deactivation URL. But I figure this could be handled with some clever formatting, or validation on anonaddy's side, so that if the quoted email does not contain an Anonaddy banner the whole message gets aborted and the user notified.

Default behavior could be to populate this fields for a simple reply, reply all, or to always ask and leave them blank. Note that this approach could allow a user to have multiple "to" addresses, defined at the email body / Anonaddy banner level, making the recipient syntax redundant as the email could simply be sent to alias@domain.com with the appropriate info. Now, this would not work as well if trying to filter from the client's side unless there's some sort of tagging that can be done automatically at the email client level.

Does this make sense? I'm mostly thinking out loud, so please let me know what y'all think.

Edit notes: For this post I originally used header / banner interchangeably, as I didn't know the appropriate syntax. I'm still learning the specifics so apologies for any confusion.

@leonardosegurat commented on GitHub (May 17, 2023): Just thought of a way to make it work. Instead of using the actual email's headers, it could be done inside the emai's body in the _Anonaddy Banner_. So, instead of the email **body** containing: > This email was sent to alias@example.com from [sender@company.com](mailto:sender@company.com) > Click [here](deactivation_URL) to deactivate this alias It could be implemented like this: > This email was sent to alias@example.com from [sender@company.com](mailto:sender@company.com) > With CC: [cc1@company.com](cc1@company.com), [cc2@company.com](cc2@company.com) > Click [here](deactivation_URL) to deactivate this alias > You may customize your response here: > To: sender@company.com > CC: cc1@company.com, cc2@company.com > BCC: > This fields are populated automatically, with default behavior **_reply all_** . Click [here](alias_settings) to change this behavior This yields the following benefits: - Only one message needs to be sent from recipient to anonaddy, containing all info - Email body can be encrypted, so CC's are not exposed in transit between reciever email and anonaddy server - There's already an implementation for adding and removing _Anonaddy banners_ to the email's body, so managing them would be simple - This implementation works regardless of the recipient client, as any email client can modify the body of the email The issue I find with this approach is a user accidentally deleting the start or the end of the _Anonaddy banner_, making it look like part of the email and exposing info about the alias, such as deactivation URL. But I figure this could be handled with some clever formatting, or validation on anonaddy's side, so that if the quoted email does not contain an _Anonaddy banner_ the whole message gets aborted and the user notified. Default behavior could be to populate this fields for a simple reply, reply all, or to always ask and leave them blank. Note that this approach could allow a user to have multiple "to" addresses, defined at the email body / _Anonaddy banner_ level, making the recipient syntax redundant as the email could simply be sent to alias@domain.com with the appropriate info. Now, this would not work as well if trying to filter from the client's side unless there's some sort of tagging that can be done automatically at the email client level. Does this make sense? I'm mostly thinking out loud, so please let me know what y'all think. Edit notes: For this post I originally used header / banner interchangeably, as I didn't know the appropriate syntax. I'm still learning the specifics so apologies for any confusion.

kerem commented

Author

Owner

@jaron-l commented on GitHub (May 23, 2023):

I think this is a great idea. What would happen if the reply to address syntax didn't overlap with the body content information? Just concatenate them?

@jaron-l commented on GitHub (May 23, 2023): I think this is a great idea. What would happen if the reply to address syntax didn't overlap with the body content information? Just concatenate them?

kerem commented

Author

Owner

@leonardosegurat commented on GitHub (Jun 2, 2023):

Honestly, I'd go for using one or the other.

Either default to the existing implementation if anonaddy syntax is detected, or use the header if the message is sent straight to your alias (perhaps even have a dedicated sending alias).

Logic for an email being sent to a plain alias would be:
If email was NOT sent from a verified recipient, forward as usual. Else, check for a header and follow instructions if present.

I think this is a great idea. What would happen if the reply to address syntax didn't overlap with the body content information? Just concatenate them?

Only scenario that I can think of playing well with current implementation would be if you had a single recipient (alias+contact=theirdomain.com@yourdomain.com), and different addresses on the banner. For this specific scenario, I lean more towards ignoring the TO: address as a user might delete a recipient from the banner and forget to modify the recipient.

The more I look into it the more ideas come out, but I know this are all major changes so I'm trying to think of the best solution without breaking the existing implementation.

So far, here's what I've come up with:

Have a dedicated address to route all your email trough. For example, routing@mydomain.com. Ideally, you'd be able to change this address.
Have an input banner showing the information about the email you received in your alias (recipients, CC's, reply-to, flags, etc.)
Have an output banner where you can configure the email you'll send (sender, recipients, CC's, reply-to, flags, etc.
If you send an email to routing@mydomain.com without an output banner, you'll receive one back with a blank output banner so that you can use it to send the message (in case the app/extension is unavailable)

Benefits:

If an encrypted email was intercepted between you and Anonaddy Server, only your routing address would be compromised as the output banner would be encrypted.
Users would be able to type emails in their natural syntax.

Compromises for this solution:

This approach depends on sending instructions trough the banner, so disabling it would hinder a user's ability to cc/reply-all
You would no longer be able to filter emails by sender, recipient, or CC's as this information would be encoded into the banner and not necessarily searchable.

Potential workaround:

A whole tangent thinking of how to make this searchable

So, we have a way of getting data form our authorized recipient address to our anonaddy server, and we can get information from anonaddy servers to our recipient address. Now we just need to make those emails indexable by our recipient address provider (RAP). Something something text tags and email rules, but that would be RAP-specific and might lead to false positives so it's not ideal.

But what if we use a second alias to handle it? Example in detail:

Email recieved by Anonaddy server:

From: contact@company1.com
To: alias@mydomain.com, ana@company2.com
CC: bob@company1.com, chris@company2.com

Email forwarded to recipient address:

From: routing@mydomain.com
To: recipient@generic.com, ana=company2.com@tag.mydomain.com
CC: bob=company1.com@tag.mydomain.com, chris=company2@tag.mydomain.com

Blackhole everything from the second domain and boom! Now we've got multiple recipients and CC's in their place from RAP's perspective and can unambiguously filter them.

Agh, nevermind. We're missing the "from" field.

Ok, one more try for indexable emails:

Keep existing syntax for the "from:" field.
Use said syntax to add other recipients and/or CC's, but use tag domain instead.
Blackhole everything going to the tag domain and use the metadata from the reply to original sender to modify the message, no need for waiting periods.
On RAP, you can filter by email using tag domain
Figure out BCC later.

Problem with this one is you'll have duplicate addresses, depending on if they were a sender or a CC.

Overall, this are the candidate solutions as far as I understand:

Use the banner method but sacrifice indexability on RAP
Use the tag domain method but have potential duplicates
Use anonaddy's existing syntax implementation (AESI) and enforce a waiting period before forwarding

Yeah, this is harder than I first thought (and I'm not even looking at the code).
I can see the banner method working if you use your RA exclusively with anonaddy, so that searching for an email address would yield the emails written on the banner. Or with some sort of integration to tag or modify emails on your RAP.

Still thinking out loud. I hope this makes at least some sense lol. The more I try to solve it the more complex the solution turns for the end user, but the goal would be to make it as simple as possible to prevent errors from leaking PI.

@leonardosegurat commented on GitHub (Jun 2, 2023): Honestly, I'd go for using one or the other. Either default to the existing implementation if anonaddy syntax is detected, or use the header if the message is sent straight to your alias (perhaps even have a dedicated sending alias). Logic for an email being sent to a plain alias would be: If email was NOT sent from a verified recipient, forward as usual. Else, check for a header and follow instructions if present. >I think this is a great idea. What would happen if the reply to address syntax didn't overlap with the body content information? Just concatenate them? Only scenario that I can think of playing well with current implementation would be if you had a single recipient (alias+contact=theirdomain.com@yourdomain.com), and different addresses on the banner. For this specific scenario, I lean more towards ignoring the TO: address as a user might delete a recipient from the banner and forget to modify the recipient. The more I look into it the more ideas come out, but I know this are all major changes so I'm trying to think of the best solution without breaking the existing implementation. So far, here's what I've come up with: - Have a dedicated address to route all your email trough. For example, routing@mydomain.com. Ideally, you'd be able to change this address. - Have an input banner showing the information about the email you received in your alias (recipients, CC's, reply-to, flags, etc.) - Have an output banner where you can configure the email you'll send (sender, recipients, CC's, reply-to, flags, etc. - If you send an email to routing@mydomain.com without an output banner, you'll receive one back with a blank output banner so that you can use it to send the message (in case the app/extension is unavailable) Benefits: - If an encrypted email was intercepted between you and Anonaddy Server, only your routing address would be compromised as the output banner would be encrypted. - Users would be able to type emails in their natural syntax. Compromises for this solution: - This approach depends on sending instructions trough the banner, so disabling it would hinder a user's ability to cc/reply-all - You would no longer be able to filter emails by sender, recipient, or CC's as this information would be encoded into the banner and not necessarily searchable. Potential workaround: <details> <summary>A whole tangent thinking of how to make this searchable</summary> So, we have a way of getting data form our authorized recipient address to our anonaddy server, and we can get information from anonaddy servers to our recipient address. Now we just need to make those emails indexable by our recipient address provider (RAP). Something something text tags and email rules, but that would be RAP-specific and might lead to false positives so it's not ideal. <details> <summary>But what if we use a second alias to handle it? Example in detail:</summary> Email recieved by Anonaddy server: >From: contact@company1.com To: alias@mydomain.com, ana@company2.com CC: bob@company1.com, chris@company2.com Email forwarded to recipient address: >From: routing@mydomain.com To: recipient@generic.com, ana=company2.com@tag.mydomain.com CC: bob=company1.com@tag.mydomain.com, chris=company2@tag.mydomain.com Blackhole everything from the second domain and boom! Now we've got multiple recipients and CC's in their place from RAP's perspective and can unambiguously filter them. </details> Agh, nevermind. We're missing the "from" field. Ok, one more try for indexable emails: - Keep existing syntax for the "from:" field. - Use said syntax to add other recipients and/or CC's, but use tag domain instead. - Blackhole everything going to the tag domain and use the metadata from the reply to original sender to modify the message, no need for waiting periods. - On RAP, you can filter by email using tag domain - Figure out BCC later. Problem with this one is you'll have duplicate addresses, depending on if they were a sender or a CC. Overall, this are the candidate solutions as far as I understand: - Use the banner method but sacrifice indexability on RAP - Use the tag domain method but have potential duplicates - Use anonaddy's existing syntax implementation (AESI) and enforce a waiting period before forwarding Yeah, this is harder than I first thought (and I'm not even looking at the code). I can see the banner method working if you use your RA exclusively with anonaddy, so that searching for an email address would yield the emails written on the banner. Or with some sort of integration to tag or modify emails on your RAP. </details> Still thinking out loud. I hope this makes at least some sense lol. The more I try to solve it the more complex the solution turns for the end user, but the goal would be to make it as simple as possible to prevent errors from leaking PI.

kerem commented

Author

Owner

@jaron-l commented on GitHub (Jun 5, 2023):

If an encrypted email was intercepted between you and Anonaddy Server, only your routing address would be compromised as the output banner would be encrypted.

Would it be a security issue if the routing email was leaked? Then someone could pretend to be the alias owner by sending a properly formatted email to the routing address. If to get around this you verify that emails sent to the routing address are from verified emails, then what is the advantage of using a routing address versus just a verified email sending to the alias?

This approach depends on sending instructions trough the banner, so disabling it would hinder a user's ability to cc/reply-all

I'm not sure I follow what you mean by "banner". Are you talking about the input/output template sections? What does "disabling" mean in this case? The user accidentally deletes the information in the email?

As a side note, when the user goes to fill in the input/output sections, won't most email interfaces filter out the input/output sections that anonaddy is adding to the email? Specifically I'm thinking that gmail does that but I guess it's not a huge pain to just have the user click the three dots to edit the previous email.

Blackhole everything going to the tag domain and use the metadata from the reply to original sender to modify the message, no need for waiting periods.

I think I lost you somewhere around here. What are "waiting periods"?

@jaron-l commented on GitHub (Jun 5, 2023): >If an encrypted email was intercepted between you and Anonaddy Server, only your routing address would be compromised as the output banner would be encrypted. Would it be a security issue if the routing email was leaked? Then someone could pretend to be the alias owner by sending a properly formatted email to the routing address. If to get around this you verify that emails sent to the routing address are from verified emails, then what is the advantage of using a routing address versus just a verified email sending to the alias? > This approach depends on sending instructions trough the banner, so disabling it would hinder a user's ability to cc/reply-all I'm not sure I follow what you mean by "banner". Are you talking about the input/output template sections? What does "disabling" mean in this case? The user accidentally deletes the information in the email? As a side note, when the user goes to fill in the input/output sections, won't most email interfaces filter out the input/output sections that anonaddy is adding to the email? Specifically I'm thinking that gmail does that but I guess it's not a huge pain to just have the user click the three dots to edit the previous email. > Blackhole everything going to the tag domain and use the metadata from the reply to original sender to modify the message, no need for waiting periods. I think I lost you somewhere around here. What are "waiting periods"?

kerem commented

Author

Owner

@leonardosegurat commented on GitHub (Jun 5, 2023):

Would it be a security issue if the routing email was leaked? Then someone could pretend to be the alias owner by sending a properly formatted email to the routing address. If to get around this you verify that emails sent to the routing address are from verified emails, then what is the advantage of using a routing address versus just a verified email sending to the alias?

That's a great point. I think the routing address would serve to obfuscate the recipient's address, but if we're already sending to our own aliases and encoding that info in the banner, just the alias gets exposed. Perhaps there could be a way of sending email from disposable addresses without verification, if sent to a routing address and including a rolling code or some other form of authentication assuming a hostile network, but that's a different feature idea entirely and would still be workable if sending to your alias.
Perhaps you would benefit of your alias not being exposed in transit between you and anonaddy (though it would be exposed once recoded and sent to its final recipients). This way, an observer would see you're sending and receiving email trough your routing address, or perhaps even through an anonaddy routing address, but wouldn't know what alias you're using or who your recipients are on the other side.
To someone inspecting a network, first case would look like you're exchanging email with an address in your domain. Second case looks like you're exchanging email with an address from an anonaddy domain. And if you set up a proxy address in the middle, you'd expose that address only and can use whatever domain you want, as long as you encrypt your email.

As a side note, when the user goes to fill in the input/output sections, won't most email interfaces filter out the input/output sections that anonaddy is adding to the email? Specifically I'm thinking that gmail does that but I guess it's not a huge pain to just have the user click the three dots to edit the previous email.

Yes it would, which is annoying. I was thinking of a workaround using different mailto: links with the whole email content embedded, or potentially telling the client which message ID to reference, tough this appears to not be widely supported.
This could allow a user to read an email and click the links in the banner instead of their application's reply / forward functions, the output banner / template could be embedded in the reply and reply all links, which would get the user to the email editor with the correct recipients, CC's, etc. This idea could actually work for either method:

Encode CC's and multiple recipients into the reply links
Encode the output banner with the appropriate format into the link.

They would both require the user to click the link in order to reply, rather than using the email client's existing buttons, so I think there is still space for the multiple recipients, no banner approach.

I'm not sure I follow what you mean by "banner". Are you talking about the input/output template sections? What does "disabling" mean in this case? The user accidentally deletes the information in the email?

By banner I'm referring to the section of an email that says "This email was sent to alias@example.com from sender@company.com Click here to deactivate this alias" , and by disabling I mean setting up anonaddy not to add this banner to incoming email.
I am also making the distinction between input and output banners.

I think I lost you somewhere around here. What are "waiting periods"?

Don't worry!
I probably misread the last part of vlad's comment, or some other part of this thread, as I was pretty confident that I read something about a potential issue if anonaddy receives multiple emails within a few seconds of each other, an email with missing headers or a duplicate email could be sent if interpreted as different emails. I thought the discussion mentioned a waiting period would solve this, but I can't find that part of the discussion.
After thinking through it, I think I was the lost one here, as all the information would be present in any of the emails, and all others could be ignored if identical (unless it's a BCC, in which case anonaddy would encode and send a new email per BCC recipient).

@leonardosegurat commented on GitHub (Jun 5, 2023): >Would it be a security issue if the routing email was leaked? Then someone could pretend to be the alias owner by sending a properly formatted email to the routing address. If to get around this you verify that emails sent to the routing address are from verified emails, then what is the advantage of using a routing address versus just a verified email sending to the alias? That's a great point. I think the routing address would serve to obfuscate the recipient's address, but if we're already sending to our own aliases and encoding that info in the banner, just the alias gets exposed. Perhaps there could be a way of sending email from disposable addresses without verification, if sent to a routing address and including a rolling code or some other form of authentication assuming a hostile network, but that's a different feature idea entirely and would still be workable if sending to your alias. Perhaps you would benefit of your alias not being exposed in transit between you and anonaddy (though it would be exposed once recoded and sent to its final recipients). This way, an observer would see you're sending and receiving email trough your routing address, or perhaps even through an anonaddy routing address, but wouldn't know what alias you're using or who your recipients are on the other side. To someone inspecting a network, first case would look like you're exchanging email with an address in your domain. Second case looks like you're exchanging email with an address from an anonaddy domain. And if you set up a proxy address in the middle, you'd expose that address only and can use whatever domain you want, as long as you encrypt your email. > As a side note, when the user goes to fill in the input/output sections, won't most email interfaces filter out the input/output sections that anonaddy is adding to the email? Specifically I'm thinking that gmail does that but I guess it's not a huge pain to just have the user click the three dots to edit the previous email. Yes it would, which is annoying. I was thinking of a workaround using different mailto: links with the whole email content embedded, or potentially telling the client which message ID to reference, [tough this appears to not be widely supported](https://stackoverflow.com/questions/66341392/can-you-use-a-mailto-link-to-reply-to-an-email-and-preserve-threading). This could allow a user to read an email and click the links in the banner instead of their application's reply / forward functions, the output banner / template could be embedded in the reply and reply all links, which would get the user to the email editor with the correct recipients, CC's, etc. This idea could actually work for either method: - Encode CC's and multiple recipients into the reply links - Encode the output banner with the appropriate format into the link. They would both require the user to click the link in order to reply, rather than using the email client's existing buttons, so I think there is still space for the multiple recipients, no banner approach. >I'm not sure I follow what you mean by "banner". Are you talking about the input/output template sections? What does "disabling" mean in this case? The user accidentally deletes the information in the email? By banner I'm referring to the section of an email that says "This email was sent to [alias@example.com](mailto:alias@example.com) from [sender@company.com](mailto:sender@company.com) Click [here](https://github.com/anonaddy/anonaddy/issues/deactivation_URL) to deactivate this alias" , and by disabling I mean setting up anonaddy not to add this banner to incoming email. I am also making the distinction between input and output banners. > I think I lost you somewhere around here. What are "waiting periods"? Don't worry! I probably misread the last part of [vlad's comment](https://github.com/anonaddy/anonaddy/issues/123#issuecomment-961599944), or some other part of this thread, as I was pretty confident that I read something about a potential issue if anonaddy receives multiple emails within a few seconds of each other, an email with missing headers or a duplicate email could be sent if interpreted as different emails. I thought the discussion mentioned a waiting period would solve this, but I can't find that part of the discussion. After thinking through it, I think I was the lost one here, as all the information would be present in any of the emails, and all others could be ignored if identical (unless it's a BCC, in which case anonaddy would encode and send a new email per BCC recipient).

kerem commented

Author

Owner

@ghost commented on GitHub (Nov 2, 2023):

Until a proper solution is created, it would be nice if a banner showed up regardless of what the current banner option is set to that informs the user that there are multiple recipients for the message when such is the case. It's possible (mildly annoying, but not too difficult on desktop) to pull up the headers, copy the recipient data into a text editor, convert all of the other recipient addresses into good reply-to addresses manually (find-and-replace and block edit are lifesavers), and then copy them back into the email client. The main thing is knowing whether all of that is necessary without checking the headers every time, which is why I'm suggesting a banner. Not knowing you're in a group email is actually a big deal.

@ghost commented on GitHub (Nov 2, 2023): Until a proper solution is created, it would be nice if a banner showed up regardless of what the current banner option is set to that informs the user that there are multiple recipients for the message when such is the case. It's possible (mildly annoying, but not too difficult on desktop) to pull up the headers, copy the recipient data into a text editor, convert all of the other recipient addresses into good reply-to addresses manually (find-and-replace and block edit are lifesavers), and then copy them back into the email client. The main thing is knowing whether all of that is necessary without checking the headers every time, which is why I'm suggesting a banner. Not knowing you're in a group email is actually a big deal.

kerem commented

Author

Owner

@willbrowningme commented on GitHub (Jun 11, 2024):

Currently making some progress on this, will need a few to help test it out shortly.

@willbrowningme commented on GitHub (Jun 11, 2024): Currently making some progress on this, will need a few to help test it out shortly.

kerem commented

Author

Owner

@Iizuki commented on GitHub (Jun 11, 2024):

Currently making some progress on this, will need a few to help test it out shortly.

I'm available ✋

@Iizuki commented on GitHub (Jun 11, 2024): > Currently making some progress on this, will need a few to help test it out shortly. I'm available ✋

kerem commented

Author

Owner

@andre-paulo98 commented on GitHub (Jun 14, 2024):

Currently making some progress on this, will need a few to help test it out shortly.

Was also about to ask if there was an update, so I'll be more than willing to help test it out!

@andre-paulo98 commented on GitHub (Jun 14, 2024): > Currently making some progress on this, will need a few to help test it out shortly. Was also about to ask if there was an update, so I'll be more than willing to help test it out!

kerem commented

Author

Owner

@willbrowningme commented on GitHub (Jun 19, 2024):

@Iizuki Thanks, please could you give it a try now. Reply-all should work (you may have to just remove the alias itself when clicking this).

@willbrowningme commented on GitHub (Jun 19, 2024): @Iizuki Thanks, please could you give it a try now. Reply-all should work (you may have to just remove the alias itself when clicking this).

kerem commented

Author

Owner

@Iizuki commented on GitHub (Jun 20, 2024):

@willbrowningme

@Iizuki Thanks, please could you give it a try now. Reply-all should work

Tried it now. Seems to work yes 👍

(you may have to just remove the alias itself when clicking this).

Yes this appears to be the case.

@Iizuki commented on GitHub (Jun 20, 2024): @willbrowningme > @Iizuki Thanks, please could you give it a try now. Reply-all should work Tried it now. Seems to work yes 👍 > (you may have to just remove the alias itself when clicking this). Yes this appears to be the case.

kerem commented

Author

Owner

@andre-paulo98 commented on GitHub (Jun 20, 2024):

How can one try this? Is it only available in addy.io or is it also available for selfhosters?

@andre-paulo98 commented on GitHub (Jun 20, 2024): How can one try this? Is it only available in addy.io or is it also available for selfhosters?

kerem commented

Author

Owner

@willbrowningme commented on GitHub (Jun 21, 2024):

@andre-paulo98 it's only available on addy.io for now. I will push a new release for those self-hosting shortly.

@willbrowningme commented on GitHub (Jun 21, 2024): @andre-paulo98 it's only available on addy.io for now. I will push a new release for those self-hosting shortly.

kerem commented

Author

Owner

@lucasfijen commented on GitHub (Jun 21, 2024):

Works like a charm! Thank you for implementing this! Last trade-off for using anonaddy is now gone for me!

@lucasfijen commented on GitHub (Jun 21, 2024): Works like a charm! Thank you for implementing this! Last trade-off for using anonaddy is now gone for me!

kerem commented