Reply-To Headers

From: and Reply-to: headers giving different addresses, and the From: address is used in the To: header of a reply.

This is not correct and the Reply-To address should be used over the From address, every time it is given, according to RFC822 (section 4.4.4).
Quoting :

        o   If the "Reply-To" field exists, then the reply  should
        go to the addresses indicated in that field and not to
        the address(es) indicated in the "From" field.

Some reasons as to why it is this way are given in section 4.4.3 of the same RFC.

Literally every other email client does it correctly…

Please change this behaviour to respect the RFC.


(Originally posted by Webbeh on GitHub.)

With multiple email accounts, sending email from one to another, sender (FROM “You”) and receiver (TO “You”) are both “You” … bug is that when one selects the action “reply,” the reply email is sent to the TO “You” instead of the FROM “You”.

You don’t need any attachment, a blank email works. This bug is 100% reproducible as follows:

  1. Add two email accounts.
  2. Send email from account 1 to account 2. Account 2 receives email FROM You(account 1) and TO You(account 2), although pull down does differentiate between the two “You’s.”
  3. Reply to email received from account 1 (“You”) as the account 2 user (also “You”).
  4. The reply email TO address is You(account 2) instead of You(account 1). In other words, “You” end up sending email to yourself instead of replying to the “other” “You.”

Work-around: Click on the FROM “You” in the original email to see the email address then manually copy it. Then select FORWARD (instead of REPLY) and paste the email address into the TO field. BTW, I had over a dozen email accounts so this bug became CRAZY, because I had over a dozen YOU’s!

Bug Fix: Don’t even use “You” in FROM field, but instead use the account name that had been configured with the email account. If one has only one email account, then this issue of course does not happen because there is always just one “You” by definition.


(Originally posted by randinovak18 on GitHub.)

  1. Configure access to two IMAP accounts on Mailspring, say me@a.com and me@b.com
  2. Send a message from me@a.com to me@b.com
  3. Read the message on the me@b.com account
  4. While reading the message, click the Write a reply... button at the bottom
  5. When the reply window opens, notice the To address: It reads me@b.com instead of me@a.com, which is the sender you want to reply to.

(Originally posted by pirivan on GitHub.)

Description

I have set up my main G Suite email a@main.com with an alias domain a@alias.com in MailSpring. Clicking the reply button for an email sent to a@alias.com opens a new composer. The recipient is a@alias.com instead of the original sender.

To Reproduce…

Steps to reproduce the behavior:

  1. Add a@main.com
  2. Add a@alias.com as an alias in MailSpring
  3. User b@sender.com to send an email to a@alias.com
  4. Click the reply button

Expected Behavior

The recipient is b@sender.com

Actual Behavior

The recipient is a@alias.com

Screenshots

Setup

  • OS and Version: Windows 10
  • Mailspring Version: 1.7.8

Additional Context

The recipient in the original email is a@main.com which is wrong. After expanding the detail, it becomes a@alias.com. It should be #874.

The sender in the replying email is a@alias.com which is correct.


(Originally posted by keithyipkw on GitHub.)

Duplicates:

I got an email using imap in mailspring. Let’s call it test@example.com. My mail provider is modern, so they support email tags. This means if I send an email to test+tag@example.com it will be delivered to test@example.com. This works fine, but if I try to answer the mail it will answer to the wrong mail.

For example: I send a mail from abc@gmail.com to test+tag@example.com. If I click on the “answer” button it should answer to abc@gmail.com, but for me it answers to test+tag@example.com (to myself).


(Originally posted by sinnlosername on GitHub.)

For what it’s worth, I would also like to see this fixed.

Referring to this issue: