Inaccessible SMTP server, no error from mailer daemon

Question

I would like to know what behavior should I expect, when I try to send an email to an address where the corresponding server has no working SMTP daemon instance running (for whatever reason).

My expectation: Mailer daemon responsible for the outgoing SMTP request should detect that something is not right, and generate an error message for the sender.

Reality: Mail goes out without error, and seemingly just vanishes.

I know that basically everyone should be aware that an email going out without error does not automatically mean that it has arrived safely, but I think I might be missing something here.

Details:

There is a working Debian host with some other daemons running, but nothing mail-related as far as I know, so definitely nothing is listening on port 25. I have just finished setting up a domain with a DNS A record pointing to the IP of this host, but without any MX records so it will fall back to the A record if I am not mistaken.

Now unfortunately email address forwarding setup or mailserver management are not something I have prior experience with, but there is a possibility that in the future I might want to use this domain for handling emails also. So I thought it would be interesting to explore what happens if without any previous setup, I tried to send something to an address with a made-up user at this domain. Would it come back with some sensible error message? I have tried it from gmail and also from proton, but as mentioned above they went without any complaints. And that is odd knowing that there is no service there on port 25. With telnet, I get "Unable to connect to remote host: Connection refused" for port 25, which is what I would expect.

Of course in this case the reason of inaccessibility is obvious, but I don't think the situation would be much different if previously working SMTP daemon had stopped or the host went offline for example.

So what am I missing?

If this is something to be expected and not to be alarmed by, then I think it should be clear that in situations such as mine, one should set up an SMTP daemon to explicitly reject anything incoming, correct?

Update

As it was mentioned below, it turned out that I was a bit impatient, and after some time I got the notifications I was missing.

For future reference, following were the time intervals for those two services I tried.

GMail:

• First message from the mailer-daemon came roughly at T+26h, saying the system will try to deliver it for another 45 hours.
• Second message came at T+53h, and promised trying for 19 more hours.
• Finally the third message came at T+75h, stating failure.

Being puzzled by this phenomenon, I have tried this two more times with similar results:

• T+25h30m, T+51h, T+75h
• T+26h, T+50h, T+77h

All messages were accompanied by the description FAILED_PRECONDITION: connect error (111): Connection refused, which is consistent with the telnet response I got earlier.

ProtonMail:

• First a warning from the mailer-daemon was sent at T+13h, with the message that delivery will be retried until the mail is 2 days old.
• Second and final notice came at T+49h as promised.

Again, both messages showed the Diagnostic-Code: [...] Connection refused statement as expected.

Answer 1

If the mail is sent from a regular properly configured mail server, you will not see any error message instantly. You will probably get one soon (in 12 hours or so).

What is happening: the mail server that accepted mail from the user to your debian server puts this message into a queue. In the next step it is trying to empty this queue initializing connection to the smtp server appropriate for the recipient's domain. You are right, it will be either MX or A.

If the message cannot be deliverd instantly (as in your case) it will be deferred, and another attempt will be made in a few minutes/hours/days. If this another attempt fails, you may get a mailer deamon's notification, that the message is still in the queue and could not be delivered so far, but the server will keep trying.

It may last about a week. After a week the server will assume, that the message cannot be delivered at all and will send you a "returned mail" notification, saying that the message could not be delivered and it is now removed from the queue.

All these time intervals I mention, depend on the mail server configuration and you cannot tell upfront when the first notification will be mailed to you and when the server will stop trying.