Strange exim behavior

[mxroute]

I don't like not knowing answers, and I suspect that no one is going to jump up and tell me the answer here because it's a bit of a head scratcher. But if I post this, maybe one day someone will come across this while experiencing the same thing and step up to find the answer.

I have my system configured to send all outbound mail through an external relay. Simple config, really:

/etc/exim.transports.pre.conf

auth_relay:
  driver = smtp
  message_linelength_limit = 52428800
  tls_tempfail_tryclear = true
  headers_add = X-AuthUser: ${if match {$authenticated_id}{.*@.*}\
  {$authenticated_id} {${if match {$authenticated_id}{.+}\
  {$authenticated_id@$primary_hostname}{$authenticated_id}}}}
  headers_remove = Received
  dkim_domain = ${if eq{${lc:${domain:$h_from:}}}{}{$primary_hostname}{${lookup{${lc:${domain:$h_from:}}}lsearch,ret=key{/etc/virtual/domainowners}{$value}}}}
  dkim_selector = x
  dkim_private_key = ${if exists{/etc/virtual/$dkim_domain/dkim.private.key}{/etc/virtual/$dkim_domain/dkim.private.key}{0}}
  dkim_canon = relaxed
  dkim_strict = 0

/etc/exim.routers.pre.conf

smart_route_forward:
    driver = manualroute
    domains = ! +local_domains
    ignore_target_hosts = 127.0.0.0/8
    condition = ${if !eq{$original_domain}{$domain}}
    condition = ${if !eq{$original_domain}{}}
    condition = "${perl{check_limits}}"

    transport = remote_smtp_forward_transport

    route_list = * filtergroup.mxroute.com
    no_more

smart_route:
    driver = manualroute
    domains = ! +local_domains
    ignore_target_hosts = 127.0.0.0/8
    condition = "${perl{check_limits}}"

    transport = remote_smtp

    route_list = * filtergroup.mxroute.com
    no_more

I'm under attack by a botnet exclusively targeting domains that are pointed to my server but are not added to my server. So the only log entries I get for each event are just one. Example:

2023-05-13 17:57:41 H=([222.187.232.115]) [43.248.191.156] F=<[email protected]> rejected RCPT <[email protected]>: authentication required

That's not the fun part. Here's the fun part. At that same time, the server behind filtergroup.mxroute.com mentioned in the configs above, logs this in it's postfix log:

May 13 17:57:41 filter006 postfix/smtpd[10184]: NOQUEUE: reject: RCPT from sunfire.mxrouting.net[49.12.120.198]: 450 4.1.8 <[email protected]>: Sender address rejected: Domain not found; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<sunfire.mxrouting.net>

Now if you're not already intrigued, let me elaborate: The DirectAdmin-based server sunfire.mxrouting.net received an email for a domain that isn't in it's system with no SMTP authentication, thus it responded "authentication required" as it should, for someone trying to open relay through it. But then, why did exim on sunfire.mxrouting.net reach out to my relay at filtergroup.mxroute.com and submit that information to postfix?

It's baffling, honestly. I think it's a bug in exim, personally.

(I didn't censor the domain names because the recipient is not a customer, and yet their MX records point to my server. Perhaps they used to be a customer, I wouldn't know anymore. But it's not customer data, it's not private.)

 

[Richard G]

Now if you're not already intrigued

I was instantly intrigued because I also don't like odd things happening. However I'm not nearly a mail specialist like you are.

However.... I did encounter something similar not too long ago with something else in Exim. Now issue is that I'm getting a bit older so a memory error is preventing me from remembering me if you helped me with that or not. You probably did.

But to make a short story long, certain things, which should not happen, did in fact happen, because the order of taking care of that certain procedure was the wrong way around in the exim.conf file.

So to make it a bit more clear. Could it be the case, that maybe, just maybe, the exim.conf is causing that the mail is firstly forwarded to your postfix server, and then later in the config the "authentication required" thing is handled?

I mean, maybe it's handling the transport before the routers or the other way around, maybe (while it shouldn't) causing this?

If not, then I hope somebody can help you, because I'm sure I can't unfortunately.