Installing SRS extensions on Postfix (Ubuntu/Debian)

Note:  This post is heavily based on this article.

Install needed dependencies:

Install libsrs:

Install pfix-srsd:

Update libraries:

Create secrets:

Save to /etc/default/pfix-srsd:

Save to /etc/init.d/pfix-srsd:

Enter addresses that you need to be excluded from SRS:

Add SRS settings to Postfix:

Install pfix-srsd init script:

Apply new changes:



11 comments on “Installing SRS extensions on Postfix (Ubuntu/Debian)
  1. Kaijia Feng says:

    Thanks a lot for your post! I think you should add

    chmod +x /etc/init.d/pfix-srsd

    to make

    service pfix-srsd start|stop


  2. Josh says:

    Any idea how to set this up for multiple domains? I saw somewhere that you need to run multiple daemons and setup transport rules to route to the correct one. But I have no idea how to do that. Do you know?

  3. Hi Josh, IIRC, all domains that Postfix accepts will be supported. Email addresses will be rewritten like [email protected]. If you want for DOMAIN to vary, you’d probably have to do some advanced stuff, certainly involving multiple daemons, and probably involving some Postfix transport rules.

  4. Elijah Jethro says:

    any idea why this would be re-writing the


    but not

    From: ?


  5. Hi Elijah,

    SRS changes the envelope sender (the ‘mail from’ address when communicating with SMTP servers). This correlates to the ‘Return-Path’ header field in SMTP. The ‘From’ header field is defined in the data portion of the SMTP communication. I could explain the reasons why, but explains it better than I could. Also, changing the ‘From’ header field would cause replies to break, unless ‘Reply-To’ is set (and recognized by the MUA).

  6. Elijah Jethro says:

    thanks for the reply Ameir.

  7. deoren says:

    Thanks so much for the detailed notes. They’re very well laid out and they got me very far along in the process of getting pfix-srsd running.

    The part I had trouble with was the secrets file. When I created it I followed the directions, but as luck would have it I had two issues:

    * Too much content (100 lines vs the 10 that seemed to be the max allowed)

    * Invalid content (The equals sign was included at the end of each line and had to be removed)

    Once I got that fixed and followed the rest of the directions I got pfix-srsd working (at least as far as I can tell).

    I also went with a fork of the main repo as the author fixed the return code for applied necessary changes to work around a bug with the option to ignore external domains.

  8. Thanks for the valuable info. I will look into this when I have a moment and update the article accordingly. Also, it looks like the fork has been pulled into the upstream, which is great; I’m glad to see the project moving forward.

  9. deoren says:


    You’re welcome!

    I’m going through and researching now how to setup multiple daemons in order to serve different domains. I understand that one daemon can serve multiple domains, but as was mentioned it sounds like the Return-Path header would be rewritten to whatever domain the single instance of pfix-srsd is operating for. While certainly acceptable in many cases, I’d like to have each domain have their own Return-Path.

    I’m researching the transport rules now. Fun!

  10. deoren says:


    I’ve not made any headway in setting up multiple transport rules for a pfix-srsd multi-instance setup, but I’m running into an issue with a single setup that I was hoping to get your help with. Thanks in advance for reading this.


    * One mail server handling one domain. We’ll call it
    * Outside group sends an email to a virtual alias ([email protected])
    * The envelope “from” part is rewritten to the SRS’d address
    * The virtual alias is expanded and the new recipient is sent a copy of the email, but …
    * The remote mail server rejects the email, sending it back to the SRS’d address
    * My mail server receives it and instead of decoding it interacts with it “literally” and generates a non-delivery notification.
    * I would expect that notification to go to the original sender (or at the very least back to the alias address)
    * Instead, it happens to match a wildcard alias entry and the addresses assigned to the wildcard alias receive the non-delivery notification.

    Is that how it is supposed to work?

    I have only minor differences in the configuration I’m using vs what you have in your guide:

    From the /etc/default/pfix-srsd conf file:

    OPTIONS=”–ignore-outside –separator + –verbose –encoding 10003 –decoding 10004″

    From /etc/postfix/

    recipient_canonical_maps =

    # Combined list of email addresses to NOT rewrite

    # SRS decoding daemon for

    recipient_canonical_classes = envelope_recipient

    sender_canonical_maps =

    # Combined list of email addresses to NOT rewrite

    # SRS encoding daemon for

    The /etc/postfix/ file contains two entries, both for [email protected] and [email protected].

    I know the second one isn’t used, but it did not seem to harm anything with having it there.

    Lastly, I haven’t been able to find a really great definition of the “-I” or “–ignore-outside” options. The help file mentions:

    ‘do not touch mails outside of “domain” in decoding mode’

    but does that refer to a situation like this where the outside domain sends something in and it is SRS’d into another address? If so, then my use of that option is why the decoding did not happen and I will want to disable that option.

    If that is true, why _would_ you use the option?

    Thanks in advance for your help, I really appreciate it.

  11. Cliff says:

    Hi mate. I wanted to thank you for the howto. Really appreciate the effort! 🙂

1 Pings/Trackbacks for "Installing SRS extensions on Postfix (Ubuntu/Debian)"

Leave a Reply

Your email address will not be published. Required fields are marked *