RSFA is short for recipient specific from address. It provides a custom modification of (mainly) mailcow's postfix setup to support usage of recipient specific from (or sender) addresses.

To impede credential stuffing attacks (actually your mail users should be smart enough to not use the same password on multiple sites, but who knows...) and to facilitate monitoring of usage or leakage of e-mail addresses when signing up to foreign services, some people consider it being smart to utilize service specific e-mail addresses for account registration.

With a "normal" mailcow installation, this can be typically be achieved by leveraging the plus-extension scheme:

Just use user+extension@domain.tld instead of user@domain.tld as your e-mail address and you are all set. Mailcow can be configured how the plus extension should be handled - I prefer rewriting of the subject line by adding a [extension] tag over direct delivery to a folder named extension.

However, there's a second solution for service specific e-mail addresses: subdomain addressing

Subdomain addressing provides an additional subdomain for every configured user. That subdomain is then being configured as catch-all and every incoming e-mail will be delivered to the respective user's mailbox:

Any mail sent to arbitrary-string@user.domain.tld will be delivered to user@domain.tld.

Both addressing schemes shown above do exactly what we'd expect. However, there's one pitfall:

Whenever you receive an e-mail to such an address and want to reply to it, the response would be sent from your mail account and your actual e-mail address would be used as sender address instead of the recipient/service specific one.

This could be circumvented by using an MUA that allows rewriting of the respective header lines, but this is cumbersome and not even possible on many MUAs, especially on your mobile devices.

Let your mail system do the work for you:

Every incoming mail addressed to either a plus-extension address or a subdomain address will be processed to reflect information on the original To-address in the mail's subject line as follows:

Whenever you reply to such an e-mail (or even write a new mail having respective tags in the subject line), the postfix submission service (well, actually the cleanup service that is triggered from submission) will apply a filter to these messages and

• Remove the tag from the subject line
• Rewrite the header from address accordingly
• Validate sender permissions for subdomain addressing
• Remove already calculated DKIM signatures
• Reinject the message for delivery

Effectively, this will yield the following result:

The position of the tag within the subject line doesn't play any role, it might occur anywhere.

Check out this repository to your mailcow:dockerized installation directory (the directory where mailcow.conf can be found) on your docker host.

1. Login to mailcow UI as mailbox user
2. Navigate to Mailbox->Settings
3. Define "In Subject" as tagged mail handling routine:
   

Just execute the script SDA_setup.sh from the RSFA folder on your docker host.
This will:

• retrieve all mailbox names from all domains

• create a new subdomain "mailboxname.domain" for each domain with dots (".") in mailbox names being translated to dashes ("-"), e.g.:
  Mailboxes:

  • [email protected]
  • [email protected]

  Created subdomains:

  • joe.domain.tld
  • john-doe.domain.tld

• create a catch-all alias for the newly created subdomain, pointing to the respective mailbox, e.g.:
  @john-doe.domain.tld -> [email protected]

• create a sender ACL to allow mailbox to send as *@subdomain

• copy the DKIM configuration of each subdomain to all of its newly created subdomains

Afterwards you still have to add respective MX (and DKIM / SPF) records to your DNS; check the DNS settings for each of your subdomains in mailcow UI for advice.

Execute install.sh from the RSFA folder on your docker host.

This project had been derived from a manual setup I've applied to my own mail system over time. You might use it as is, but please be aware that this is far beyond production grade code quality. Use at your own risk!