Improvements to our bounce emails

[jfly]

We've experienced 2 problems with our bounce emails.

1. They leak mailing list members's "final" email addresses.
2. They confuse senders, who think that their email didn't get sent to anyone.

I'm not sure #2 is really solvable. I suspect that postfix's architecture involves enqueuing these forwards as completely isolated tasks that can independently fail and generate bound messages (I'd be happy to be told I'm wrong about this, though). One option would be to turn of bounces entirely, but I beleive that's even worse UX for senders.

Some detail on how emails get leaked

We've put some effort into hiding our mailing list member's email addresses by encrypting them (example).

However, if umbriel.nixos.org (our mailserver) fails to forward an email, we send a bounce back to the sender, and that leaks the bounced email addresses to the original sender. These emails look like this (sensitive and irrelevant information redacted):

<[OUR MAILING LIST MEMBER'S FINAL ADDRESS]> (expanded from <[LIST]@nixos.org>): host
[OUR MAILING LIST MEMBER'S MAILSERVER][OUR MAILING LIST MEMBER'S MAILSERVER IP] said: 550 Unauthenticated mail not allowed
from this range (in reply to RCPT TO command)

Reporting-MTA: dns; umbriel.nixos.org
X-Postfix-Queue-ID: [REDACTED]
X-Postfix-Sender: [REDACTED]
Arrival-Date: [REDACTED]

Final-Recipient: [OUR MAILING LIST MEMBER'S FINAL ADDRESS]
Original-Recipient: rfc822;[LIST]@nixos.org
Action: failed
Status: 5.0.0
Remote-MTA: dns; [OUR MAILING LIST MEMBER'S MAILSERVER]
Diagnostic-Code: smtp; 550 Unauthenticated mail not allowed from this range

What to do?

These bounces must be getting generated and sent by postfix. We should be able to configure postfix to still send a bounce, but with a different template that does not include the mailing list member's final email address. It's important that whatever we do does still include that X-Postfix-Queue-ID so we can debug reports from users.

[jfly]

I dug into this a bit, and I'm not seeing a great way to avoid leaking the member's final address. This report seems to be built in C code, not via a template:

• Here's where the "<[OUR MAILING LIST MEMBER'S FINAL ADDRESS]>" is injected
• Here's where the "Final-Recipient: [OUR MAILING LIST MEMBER'S FINAL ADDRESS]" is injected

I know enough about Postfix to know that it's a very flexible piece of software, though: perhaps it's possible to override some of these values, or apply some sort of filter/processing on the bounce email.

[ryantrinkle]

IMO if we are trying to keep list members secret, maybe bounces should go to a postmaster or list moderator rather than the sender? It is not really the sender's problem if they're sending to a valid mailing list.

[jfly]

That's an excellent point. This is definitely an "us" problem. I also don't know how to configure postgresql postfix that way. Hopefully it's possible! I'll investigate tomorrow if no one points me in the right direction before then.

[mweinelt]

One idea I proposed on matrix was to look at recipient_bcc_maps instead of virtual_alias_maps.

[jfly]

One idea I proposed on matrix was to look at recipient_bcc_maps instead of virtual_alias_maps.

This sees to work! I still had to have an empty entry in virtual_alias_maps for postfix to not complain. Mail gets forwarded, and bounces do not make it back to the original sender. However, I'm not sure I'm comfortable with the blindness this change introduces. See this draft PR for details: #679

[jfly]

Oooh, https://www.postfix.org/aliases.5.html seems to document @ryantrinkle's suggestion:

In addition, when an alias exists for owner-name, this will override
the envelope sender address, so that delivery diagnostics are directed
to owner-name, instead of the originator of the message (for details,
see owner_request_special, expand_owner_alias and reset_owner_alias).
This is typically used to direct delivery errors to the maintainer of a
mailing list, who is in a better position to deal with mailing list
delivery problems than the originator of the undelivered mail.

But I tried this, and I couldn't get it to work. I wondered if this is possibly related to us using virtual aliases, and then I found this example, which seems to forward virtual addresses to local aliases. I tried that as well and somehow introduced a mail loop.