mirror of
https://github.com/anonaddy/anonaddy.git
synced 2026-04-25 06:05:55 +03:00
[GH-ISSUE #123] No support for CC/Reply-All? #702
Labels
No labels
bug
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/anonaddy#702
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @vlad-tim on GitHub (Jan 27, 2021).
Original GitHub issue: https://github.com/anonaddy/anonaddy/issues/123
If an original email message contains multiple recipients (aka CC), the forwarded email seems to be lacking information about them. And, as a consequence, it's not possible to "Reply All".
Am I missing something? If not, are there any plans to add support for this use case?
@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.
@vlad-tim commented on GitHub (Jan 27, 2021):
That would be helpful. Also, there is an edge case - if AnonAddy email alias itself was it
Cc:originally and not inTo:, then it's nice to know who was inTo:.Makes sense. Not sure how feasible it sounds, but I have been imagining encoding CC'ed recipients in
To:header like this:Where
to_recipientis something likerecipient1=gmail.com, andfirst_cc_recipientis something likerecipient2=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.
@willbrowningme commented on GitHub (Jan 28, 2021):
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.
@akirayamamoto commented on GitHub (Aug 9, 2021):
I am also interested.
@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?
@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 toApp/Models/EmailData.phpand then access it fromApp/Mail/ForwardEmail.phpadding the CC header to the forwarded message inside the->withSwiftMessage(function ($message) use ($returnPath) {method.@willbrowningme commented on GitHub (Nov 3, 2021):
Testing this out now, more complicated than I first thought but got some bits working so far.
@vlad-tim commented on GitHub (Nov 3, 2021):
I could help with testing.
@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
@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.meand this alias is sent an email fromsender@example.comthat hascc@example.comCC'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.comotherwise clicking reply-all would send the message directly from their real email and expose it. So AnonAddy must replace the CC header withalias+cc=example.com@anonaddy.me, then when you click reply-all it will be sent tocc@example.comfrom 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.mewithalias+cc=example.com@anonaddy.meCC'd in, ensuring that their real email is not exposed.AnonAddy will need to accept and process these two emails so that
sender@example.comandcc@example.comboth recieve them with the correct headers.sender@example.comwill need:cc@example.comwill also need:That is where AnonAddy will need to swap the incoming CC header
alias+cc=example.com@anonaddy.metocc@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.
@vlad-tim commented on GitHub (Nov 5, 2021):
I like the idea.
So, in your example, after the user clicks
Reply all,anonaddy.mewill receive 2 emails, and it will map each of those incoming emails to single, not 2, outgoing emails, right?Agree. I would verify the case with multiple Tos and CCs at the same time and
alias@anonaddy.mecan 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?@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?
@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
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
@willbrowningme commented on GitHub (Nov 26, 2021):
Okay for the first step I have just added new headers to forwarded emails. These headers are:
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.meetc.@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.
@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 (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:
It could be implemented like this:
This yields the following benefits:
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.
@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?
@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.
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:
Benefits:
Compromises for this solution:
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:Email forwarded to recipient address:
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.
Ok, one more try for indexable emails:
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:
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.
@jaron-l 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?
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.
I think I lost you somewhere around here. What are "waiting periods"?
@leonardosegurat commented on GitHub (Jun 5, 2023):
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.
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:
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.
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.
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).
@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.
@willbrowningme commented on GitHub (Jun 11, 2024):
Currently making some progress on this, will need a few to help test it out shortly.
@Iizuki commented on GitHub (Jun 11, 2024):
I'm available ✋
@andre-paulo98 commented on GitHub (Jun 14, 2024):
Was also about to ask if there was an update, so I'll be more than willing to help test it out!
@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).
@Iizuki commented on GitHub (Jun 20, 2024):
@willbrowningme
Tried it now. Seems to work yes 👍
Yes this appears to be the case.
@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?
@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.
@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!
@cb3inco commented on GitHub (Jun 25, 2024):
I'm wondering....if a email is forwarded on from Anonaddy from sender@example.com and I respond but add a cc1@example.com or to1@example.com, is there not a way to hide the originating email address if they weren't included on the first email?
@willbrowningme commented on GitHub (Jun 26, 2024):
@cb3inco you would have to manually construct the correct address in order to send from your alias and enter that as a CC or To - https://addy.io/help/sending-email-from-an-alias/
e.g.
alias+cc1=example.com@johndoe.anonaddy.com