Sender verification with SRS fails for forwarders without a mailbox

uHost

Verified User
Joined
Mar 14, 2016
Messages
23
Problem:
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:
Code:
./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 http://forum.directadmin.com/showthread.php?t=53184 and tried rebuilding exim and configuration but this didn't help. Apparently the folks at SpamExperts are known with this problem (see: https://kb.spamexperts.com/29945-other/227901-problematic-routers-firewalls-mail-servers):
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.
 
Hello,

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.

John
 
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.
 
As it's not yet released, you'd do:
Code:
cd /usr/local/directadmin/custombuild
./build update
echo "[COLOR=#000000]exim_conf_45:4.5.10:" >> custom_versions.txt
./build exim_conf
Let us know if you have any issues.[/COLOR]
 
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.
 
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=*@localdomain.com 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. [email protected] sends an email to [email protected]
  2. [email protected] is fowarded to [email protected], but exim encoded the sender with SRS.
  3. during that smtp call, gmail could call back to MX localdomain.com to ask is the [email protected] 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 [email protected].. 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 [email protected] in a perfect world.
If it was populated with that string, then I could use it to verify that [email protected] 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:
srs_router:
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!

John
 
Looks like exim.conf 4.6 is released with this fix in, thank you!
 
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.

John
 
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.
 
/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?
 
A client of ours recently reported having this same issue again. Whenever they try to send emails from PHP with the From header set to an email address that's configured as a forwarder within DirectAdmin they get an Exim Sender verify error. We're using the following version, much higher than the versions when this issue was initially reported:
Latest version of exim.conf: 4.5.43
Installed version of exim.conf: 4.5.43

Is it possible that this issue has resurfaced?
 
I'd rather not have to start a new thread about an identical issue.
After 5 years that's better anyway (because in ICT 5 years can change a lot) and then referring to this thread. I wouldn't start a new one now anymore, since it's here and it will be read. Starting a new thread now does not make munch sense anymore. A ticket would probably be better then.

Are you also using SRS?
Is it exactly the same verify error?

And yes it's possible the issue has resurfaced.
 
Thanks for the info. Good to know for next time.

I just verified: SRS is configured yeah. I can see all of it hooked up inside the Exim configuration.

Here's an SMTP session from a client we got as part of our debugging session to illustrate the error:
2023-04-07 08:33:12 CLIENT -> SERVER: EHLO test.be 2023-04-07 08:33:12 CLIENT -> SERVER: STARTTLS 2023-04-07 08:33:12 CLIENT -> SERVER: EHLO test.be 2023-04-07 08:33:13 CLIENT -> SERVER: AUTH LOGIN 2023-04-07 08:33:13 CLIENT -> SERVER: [credentials hidden] 2023-04-07 08:33:13 CLIENT -> SERVER: [credentials hidden] 2023-04-07 08:33:13 CLIENT -> SERVER: MAIL FROM:<[email protected]> 2023-04-07 08:33:13 CLIENT -> SERVER: RCPT TO:<[email protected]> 2023-04-07 08:33:13 SMTP ERROR: RCPT TO command failed: 550-Verification failed for <[email protected]>550-Unrouteable address550 Sender verify failed 2023-04-07 08:33:13 CLIENT -> SERVER: QUIT SMTP Error: The following recipients failed: [email protected]: Verification failed for <[email protected]>Unrouteable addressSender verify failed Mailer Error: SMTP Error: The following recipients failed: [email protected]: Verification failed for [email protected] Unrouteable address Sender verify failed

This does seem to us like the same issue and error.
 
I presume the [email protected] is also a real existing mail address and it's just masked to put down here. Also you already checked SPF records.
If yes, then it looks like the same issue, maybe it's best to send in a ticket in that case, so it's more quickly solved.
 
Yeah, [email protected] is a forwarder that exists inside DirectAdmin. The IP address of the server where we got the SMTP session from and where the forwarder exists is correctly listed in the SPF record. Sadly, we use lifetime licenses which no longer give access to DA ticketing, so we're kind of stuck it seems.
 
Back
Top