Mail redirect and privacy

[Smithy]

I just noticed that if a forwarding rule is set in Sieve screen to "redirect" messages to another address and if the mail is bounced due to some problem with the destination server, the bounced mail goes directly to the original sender revealing full glory details of where you are forwarding your emails to and what route it took. I noticed that the same happens if the mail forwarding is set up from the aliases screen using aliases.

I suspect that if the forwarded destination address has set up vacation message, the vacation message will go back to the original sender as well.

Does anyone else see the privacy implications and potentially embarrassing situation caused by this?

Interestingly, when I redirect messages by selecting the messages and choosing "redirect to people" from the pull down menu, the bounced messages do not go to the original sender.

[DrStrabismus]

That's how it should be. When an email is redirected any delivery failure message needs to go back to the sender. When you manually redirect, it's you who needs to know what happened.

[Smithy]

Originally posted by DrStrabismus
That's how it should be. When an email is redirected any delivery failure message needs to go back to the sender. When you manually redirect, it's you who needs to know what happened.

That makes sense for the forwarding done through the aliases screen, but not through the sieve rules. The message has already been delivered when the rules are applied and most other mail services that I have used modify the return-path before forwarding a message after delivery.

Whatever be FM's logic and adherence to so and so RFCs, I just wish that I had known it before buying my second email account. Anyway, will take it into account at the time of renewal.

[n5bb]

I just posted on a related topic:
Return-Path header not used for FM bounce?

Also in that other post: The Action box redirect to people command adds a Return-Path header using the address of your default personality, while the Sieve redirect command (used by the Forward feature on the Rules screen) uses the original envelope From.

Bill

[DrStrabismus]

Originally posted by Smithy
Whatever be FM's logic and adherence to so and so RFCs,

It's more to do with common sense. The chief reason for using a sieve redirect is because the mail is read elsewhere. If it can't be delivered then the original sender needs to know.

[n5bb]

Originally posted by DrStrabismus
It's more to do with common sense. The chief reason for using a sieve redirect is because the mail is read elsewhere. If it can't be delivered then the original sender needs to know.

And the full headers need to indicate how the mail was routed, so the original sender can determine why they are getting a bounce from someone not on the original To or CC or BCC lists.

So even though this may seem to some as a "security leak", there is no easy way to keep email flowing smoothly without full headers transmitted to the sender. At least not for the purpose intended by the forward action.

Now it might be useful to edit the headers when redirecting for certain purposes. The Sieve editheader extension provides this ability, but is not yet supported by Cyrus (so not by Fastmail).

Bill

[Smithy]

The question of whether message can be delivered or not is not applicable in this case as I use

redirect "................."; keep;

so that a copy of the message is explicitly kept in my inbox. Obviously, the message has been delivered so that should be enough as far as message delivery is concerned.

I think calling this behaviour "common sense" is stretching common sense a bit too far, unless the common sense in question is "If I send a message to someone, I have the right to know how many times the message is forwarded and who reads the message". Clearly the message has been delivered to the intended recipient and there is no standard to dictate that the sender should know where else the message is forwarded to. Even if there were such a standard, it could easily be circumvented by manually forwarding the message.

Yes, I do understand the technical side of it, and Cyrus and Sieve not supporting it is fine. However, the only reason I am posting about it here is that with most other email providers, when I set up automatic email forwarding, the behaviour was quite different. They were not using Sieve, so my assumption about Sieve redirect turned out to be wrong. But calling it a "common sense" is far from the reality.

[DrStrabismus]

Originally posted by Smithy
The question of whether message can be delivered or not is not applicable in this case as I use

redirect "................."; keep;

Like I said: "The chief reason for using a sieve redirect is because the mail is read elsewhere."How does sieve know whether you read your local mailbox.

[Smithy]

Originally posted by DrStrabismus
"How does sieve know whether you read your local mailbox.

And how would Sieve know if I sent that email straight to the Trash never even looking at it? It's not the MTA's job to make sure that I read a certain message. Reading, ignoring, forwarding or discarding a message is my own choice.

[robmueller]

I guess what's needed is two concepts:

1. redirect = keep existing Received headers and MAIL FROM envelope and forward the message
2. resend - create a "new" message with the exact same content but with a MAIL FROM of the user resending, and none of the previous Received headers

In that respect, the sieve redirect is (1) above, and the mailbox screen redirect is half way between (1) and (2) (keep the Received headers)

Rob

[hadaso]

Originally posted by robmueller
I guess what's needed is two concepts:
...
2. resend - create a "new" message with the exact same content but with a MAIL FROM of the user resending, and none of the previous Received headers
...

Perhaps a third one: send with a MAIL FROM (or whatever get the message to be bounced to a particular address if the recipient decides to bounce) but keep all or most headers, such as "Received" headers.

This is the best way with what some people do: send a copy of received mail to another account for "archival" purposes. Many users (including myself) forward a copy (using Sieve) to a Gmail account. I also forward small messages to a Guest account tp populate it with messages (so it can then be used for testing). What happens sometimes is that if I don't react fast to the "account almost full" message my correspondents get a bounce message and think the message was not received (and then resend it several times, until I realize what's happening.

I'm son't see why discarding the old "Received" headers is needed. If the message will not bounce to a stranger, there's no privacy issue, and the info might be useful if the other account is really used as an archive. The real issue is to differentiate between email that is being copied elsewhere, and email that is being redirected as part of the delivery process, and only the user can know which one it is (as DrS pointed out, email might be redirected for reading it elsewhere with a copy kept on fastMail for archival purpose).

A very similar issue was mentioned here (in the context of forwarding email to SMS).