Results 1 to 5 of 5

Thread: SRS with Postfix

  1. #1

    Default SRS with Postfix

    If you interested in SRS than you probably already know what it is In this tutorial I don't want to explain the SPF and SRS mechanisms. In general, i think, it is used by big companies to reduce spam but also produces some problems with forwarding mails. It is also a mystery for me why after nearly 10 years there are so few tutorials over internet about this topic. I came to a problem with my postfix configuration on OpenSuse (12.3 at the time of writting). I use aliases maps (through mysql) to forward mails sent to my domain to other (external) domains ex: sender@example.com -> me@mydomain.com -> my_priv_adr@bla.com. In this situation, if the bla.com server has SPF running than it recognises that the orginal mail domain was different than the relay domain and will block the email with SPF error. I don't want to enable SPF on my company server because i find it unnecesarry, but if I want to be able to use forwarding feature I had to use SRS. This tutorial asumes thet you have working postfix server.

    My tutorial is generally based on two other but the configuration has been made for OpenSuse
    - Mail in 2012 from an admin’s perspective – Phusion Corporate Blog
    - Sender Rewriting Scheme (SRS) für Postfix unter Debian

    1. First we'll need libsrs2 library. It can be downloaded from libsrs2 - Download the newest version now is libsrs2-1.0.18.tar.gz
    Install the package as describrd in INSTALL file. The default install location is /usr/local/lib64, so run:
    cp /usr/local/lib64/* /lib64/

    2. Download and compile pfix-srsd
    wget https://github.com/Fruneau/pfixtools.../pfixtools-0.8
    tar -xzvf pfixtools-0.8
    or
    git clone https://github.com/Fruneau/pfixtools.git
    cd pfixtools
    git submodule init
    git submodule update

    cd common
    make
    cd ../pfix-srsd
    make

    While comiling an error about missing .h files may occur but they can be installed from standard repos like:
    zypper install libev-devel
    Another missing file srs2.h can be found in libsrs2 package:
    updatedb && locate srs2.h
    cp <path>/srs2.h /usr/include/

    Finally, you should get a binary pfix-srsd. Copy that file do /usr/local/bin/

    3. Create config and secrets files
    vi /etc/default/pfix-srsd
    put:
    DOMAIN=your_domain
    SECRETS=/etc/postfix/pfix-srs.secrets
    OPTIONS=-I

    vi /etc/postfix/pfix-srs.secrets
    Here put some long random string and set permissions:
    chown postfixostfix /etc/postfix/pfix-srs.secrets
    chmod 400 /etc/postfix/pfix-srs.secrets

    Create /etc/postfix/pfix-no-srs.cf
    You can put addresses that should not be SRS’ed. If you don't know any, leave empty file and run:
    postmap /etc/postfix/pfix-no-srs.cf

    4. Create a daemon for pfix-srsd
    vi /etc/init.d/pfix-srsd

    Code:
    #!/bin/sh
    ### BEGIN INIT INFO
    # Provides:          pfix-srsd
    # Required-Start:    $local_fs $remote_fs
    # Required-Stop:     $local_fs $remote_fs
    # Default-Start:     2 3 5
    # Default-Stop:      0 1 6
    # Short-Description: pfixtools SRS Daemon backend for Postfix
    ### END INIT INFO
    
    PFIXSRSD_CONFIG="/etc/default/pfix-srsd"
    NAME="pfix-srsd"
    DAEMON="/usr/local/bin/pfix-srsd"
    PID_FILE="/var/run/pfix-srsd.pid"
    
    if [ -f $PFIXSRSD_CONFIG ]; then
      . $PFIXSRSD_CONFIG
    else
      exit 0
    fi
    
    test -x $DAEMON || exit 0
    
    case "$1" in
      start)
        echo -n "Starting Postfix SRS Daemon: $NAME"
        exec $DAEMON -f $OPTIONS -p $PID_FILE $DOMAIN $SECRETS 2>&1 &
        echo "."
        ;;
      stop)
        echo -n "Stopping Postfix SRS Daemon: $NAME"
        if [ -f $PID_FILE ]; then
          kill `cat $PID_FILE`
          rm $PID_FILE
        fi
        echo "."
        ;;
      restart)
        $0 stop
        $0 start
        ;;
      force-reload)
        $0 restart
        ;;
      *)
        echo "Usage: $0 start|stop|restart|force-reload"
        exit 1
        ;;
    esac
    5. Setup postfix
    vi /etc/postfix/main.cf
    At the EOF add:
    Code:
    #SRS Remapping
    recipient_canonical_maps = hash:/etc/postfix/pfix-no-srs.cf, tcp:127.0.0.1:10002
    recipient_canonical_classes = envelope_recipient
    sender_canonical_maps = hash:/etc/postfix/pfix-no-srs.cf, tcp:127.0.0.1:10001
    sender_canonical_classes = envelope_sender
    6. Automate and run
    chkconfig pfix-srsd on
    /etc/init.d/pfix-srsd start
    postfix reload

    You can see the service listening on ports 10001 and 10002

    7. Test
    Do a redirection in postfix in alias maps. Send emali from external domain to your redirected address and see if it will come to destination. Check the mails's header at the destination. You will notice an srs records.

  2. #2
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    12,599
    Blog Entries
    2

    Default Re: SRS with Postfix

    Although I'm sure that what is posted here is valuable,

    Isn't the standard fix just to create SPF records in your public DNS? Without getting into detail, SPF merely checks the published authorized SMTP servers for your Domain.

    Implementing SPF or SRS for incoming mail would be a completely different issue altogether, but for the stated Use Case, mail is merely outbound, being forwarded to a remote recipient mail server.

    Unless I'm misunderstanding something here?
    Also consider my thoughts are are entirely theoretical and not supported by actually testing in the real world.

    TSU

  3. #3
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    12,599
    Blog Entries
    2

    Default Re: SRS with Postfix

    Took another look at this.
    Curiously, I can't find anyone even trying what I described, which is to simply publish additional SPF records... So maybe recipient mail servers may simply fail when encountering a forwarding header instead of doing a lookup to verify <both> SPF records for the sender and forwarder.

    So, it looks like the posted solution is the "Re-mail" method which I assume would be useful if you need to send to a large number and perhaps changing recipient mail servers. The problem with re-mailing is that the original sender's identity is changed so you will need to map replies as well as forwarding.

    Otherwise, it looks like most recommendations simply ask the recipient mail servers to whitelist the forwarders... But I would then return to my original suggestion to test whether publishing appropriate SPF records might do the same. I just don't know if what I suggested will work or not, if anyone has tested

    TSU

  4. #4

    Default Re: SRS with Postfix

    I'm not sure if I understood correctly your thoughts but here is some explanaton:

    So maybe recipient mail servers may simply fail when encountering a forwarding header instead of doing a lookup to verify <both> SPF records for the sender and forwarder.
    Otherwise, it looks like most recommendations simply ask the recipient mail servers to whitelist the forwarders... But I would then return to my original suggestion to test whether publishing appropriate SPF records might do the same. I just don't know if what I suggested will work or not, if anyone has tested
    It's not like that the final destination server simply fail. The MTA with SPF will check 2 things:
    1.
    In the DNS record of the original sender domain it will check if the re-mailing (relay) server is actually authorised to re-mail. You can ask the source domain (not recipient) to whitelist your ip so you will be able to forward email from particular domain, but it is practically imposible to ask big companies like ex. google to do it for you. If you want to ask recipient server than you would have to ask every where you want send a mail and that's impossible.

    2.
    The SPF server will check the mail header. There must be information about the origin of the mail and all hops must be listed (re-mailing servers). This information is wtitten in srs records directly in mail header. If the information is correct the mail will pass, else it'll be droped.

    So, it looks like the posted solution is the "Re-mail" method which I assume would be useful if you need to send to a large number and perhaps changing recipient mail servers. The problem with re-mailing is that the original sender's identity is changed so you will need to map replies as well as forwarding.
    In this case the original sender adress remain unchanged but It shouldn't be a problem to remap sender address with sender_canonical. It all depend what you need.

  5. #5
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    12,599
    Blog Entries
    2

    Default Re: SRS with Postfix

    In the case of
    1. SMTP Relay (no re-mailing)
    It would be trivial to simply add an SPF record. Typically, the reason why you might run into a relay issue is if you are mailing using an email Domain Name based on your own publicly registered Domain Name. If the recipient mailserver <simply> does a lookup for authorized outbound mail servers for your Domain, then simply adding additional SPF records to your Domain records should be simple and feasable (after all, you own your own Domain name). This would not work if the recipient mail server does a deeper message header analysis than simply comparing to and requiring a valid SPF record.

    I dunno, things may have changed and be specific to various mail services, but if the whitelisting approach is required, I haven't had a problem getting mail server admins to implement in the past. They're already managing massive whitelist and blacklists (usually associated with anti-spam) so adding another entry is usually trivial... Just try to provide all necessary info up front so your request doesn't become a long back-and-forth.

    2. SMTP Re-mailing
    This method re-writes the message header, it's the difference between "Sent by" and "Send As"(The latter assumes a new primary identity). Although probably common to all mail systems, I've commented on this plenty of times in the past configuring MS Exchange servers (which require "Send As" to work). This seems to be acceptable universally and this seems to be what your post describes which is good.

    TSU

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •