Sender verification with SRS fails for forwarders without a mailbox

[Richard G]

we use lifetime licenses which no longer give access to DA ticketing

It's possible to get support access for a year by paying if I'm not mistaken.

Otherwise you might hope that maybe Directadmin Support will see this thread or maybe @mxroute might be able to help you.

 

[mxroute]

I shall do my best @Richard G

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.

It's plausible that there's more to this than is being logged. First, kick exim into debug mode and make sure this log file is NOT being stored anywhere customer accessible, it WILL log plain text passwords for all users to this file during this event:

service exim stop; /usr/sbin/exim -bd -d+all  2>&1 | tee debug.log

In another terminal (or move in and out of screen sessions, your preference), tail the exim log (tail -f /var/log/exim/mainlog). Test this event again, wait for the error to be logged, and then ctrl+c out of the debug mode, then restart exim.

Now, you should have a debug.log that details this event. Hopefully you moved quickly, because that file is going to get very large very quick, and the less you have the easier this is going to be. Open that file and search for "[email protected]" (editing for what that actually is in your case, of course). The beginning of the log entries may look like this:

21:55:19 3661001

That 3661001 is important, but it'll be unique for your case. If yours were 3661001, then I'd do this:

grep 3661001 debug.log >> debug2.log
rm -f debug.log

The less customer passwords you have logged here, the less of a liability this event is going to be.

Now, find the "Sender verify failed" message and start looking around above and below it in debug2.log. I can't tell you what you're looking for here, but I'm hoping you'll know when you see it. Plenty of things succeed and fail during this process and that's all normal, what you're looking for is what failed that triggered this. For example, I just finished doing this for another "Sender verify failed" case and what I found in mine was much more informative than what was logged. For me it was:

21:55:19 3661001  ├──condition: inbound_srs {$local_part} {}
21:55:19 3661001  ├─────result: true
21:55:19 3661001  ├──expanding: ${if inbound_srs {$local_part} {}}
21:55:19 3661001  ╰─────result: true
21:55:19 3661001 calling inbound_srs_failure router
21:55:19 3661001 rda_interpret (string): ':fail: Invalid SRS recipient address'
21:55:19 3661001 expanded: ':fail: Invalid SRS recipient address'
21:55:19 3661001 file is not a filter file
21:55:19 3661001 parse_forward_list: :fail: Invalid SRS recipient address
21:55:19 3661001 extract item: :fail: Invalid SRS recipient address
21:55:19 3661001 inbound_srs_failure router forced address failure

Which obviously helped me understand my situation much better, just a few minutes ago. Hopefully it'll help you too.

 

[bertvandepoel]

Thanks for the detailed explanation. It's a good idea to look for unusual situations in the debug logs that might explain this issue. We hadn't considered that those logs were an option. We'll reach out to our client to ask if we can run such a test on their setup and if we can coordinate a time for them to perform the login. Let's hope this helps us to figure out the source of this problem! Thank you for your help

 

[Richard G]

@bertvandepoel It's a thread of earlier this year, but we are now experiencing the same issues with for example mails forwarden via outlook.com and also with the test mails from Microsoft, generated when you create a new account in the Outlook mail client.

For example I created an abuse account for one of the servers and I got the mail from mailer-daemon, but not directly due to SRS issues.

Reporting-MTA: dns; server.domain.nl

Action: failed
Final-Recipient: rfc822;[email protected]
Status: 5.0.0
Remote-MTA: dns; mail.mycompanydomain.com (is on another server but got it from mailer-daemon)
Diagnostic-Code: smtp; 550-Verification failed for <[email protected]>
 550-Invalid SRS recipient address
 550 Sender verify failed

Which is clearly wrong, because the [email protected] e-mail address already existed and I can send mails to that account from anywhere.

I've had some others this week too when using a forward but this time without real account existing, same issue with SRS mails from SNDS.