Rule "Send a copy to..." misdirects bounces

[chrisjj]

I have a FM rule to "Send a copy to..." a Gmail address.

If that operation generates a bounce, currently FM sends it not to the place it should go - the FM account which made that send - but to the original sender's account, which did not.

This is unfortunate because it a) misinforms the sender "your message could not be delivered to one or more recipients." and b) reveals the forward-destination Gmail address to the sender.

Does anyone know a configuration adjustment to workaround this?

[BritTim]

I cannot see a good solution. A common use case for sending a copy to Gmail is for disaster recovery purposes. We want this backup to contain all the same details as the original delivered at Fastmail. It seems you want a special option something like "send a copy as <chosen from address>". Although probably really tricky. it might be feasible, using custom sieve, to edit the From header before forwarding a copy to Gmail. Whether this would be possible without making the modified message look like spam is questionable.

[chrisjj]

Originally Posted by BritTim

It seems you want a special option something like "send a copy as <chosen from address>".

I need only "Send a copy as this account address". Which is what Actions > Send a copy... already does, no?

[n5bb]

I just made some tests of various Fastmail send a copy features.
The manual action Send a copy sends the original email to the destination address you enter as follows:

• The Envelope-sender (Return-Path) address is set to the main address (login address) of your Fastmail account where you exectuted the Send a copy. So a message delivery failure will be sent to the Fastmail account.
• All of the usual recipient-viewable headers (From, To, Cc, Subject, Date/Time) are set as in the original message.

So the recipient will receive the original email just as it was created, with the exception that the full headers will show an unusual delivery path and Envelope-sender address. This might be confusing for the recipient, since they can?t why they received the message unless they know about the BCC feature (which wasn’t actually used in this case).

The Fastmail Rules Send a copy to feature seems to do the same thing as the My email addresses Advanced delivery Alias delivery target feature. The message is sent to the new recipient with the Envelope-sender (Return-Path) address set to the original sender address. That is why message delivery failures are sent to the original sender, not to the Fastmail account.

The manual Forward feature does something quite different. It creates a completely new message and inserts text which shows the original message user readable contents, including the original From, To, Cc, Subject, and Date.

The manual Edit as new feature seems to be unique to Fastmail and is very useful. It loads the original message into the Compose screen (but using one of your From addresses) and lets you create a new message just as if you were the original sender creating the message. I use this all the time after I send a message to one person (or group). In the Sent folder I open that message using Edit as new and then change the To/Cc lists and other message details so it is appropriate for another group of recipients.

Bill

[chrisjj]

Thanks Bill. Very useful.

Originally Posted by n5bb

The Fastmail Rules Send a copy to feature ... The message is sent to the new recipient with the Envelope-sender (Return-Path) address set to the original sender address.

I cannot see how anyone would think this is proper. As the command name "Send a copy to" makes obvious, this is a new send - so the return path should be the new sender.

And regardless, also not proper is Send a copy... doing one thing from the UI command and a different thing from the rule command.

[BritTim]

Originally Posted by chrisjj

I cannot see how anyone would think this is proper. As the command name "Send a copy to" makes obvious, this is a new send - so the return path should be the new sender.

And regardless, also not proper is Send a copy... doing one thing from the UI command and a different thing from the rule command.

I understand your point of view, but as I implied in my earlier post, Send a copy and a manual forward have generally had different objectives: one for backing up a message, the other a decision to tell someone else about the message. The inconsistency that seems wrong to you follows from the typically different use cases. Backing up a message, in my view, reasonably implies storing it elsewhere unchanged.

[chrisjj]

Originally Posted by BritTim

I understand your point of view, but as I implied in my earlier post, Send a copy and a manual forward have generally had different objectives: one for backing up a message, the other a decision to tell someone else about the message.

Well, I don't see anything suggesting that those different /uses/ are priority design /objectives/.

And nor do I see that those uses are specific to the respective commands. Backup can be done with either command - one automatic, the other manual. Likewise tell someone else about the message can be done with either command - one automatic (probably selectively), one manual.

Originally Posted by BritTim

Backing up a message, in my view, reasonably implies storing it elsewhere unchanged.

Sure, but that's just one use case. Nothing about the command affordance is specific to backup.

And if rules Send a copy /were/ designed for backup, surely it should not suffer from this sending the originator a DSN saying the backup failed!

[hadaso]

What the manual "Send a Copy" action does is the same as adding bcc recipients. It can be used you forgot some bcc recipient, or realized that some people that were not included should have received a copy, or to send a copy to another address of one of the recipients.It can be used to manually send a copy as backup to the user's different account. In all these scenarios, since the action is manual, the destination of a bounce message should be to the one that initiated the "Send a Copy" action (and AFAIK that;s what happens.
Automatic sending of (an exact) copy is different: it can be used for simple mail forwarding: the account is used as a forwarding service, and redirects the message to where the recipient reads their email. In this case failure to deliver to the final destination means that the message has not been received by the intended recipient, so the proper thing to do is inform the sender of the message that it was not received by the recipient. However it can also be used by the recipient to send extra copies to backup accounts, and in this case it is not appropriate to notify the original sender that the delivery failed, because it has not failed: the recipient has received the message in their account. It is proper in this case to inform the the original recipient (the owner of the accounts that sends a copy) that the delivery to the extra destination has failed. IMHO the naming of the action as "Send a copy" implies the second use scenario, and the bounces should go to the user that wrote the rule, and there should be a separate instruction to be used when it's not sending a copy but rather resending the message to its final destination without keeping a copy.
Sending a non-delivery message to the sender of a message because some back process at the recipient has failed is wrong, and is a sort of security problem because it reveals the address of the recipient's backup account to the sender (that may later use it to send email that would never be received at a destination were the recipient reads email, and produce no non-delivery messages for such email/

[n5bb]

I agree that the multiple ways you can cause a copy of an incoming message to be copied to another account are confusing and not well documented.

The manual Send a copy action is the exception - it is well documented in Fastmail help:
https://www.fastmail.help/hc/en-us/a...82-Send-a-copy
As I previously noted, I find this feature extremely useful.

Fastmail Help describes alias targeting and forwarding using rules here:
https://www.fastmail.help/hc/en-us/a...ail-forwarding

The manual forwarding feature is described here:
https://www.fastmail.help/hc/en-us/a...rding-messages

I think that the lack of generally accepted terminology for these different actions complicates dealing with this issue. The normal action of a MTA (Message Transfer Agent) server is to redirect a message to a different target, making no changes which are visible to the typical recipient but adding a few headers. This is also what happens using the alias target and rules Send a copy features. A normal MTA is not responsible for detailing with delivery issues other than informing the original sender of the difficulty. This is done directly by the MTA if the message target cannot be reached or it rejects the message immediately, or indirectly by the delivery system sending a message to the original sender using the Return-path header (Envelope-From).

Note that message authorization features at the delivery server can cause difficulty if the From address is not aligned with the Envelope-From address. Since the Return-path header is normally set to the Envelope-From, all of these direct message automatic forwarding methods are starting to fail erratically. If you change the headers so the delivery failure message goes to an address associated with the forwarding system, normal messages to that recipient may get rejected or marked as spam.

I think the only solution is to somehow encapsulate the message you are forwarding so the delivery issues to the final recipient are separated from the message origination reputation issues. You can manually do this by the manual message forwarding and forward-as-an-attachment features, but there are no automatic methods to do this as far as I know other than LISTSERV and other email redistibution (reflector) systems.

Bill

[chrisjj]

Originally Posted by hadaso

What the manual "Send a Copy" action does is the same as adding bcc recipients. It can be used you forgot some bcc recipient, or realized that some people that were not included should have received a copy, or to send a copy to another address of one of the recipients. It can be used to manually send a copy as backup to the user's different account.

Plus to reattempt a copy that mail rule "Send a Copy" failed to deliver - a frequent occurrence here with target Gmail which often rejects due to "Your email has been rate limited" (sic).

Originally Posted by hadaso

In all these scenarios, since the action is manual, the destination of a bounce message should be to the one that initiated the "Send a Copy" action (and AFAIK that;s what happens.

AFAIK too.

Originally Posted by hadaso

Automatic sending of (an exact) copy is different: it can be used for simple mail forwarding: the account is used as a forwarding service, and redirects the message to where the recipient reads their email. In this case failure to deliver to the final destination means that the message has not been received by the intended recipient

Since we cannot mind-read /intent/ lets say /addressee/.

I disagree that failure to deliver to the final destination means that the message has not been received by the addressee. If the addressee is chrsijj@fastmail.fm , the message has been received by the addressee.

Originally Posted by hadaso

However it can also be used by the recipient to send extra copies to backup accounts, and in this case it is not appropriate to notify the original sender that the delivery failed, because it has not failed: the recipient has received the message in their account. It is proper in this case to inform the the original recipient (the owner of the accounts that sends a copy) that the delivery to the extra destination has failed. IMHO the naming of the action as "Send a copy" implies the second use scenario, and the bounces should go to the user that wrote the rule

I agree.

Originally Posted by hadaso

Sending a non-delivery message to the sender of a message because some back process at the recipient has failed is wrong, and is a sort of security problem because it reveals the address of the recipient's backup account to the sender

Agreed. Plus imagine the confusion to the sender of getting a soft-bounce from the first mailbox and then from the second ... and possibly more.

I'll propose to FM that this be addressed e.g. by addition of a second command, "Send a copy properly..." . I'll report here so you can add your vote at FM.