OpenSMTPd's MTA is not foolproof: if target's DNS is not properly configured, the MTA fails to forward the message.

[spamjeney]

First of all, you have made a great job with OpenSMTPd, thank you for all your efforts, you are really great!

I have discovered an interesting issue if the DNS zones are not properly set.

The MTA of OpenSMTPd fails to find the target’s MX server, if the DNS administrator of the target’s domain made a mistake in the configuration. If the target’s domain MX record (1) contains a line where no A and/or AAAA records exist, even if (2) other MX records are available and valid, the MTA will send the message to itself (loopback).

For the sake of anonymity I have changed the values of different components as follows:
— the name of the originating domain is ORIGIN.hu
— the name of the target domain is TARGET.hu — this is a completely separated domain, no common MX servers exist
— the email of the sender is [email protected]
— the email address of the addressee is [email protected]
— the originating domain’s SMTP server is MX.ORIGIN.hu
— the IP address of the originating domain’s SMTP server is ORIGIN_IP
— all other values are simply replaced by the pattern CENSORED, but I kept the envelope (and other) ID’s to keep it traceable.

You can check that the problem persists as it could be repeated if you configure a domain zone stupidly — see later how.

Chronologically the following events happened:

1. I have found the following error in the logs:

Jun 14 17:14:51 mail smtpd[17422]: 0661f4275680f262 smtp connected address=CENSORED host=CENSORED.hu
Jun 14 17:14:52 mail smtpd[17422]: 0661f4275680f262 smtp tls ciphers=TLSv1.2:ECDHE-ECDSA-AES256-GCM-SHA384:256
Jun 14 17:14:52 mail smtpd[17422]: 0661f4275680f262 smtp authentication user=[email protected] result=ok
Jun 14 17:14:58 mail smtpd[17422]: 0661f4275680f262 smtp message msgid=8cebc743 size=8621984 nrcpt=1 proto=ESMTP
Jun 14 17:14:58 mail smtpd[17422]: 0661f4275680f262 smtp envelope evpid=8cebc7437ccd4258 from=[email protected] to=[email protected]
Jun 14 17:14:58 mail smtpd[17422]: 0661f42a0ec269e9 mta connecting address=smtp:https://ORIGIN_IP:25 host=MX.ORIGIN.hu
Jun 14 17:14:58 mail smtpd[17422]: 0661f42a0ec269e9 mta connected
Jun 14 17:14:58 mail smtpd[17422]: 0661f42b324d0a52 smtp connected address=ORIGIN_IP host=MX.ORIGIN.hu
Jun 14 17:14:58 mail smtpd[17421]: senderscore: link-connect addr=ORIGIN_IP score=127
Jun 14 17:14:58 mail smtpd[17422]: 0661f42a0ec269e9 mta tls ciphers=TLSv1.3:TLS_AES_256_GCM_SHA384:256
Jun 14 17:14:58 mail smtpd[17422]: 0661f42a0ec269e9 mta cert-check result="unverified" fingerprint="SHA256:CENSORED”
Jun 14 17:14:58 mail smtpd[17422]: 0661f42b324d0a52 smtp tls ciphers=TLSv1.3:TLS_AES_256_GCM_SHA384:256
Jun 14 17:14:59 mail smtpd[17422]: 0661f42b324d0a52 smtp failed-command command="MAIL FROM:[email protected]" result="530 5.7.0 only authenticated senders are allowed to send emails on behalf of our users... Try harder!"
Jun 14 17:14:59 mail smtpd[17422]: 0661f42b324d0a52 smtp disconnected reason=quit
Jun 14 17:14:59 mail smtpd[17422]: 0661f42a0ec269e9 mta delivery evpid=8cebc7437ccd4258 from=[email protected] to=[email protected] rcpt=<-> source="ORIGIN_IP" relay="ORIGIN_IP (MX.ORIGIN.hu)" delay=7s result="PermFail" stat="530 5.7.0 only authenticated senders are allowed to send emails on behalf of our users... Try harder!"
Jun 14 17:14:59 mail smtpd[17422]: 0661f42a0ec269e9 mta error reason=IO Error: read failed: Connection reset by peer

That is, the server tries to send the message to itself. (?)
Obviously, firstly I tried to find the mistake in the smtpd.conf configuration file.
I have not included the configuration, as I am sure that configuration could not be a problem here.
It took me a few hours to figure out what has happened, what is behind this anomaly.

2. A few hours later, I realized that the TARGET’s DNS settings are a bit weird:

% host -t mx TARGET.hu
TARGET.hu mail is handled by 0 msCENSORED.msv1.invalid.outlook.com.
TARGET.hu mail is handled by 0 TARGET-hu.mail.eo.outlook.com.

And the first MX record does not have an IP (this is definitely a misconfiguration):

% host msCENSORED.msv1.invalid.outlook.com.
Host msCENSORED.msv1.invalid.outlook.com not found: 3(NXDOMAIN)
% host TARGET-hu.mail.eo.outlook.com.
TARGET-hu.mail.eo.outlook.com has address 52.101.73.2
TARGET-hu.mail.eo.outlook.com has address 52.101.73.4
TARGET-hu.mail.eo.outlook.com has address 52.101.73.1
TARGET-hu.mail.eo.outlook.com has address 52.101.68.32

The misconfiguration lies in the fact that msCENSORED.msv1.invalid.outlook.com. pattern should appear in the TXT record of the TARGET domain (and not in the MX record), probably the administrator was not familiar with DNS zones.
See eg.
https://answers.microsoft.com/en-us/msoffice/forum/all/cant-add-mx-record-to-verify-domain-for-office-365/a0c85344-bab7-45e7-94bc-c0ed966712f2
https://learn.microsoft.com/hu-hu/microsoft-365/admin/get-help-with-domains/create-dns-records-at-any-dns-hosting-provider?view=o365-worldwide&redirectSourcePath=%252fen-us%252farticle%252fCreate-DNS-records-at-any-DNS-hosting-provider-for-Office-365-7b7b075d-79f9-4e37-8a9e-fb60c1d95166#bkmk_verify

In this case, OpenSMTPd will send the messages of TARGET.hu to itself MX.ORIGIN.hu (loopback).

To reproduce the situation, set a domain with an invalid MX record (which does not have A/AAAA record) as a first line and a second line of MX record, where valid A/AAAA IP addresses are available. If you send messages to this domain, OpenSMTPd has this weird behavior and it fails to deliver the message.

Even though the problem lies in the misconfiguration of a domain which is out of our control, MTA’s should handle these situations. OpenSMTPd should be foolproof that when MX record does not yield A or AAAA records, it should not try to send the message to itself (loopback), but try to resolve the other MX records. If no valid MX records are found, the message should not be delivered to anywhere. Anyway, loopback is definitely not a good idea.

I have not checked the source code, I do not know where it comes from.

Unfortunately more and more misconfigurations will appear. OpenSMTPd should be robust enough to circumvent such misconfigurations. Malfunctioning should be avoided, even if external factors are the source of the problem.

I hope it helps.