Sieve redirect privacy concern

[xyzzy]

This is just a "heads up" that if you are using a rule's "Send a copy to" which is coded as a Sieve redirect or of course you use a Sieve redirect explicitly, the redirected message contains your X-Resolved-to. (plus a number of other headers). That effectively gives away your actual FM email account address. Obviously if it's another one of your own FM addresses it doesn't matter.

FM's "Organizing your inbox" document states for Rule actions,

• Send a copy to — with this option, a copy of messages that match your condition(s) can be sent to one or more external email addreses

But when I submitted a ticket on this FM's reply was,

This is the intended behaviour. Sieve redirect is primarily intended for forwarding on mail to another account you control. We have no current plans to change this.

My reply then to that is they need to define "external" more precisely in their documentation (and I did update the ticket stating that - reopened after the tried to close it). I guess "external" can be a non-FM email address so long as it's only one of your own.

Thoughts?

[hbs]

Interestingly FastMail strips all their own X-headers when forwarding an email via the Web UI including X-Resolved-to. I once mentioned it here in the forum.

I had raised a ticket in 12/2017 to no avail. One of the developers (quite active here in the forum) stated that retaining the X-Resolved-to header (as well as all other of FM's X-headers) is the intended behavior:

"2. As noted, in the vast majority of cases people use sieve redirects to send emails to another trusted mailbox. In these cases, preserving as much information as possible is always useful (e.g. all the Received headers + any additional X— headers we add like X-Spam-score, X-Delivered-to, X-Resolve-to, etc), since it helps understand the overall mail flow and actions that occurred on the mail from start to finish."

Since then, for I don't need the X-Resolved-to header, I remove it right at the beginning of my Sieve script:

# Get rid of the "X-Resolved-header"
if address :matches ["X-Resolved-to"] ["*"] {
    if not string :is "${1}" "" {
        set :lower "v_hbs_header_x_resolved_to" "${1}";
        deleteheader "X-Resolved-to";
    }
}

If retaining the X-Resolved-to header is essential it would be possible to re-add the header afterwards (in pseudo code):
- delete x-resolved-to header
- redirect copy of email
- add x-resolved-to header

The only drawback would be that the X-Resolved-to header would not reappear in its original place in the email source.

H.

[SideshowBob]

I don't see in what circumstance anyone would redirect to an address that's not trusted. This seems like a very artificial problem.

[BritTim]

Originally Posted by SideshowBob

I don't see in what circumstance anyone would redirect to an address that's not trusted. This seems like a very artificial problem.

Depending on the mail service used (for instance for backup email accounts) you may trust the recipient, but not want the provider of the mail service to be able to harvest your FastMail account name.

[xyzzy]

Originally Posted by SideshowBob

I don't see in what circumstance anyone would redirect to an address that's not trusted. This seems like a very artificial problem.

You might be right. I only stumbled upon this issue tinkering around with might be an "artificial" problem! I have two kinds of aliases I use for registrations. There's my "standard" regular aliases used for permanent registrations. And then there's "one offs", "disposables", "temporaries", "quick and dirty" (whatever you want to call them) aliases I use much like you would use sites like Mailinator, etc. (many places though a wise to sites like Mailinator and don't allow using their email addresses).

My "disposables" overload a single alias using subdomain addressing so I cannot just delete or disable that alias. For example, x1@aliasname.aliasdomain, x2@aliasname.aliasdomain, etc. I can create any number of these quickly using a single alias set up for this purpose when some place insists on an email address. Yes, I could use new standard aliases each time. But then I have to create it and wait until it takes effect.

When it comes time to no longer needing one of these email addresses I have a number of choices on how to handle it.

1. Reject it. More-or-less the equivalent of disabling or deleting standard aliases.
2. Save it in a folder (e.g., FM provides blocked addresses setting that moves in them only into trash). I might want to see why that email address is being used after I'm through with it.
3. Discard them (but I never want to discard - for discards I use a folder named "discard" that has a small retention time).

My experiment (and it was only an experiment just to see if it was possible) was to be able to do both 1 and 2, i.e., save a copy in a folder and also reject it. And this might apply for certain standard aliases as well.

To do this I create a copy of the message using a redirect :copy. Since the original was sent to my alias it is being redirected back to that same alias (i.e., it's a loop but I added a unique header to detect this case). The original message is filed into a folder and the redirected copy is rejected back to the original sender, i.e., the one not to be trusted. It's not the original copy of course but the one sent by the redirect so it contains the X-Resolved-to.

So this (contrived?) case is an example of using a redirect to effect a reject back to an untrusted sender.

As I said it was only an experiment (a proof of concept) to see if it could be done and it does work. But that's where I discovered the X-Resolved-to was added to the redirected copy and then rejected back to the original sender. If I really wanted to do this I can keep the recipient from seeing my X-Resolved-to simply by deleting it before the redirect.

As I said it was only a proof of concept. But it seemed to me that in general why should the X-Resolved-to (and a bunch of the X-Spam headers) be included by a redirect? The documentation doesn't specify any such restrictions on the redirect recipients and the UI doesn't place any restriction on it there either. I don't know, maybe you want to create a filter to redirect certain messages to friend. You still might not want them to know your actual account email address (assuming they bother to dig around in the headers).

Anyway, that's how all this came up. If you want to call it an "artificial problem" I'm fine with that.

----

Update:
I was constructing this reply when I noticed after I posted it that BritTim can up with another reason not have your account info in the headers. That too!

[Grhm]

Originally Posted by SideshowBob

I don't see in what circumstance anyone would redirect to an address that's not trusted. This seems like a very artificial problem.

Originally Posted by xyzzy

I don't know, maybe you want to create a filter to redirect certain messages to friend. You still might not want them to know your actual account email address (assuming they bother to dig around in the headers)

I do exactly this: I automatically forward copies of messages that arrive at certain addresses on one of my domains to the chair and secretary of an organisation I belong to. I thought that was the kind of thing it was designed for! I'm slightly shocked by what xyzzy has uncovered. (Unless I've misunderstood?)

[SideshowBob]

Originally Posted by Grhm

I do exactly this: I automatically forward copies of messages that arrive at certain addresses on one of my domains to the chair and secretary of an organisation I belong to. I thought that was the kind of thing it was designed for! I'm slightly shocked by what xyzzy has uncovered. (Unless I've misunderstood?)

What exactly do you think they would do with that information?

Sell it to a spammer? Hack you?

[Grhm]

It's not relevant what they might do with the info.
xyzzy reports Fastmail as saying "Sieve redirect is primarily intended for forwarding on mail to another account you control."
They wouldn't have said that if it doesn't matter whether I control the account or not.

[xyzzy]

Originally Posted by Grhm

It's not relevant what they might do with the info.
xyzzy reports Fastmail as saying "Sieve redirect is primarily intended for forwarding on mail to another account you control."
They wouldn't have said that if it doesn't matter whether I control the account or not.

I still don't agree with their response and may request it be escalated to a higher level.

If there is confirmation of the intent of the UI's Send a copy to (which currently allows you to type any email address you want in there) then so be it but I think then they at least need to document the possible implications of using that setting if you don't send to "another account you control".

Part of my original ticket asked why they include these headers in the forwarded message at all. Never got an answer for that.

[xyzzy]

My ticket has been updated by a different support person, one I have dealt with before, and he says it's passed to the "team concerned". That's just what I was after. So we wait...

[SideshowBob]

I don't forward from Fastmail, but I do make use of upstream headers, they can be very useful.

You're talking about removing a feature that's useful to some people using redirect in the normal way. Anyone who cares can remove the headers with sieve, or simply get a life.

So far I haven't heard a good reason why it's even a problem. I certainly don't think it's worth documenting. This kind of nonsense is why kettles now come with 10 page manuals.

[Grhm]

Originally Posted by SideshowBob

I do make use of upstream headers

What use do you make of them, if you don't mind me asking?

[JeremyNicoll]

Originally Posted by SideshowBob

I don't forward from Fastmail, but I do make use of upstream headers, they can be very useful.

If you're not forwarding, surely "upstream headers" are just normal mail headers?

And, yes, of course those are useful, showing the route emails took to get to you, and whose systems they passed through quickly and whose they were delayed on.

[SideshowBob]

Originally Posted by JeremyNicoll

If you're not forwarding, surely "upstream headers" are just normal mail headers?

I forward some mail *into* FM, and then retrieve from FM and feed the mail into my own imap server with it's own sieve filtering and SpamAssassin. In practice there no real difference between retrieval and forwarding.

And, yes, of course those are useful, showing the route emails took to get to you, and whose systems they passed through quickly and whose they were delayed on.

There's a lot more. There's upstream authentication results either via ARC, or by SpamAssassin examing the trusted network. Some systems, and particularly FM, have a wealth of spam-filtering information, for example the paid Invaluement lists.

They can also be useful for general filtering, for example if you are forwarding two accounts to the same destination, X-Resolved-to tells you which account an email came through.

[xyzzy]

Finally got a update on my ticket. They are not going to change it but they are considering documenting it. End of story.