Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When we reply to an email we have sent, it proposes our address #384

Closed
adrienmaloba opened this issue Apr 5, 2020 · 7 comments
Closed
Labels
core core module set enhancement suggest an improvement smtp smtp module set
Milestone

Comments

@adrienmaloba
Copy link
Member

When we have sent an email to a correspondent and we want to reply to the same message.
By clicking on REPLY, this suggests us to send a message to the sender, not to the receiver of the sender.
The improvement would be to offer to send an email to the recipient instead of the sender.

cypht-

@dumblob
Copy link
Member

dumblob commented Apr 5, 2020

I'll second this request with a minor modification - I'd actually expect to have all To: From: Cc: copied with To: and From: swapped.

@marclaporte
Copy link
Member

Also, when forwarding a message, the "to" and "cc" are missing.

Open question: should bcc be in the forward? Roundcube doesn't do it. I can think of arguments on both sides. I guess we can see what all the main webmail software and services do...

Current forward message:

----- begin forwarded message -----

From:
Date:
Subject:

@dumblob
Copy link
Member

dumblob commented Apr 13, 2020

Open question: should bcc be in the forward?

Hm, bcc gets separated from the email before sending and because "saving to sent folder" is usually implemented as sending as well, one would think it'll always be empty in the saved email. On the other hand, I had many times the problem I wanted to find out who was in bcc (I use it quite frequently) and couldn't find anything because it won't get saved.

That said I'd strongly prefer if bcc actually got saved alongside with the whole email (and then when replying to it copied to the bcc field without any swapping with to nor from nor cc).

@marclaporte
Copy link
Member

@dumblob For reply and reply-to-all, I just tested and it looks good to me. Can you confirm?

As for forward: Maybe we should track in a different issue because there are other concerns.
#558
https://gitter.im/cypht-org/community?at=60d49d5b8c12474d8ccde4c3

@dumblob
Copy link
Member

dumblob commented Jul 12, 2022

@dumblob For reply and reply-to-all, I just tested and it looks good to me. Can you confirm?

You mean the installation you tested exhibits the behavior I outlined above in #384 (comment) ?

As for forward: Maybe we should track in a different issue because there are other concerns. #558 https://gitter.im/cypht-org/community?at=60d49d5b8c12474d8ccde4c3

Yep, that is a tough one. OTOH I would also welcome to have an option of a lossy conversion (but not as a default). The conversion "filter" could even be configurable (or there could just be multiple different conversion filters to choose from to not overengineer Cypht configuration 😉).

@marclaporte
Copy link
Member

Well, I am not sure I understand #384 (comment) so maybe I am missing a use case.

@dumblob
Copy link
Member

dumblob commented Jul 12, 2022

Yeah, the mention of swapping shall not be there - I might have been misled by the screenshot - I apologize for the fuss. To clarify, the following is what I actually expect.

Original (in any folder but sent by me):

From: a@b.c
To: b@c.d, c@d.e
Cc: d@e.f, e@f.g

After I (a@b.c) clicked "reply to all":

From: a@b.c
To: b@c.d, c@d.e
Cc: d@e.f, e@f.g

(i.e. 1:1 copy)

Note, this shall work even if I have multiple email addresses in Cypht - so the check "whether it originates from me or someone else" shall be performed against every email I have configured Cypht to actively use.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core core module set enhancement suggest an improvement smtp smtp module set
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants