When an e-mail message about to be send fails MTA-STS checks, it must not be delivered by design; will the sender be informed about the delivery failure? When?
When implementing mta-sts on custom domains to enforce the use of TLS connections, misconfigurations of the mta-sts.txt policy file (or a smtp-server not supporting TLS connections) will result in e-mail not being delivered as an enforced policy will require TLS connections to deliver the e-mail.
Via TLS-reporting the domain holder - not the sender - could be informed about any problems, provided TLS reporting is set-up to a different domain or tool that notifies on a different address than the domain in question.
My question is about any senders of e-mail messages. In a testcase with policy file mentioning incorrect mx records, no e-mails are delivered (as expected), but the test sender did not receive any messages about delivery problems (yet).
Is this expected behaviour? Or will the sender be informed after a number hours? If so, how many hours? - I ask because a delivery failure and NDR (non-delivery-reports) are usually returned instantly.
If a user misspelled an e-mail address or the receving server is down, the sender is informed about the trouble and can take action. Sometimes even the "delivery is delayed" is announced; not failed yet, but not delivered either.
I get the impression that the sender is not informed that a message is not delivered and is "silently blackholed / discarded". To be clear: that the message is not delivered is expected behaviour in this test case.
After running some testcases, I have experienced the following:
(This was done by a Outlook.com smtp server.)
The sender was informed about the delivery failure after 24 hours.
It was explained in my local language what was going on; here information highlights:
After 24 hours I received an error back. Confusingly the message state that the address did not exists in the target domain. Though this is true, it shouldn't have gotten this far. However, when reviewing the technical part the outlook-sending server mentioned 'failed mta-sts errors validation'. So the technical part contained the correct mta-sts validation error, but the human/user readable part only mentioned that the target address did not exist in the target server.
I guess if the address doesn't exists, any mta-sts errors are "less important" to report to the end-user. The user was advised to re-type and resend the e-mail and verify if the address with the recipient (phone was mentioned). However, even if the user followed the instructions, the next e-mail wouldn't have been delivered either, but that is beyond this testcase.
After 24 hours I received an error back. The cause for not being able to deliver the message was being unable to resolve the domain location of the recipient. (Undesired result, but logical, mx were referring to nothing.)
The technical part of the message mentioned 'DNS query failed'. Nothing of mta-sts was mentioned.
The results, unexpected:
Temporary downtime of webserver might have been a factor, though that shouldn't have mattered. - Cannot explain.
I took a while to find the correct testcase as you can see. But Testcase C describes the desired behaviour. Yes, the sender is informed, after 24 hours with outlook.com as smtp-server. The user is informed in clear language. That being said, I do have an additional opinion about the timing here, mentioned below.
Staying with the facts: I did not perform a testcase with a server trying unencrypted connections. Testcase C puts the ball into the the recipient's postmaster's court, I would be curious to see where the ball (the 'todo') would be placed, in the case of unencrypted attempts, as that cannot be solved by the recipient but must be solved by the sender or sender's postmaster.
I also did not test multiple smtp servers.
That being said, MTA-STS-validation needs to be supported by the sender SMTP (correct me in comments if I am wrong*), so if a server is so old it tries do deliver an e-mail over non-encrypted connection, it will most likely not support MTA-STS so it will not validate the MTA-STS policy and simply deliver the e-mail unprotected. * Found confirmation here, from paragraph "There is a standard...")
If somebody tries to redirect some incoming e-mail by dns-poisoning, a modern smtp-server will not deliver the e-mail to an incorrect destination. So it protects against evil doing, not against legacy.
I think the feedback delay of 24 hours is too long. Testcase C reports 11 retry attempts within that 24 hour window. Though I appreciate the system not giving up, I would argue that it might be in the interest of the sender to inform him of at least a non-regular delivery.