Results 1 to 14 of 14

Thread: Sender verification with SRS fails for forwarders without a mailbox

  1. #1
    Join Date
    Mar 2016

    Sender verification with SRS fails for forwarders without a mailbox

    When a forwarder is created and there is no local mailbox sender verification fails if mail is relayed through SpamExperts. This is on a setup with:
    ./build set eximconf yes
    ./build set eximconf_release 4.5
    ./build set blockcracking yes
    ./build set easy_spam_fighter no
    ./build exim
    ./build exim_conf
    Setting easy_spam_fighter to yes doesn't change anything.

    I have seen and tried rebuilding exim and configuration but this didn't help. Apparently the folks at SpamExperts are known with this problem (see:
    Resolving SRS issue with Direct admin Exim - SpamBlocker 4.4*

    In the newer versions of Exim SpamBlocker (4.4*) for Direct Admin, there are some issues with SRS, when using sender verification on outbound emails with SpamExperts. To resolve this, simply move the srs_router above the virtual_aliases router. Once you do this, you will be able to enable SRS on the sending mail-server and continue to use sender verification on the SpamExperts side. So the config should then look like this:

    srs_router: driver = redirect srs = reverseandforward data = ${srs_recipient}
    virtual_aliases: driver = redirect .include_if_exists /etc/exim.srs.forward.conf allow_defer allow_fail condition = ${if eq {}{${if exists{/etc/virtual/${domain}/aliases}{${lookup{$local_part}lsearch{/etc/virtual/${domain}/aliases}}}}}{yes}{no}} data = ${if exists{/etc/virtual/$domain/aliases}{${lookup{$local_part}lsearch*{/etc/virtual/$domain/aliases}}}} file_transport = address_file group = mail pipe_transport = virtual_address_pipe retry_use_local_part #include_domain = true
    So I moved the block with srs_router above the virtual_aliases block and restarted exim and my problem was resolved.

    Could you please take a look at this and fix this? If you need access to a server with this problem I can provide.

  2. #2

    I've moved the srs_router above the virtual_aliases router.
    This has been released in exim.conf 4.5.10, but has not yet been pushed as "stable".

    Please try out and let me know if you have any issues.
    I've tested it on our test box, and normal deliveries work and forwarders also still work using the SRS headers.


  3. #3
    Join Date
    Mar 2016
    How do I get and install exim.conf 4.5.10? I already tested by manually moving srs_router above virtual_aliases router and that fixed the problem for me.

  4. #4
    Join Date
    Jul 2008
    Greetings, Richard.

  5. #5
    As it's not yet released, you'd do:
    cd /usr/local/directadmin/custombuild
    ./build update
    echo "exim_conf_45:4.5.10:" >> custom_versions.txt
    ./build exim_conf
    Let us know if you have any issues.

  6. #6
    Join Date
    Mar 2016
    OK thanks, I just installed exim.conf 4.5.10.

    This is weird. I thought I already tested this by moving srs_router manually above virtual_aliases but it still doesn't seem to work. The sender verification still fails.

    Could you fix this? If you need anything from me just let me know in the ticket, I could give you access to the server.

  7. #7
    I've got an updated 4.5.10 version, which I believe has been figured out.
    The issue was the remote sender verify, where a remote box (after receiving a message from the local box) would as:
    "is this SRS0=* email allowed to be sending?"

    and because the local exim would have no idea who the SRS0 email was, the verify failed.
    I believe it worked with local inboxes because the libsrs does some magic internally to check that inbox (decoded from the SRS0 value) but not 100% on that.

    In any case, the 4.5.10 change simply uses the "srs = reverse" option to confirm it's a valid SRS0 email from this box, on a local domain.
    If that is true, the message is accepted and sent to :blackhole:.
    We do not want to relay the message to the srs_recipient (first original sender) as this would essentially be back-scatter if the final forwarded destination rejects it.
    The final destination "should" use the original sender when clicking "reply" (did in my tests anyway), so your local box doesn't need to be relaying the replies.

    So the basic steps are as follows:
    1. sends an email to
    2. is fowarded to, but exim encoded the sender with SRS.
    3. during that smtp call, gmail could call back to MX to ask is the is valid.
    4. DA figures out that is a valid SRS0 email (encoding matches) and is a local domain, so it "accepts" it
    5. gmail had no intention of actually sending any DATA, so it hangs up and accepts the message

    If my assumption is correct, there shouldn't really be any major cases where gmail tries to deliver an actual email to the SRS0 address.. which should go to but again, we don't want that, as it's basically an open relay, hence I've opted for the :blackhole: option.

    Anyway, the original issue wasn't the SRS encoding/forwarding of the message.
    The issue was the sender verify check done by the final servers to the middle/local server, where it used to say "nope, no SRS0 addresses here", where it should have accepted them for remote verification purposes.

    I was able to sniff through the exim srs code, and did find a variable srs_orig_recipient, which I believe would store the in a perfect world.
    If it was populated with that string, then I could use it to verify that actually existed, for a more accurate verify.
    But for now, this should be fine, since it's encoding is verified anyway, and it's dropped, so no spamming can be done.

    I've not pushed it yet, but for anyone who wants to try it out, please let us know if you have any issues.

    This is the main change, added just after the "userautoreply:" section:
    driver = redirect
    condition = ${if exists{/etc/exim.srs.forward.conf}}
    srs = reverse
    data = :blackhole:
    domains = +local_domains
    where we also removed the srs_router section, which is different, from further down.
    I'm pretty sure it never hit that router.. but it's wrong location was the main reason the verify failed.
    Note that this new version of the srs_router does better checks to ensure srs is actually enabled and drops the messages instead of relaying them (it never could relay simply due to it's location being too far down)

    Hope this helps!


  8. #8
    Join Date
    Mar 2016
    Looks like exim.conf 4.6 is released with this fix in, thank you!

  9. #9
    There is no 4.6 of any significance. Ignore the file that you see. It's just the template for future changes, and may actual go backwards in some cases, as it's not yet maintained.
    As mentioned above, the version is 4.5.10.

    I've pushed this in the versions.txt now, so should be showing up as standard shortly.


  10. #10
    Join Date
    Mar 2016
    Looks like this is broken again. I'm unsure what triggered this but I'm getting the following:
    550 Administrative prohibition

    I'm on exim.conf version 4.5.11

    The only change I can think of which I have done recently (besides regular updates) is I have updated pcre by setting new_pcre to yes and recompiling almost all services including exim.

    Please assist.

  11. #11
    Join Date
    May 2014
    The only changes on version 4.5.11 is:

    .include_if_exists /etc/exim/local_part_suffix.conf


    Maybe you can check 4.5.10?

  12. #12
    Join Date
    Mar 2016
    /etc/exim/local_part_suffix.conf does not exist on my system.

    Maybe you can check 4.5.10?
    What do you mean exactly? Install 4.5.10 and try? If yes, how?

  13. #13
    FYI: 4.5.12 has been pushed. It allows for the / character, which was previously blocked, causing issues with some instances of an SRS email format.


  14. #14
    Join Date
    Mar 2016
    Thank you John, this fixes the problem indeed.

Posting Permissions

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