Correct. And good to know that Alice’s SMTP server (or is that not what it is?) will accept the mail from Alice’s mailer, no matter what (authentication provided, of course). It was basically that part I wasn’t sure about. But now that you put it down so nicely it makes complete sense.
So can I add a little complication to the picture and ask what happens when Bob’s MX served is a Google server which accepts all email for Bob’s domain (which is the default config when you register a domain with Google Domains). But in order to read Alice’s mail, Bob needs to either sign up for a G Suite plan or configure the MX server so that mails to Bob’s email address are forwarded to his actual email account at another provider (All other emails are sent to /dev/null, I suppose).
Could you explain what happens in this forwarding step? Is the process the same as when Alice’s relay server delivered the mail to Bob’s (first) MX server? If so, why would the (second) MX server accept Alice’s email? After all, it is addressed to an entirely differed email address…
Yes, it is an SMTP server, but it is serving a particular role (eg, internal incoming, relay, external incoming).
I’m not so familiar with the specifics of Gmail configuration. And this sounds like you are asking about a half-configured set-up. But let’s try to guess the process anyway.
Before Google knows about Bob’s domain, it will reject email to it. Once it knows, because configuration has started, it will possibly accept and store that email to forward in the future. During configuration of such MX intermediaries, you sometimes can configure things as “accept email ONLY for these named addresses” or “accept all email, and use this box name as a catchall”. Then there’s the not recommended in the age of spammers configuration of “accept all email, bounce at a later date when Bob’s server refuses some of those addresses”. (That last one is the source of “backscatter” spam.)
Because it has been configured to allow relaying to that domain.
The first mail server Alice uses probably checks username and password on connection.
The relay server that uses probably strictly checks IP address of first mail server.
The MX server the relay server connects to checks recipient strictly, only allowing “local” and known relayed domains.
When that MX server is relaying, it will locally queue and attempt delivery to the relay endpoint.
Typically you use a relay MX server like that because you want someone else to maintain a high quality reliable endpoint for you, either as a main delivery point or as a backup if you go off-line. The Gmail case sounds like a main delivery point scenario.
Hm, not sure if I’m not getting something or if you misunderstood me. Here’s the route Alice’s email will take (and let’s leave Gmail out of the picture because that just causes confusion with Google Domains, i. e. Google as a registrar, which is what I’m talking about):
Alice’s SMTP server
Bob’s (first) MX server, which is run by Google. It accept emails sent to Bob’s domain, the one Alice is mailing to.
Bob’s (second) MX server (I guess that would be the MX endpoint) , let’s say it’s run by Yahoo, because that’s where Bob has his email account. It accepts emails sent to a yahoo domain. But Alice did not send her mail to a yahoo domain. Why/How does the Yahoo server accept the mail nonetheless?
My mail for literatecomputing.com is MXed to my registrar. The registrar accepts the mail for literatecomputing.com. It forwards that mail to my gmail account. Gmail accepts the message, which now has been re-addressed to my gmail account.
I think the part that you’re missing is that when a message is forwarded, the envelope gets a new address in it and gmail knows it’s for my gmail address, even though the To: address still has literatecomputing.com in it.
Yeah, forwarding is different than relaying. The forwarder will change the “envelope” (SMTP protocol, rather than “in the headers”) email address. Having envelope address not match headers is how BCC works, too.
Got this up and running, seems great. However I’d like to simply drop mail to “email@example.com”, rather than rejecting it with the usual BadDestinationAddress template. Is that achieveable via the YML file or do I need to tweak something else?
I don’t believe that functionality exists at present. It would probably be easiest to add a “blackhole destination addresses” list setting to core, and then put your noreply address in there. PR welcome!