Re: How getmail deals with delivery errors and with bounce e-mails

R. Diez,

I will try briefly to answer your questions below, but what I was just urging you to do is to *study* the roles and responsibilities of MUA, MTA and MDA software & at the same time see how getmail fits into the picture as a special hybrid tool. You're persisting asking specific "why" questions, but the questions result from your not understanding the proper function of the roles above. They seem simple to you, but the answers are anything but simple, that's why there are best practice guides. Too many people have been bull-headed, thinking they can just figure it out and get it to work but there is a subtle but important difference between something that appears to work & something that works correctly. You need to study this stuff to better understand the difference.

Brief answers in-line below.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, November 3, 2020 9:33 AM, R. Diez <[email protected]> wrote:

> I would like to understand why "the responsibility for bouncing" has already been handled and it is too late to do it later.

There is only one destination mailbox, and thus only one final destination MDA and MTA. With a catch-all configuration at your ISP, the mailbox at the ISP is the final destination mailbox. It's MDA accepts the message for delivery to the mailbox, end of story.

> > The trouble with your approach is that the final MTA/MDA don't know enough to bounce
> > a message because you're using a catch-all mailbox.
>
> What information is missing?

A catch-all mailbox accepts all mail for a given domain OR acts as a default destination if no other mailboxes match the destination address. Either way, there is no bounce possible because the catch-all accepts the messages. This is why catch-all setups are a bad idea & the proper approach for your partially connected scenario is to have a 1-1 correspondence between the mailboxes on internal and ISP servers.

> Even when using a multidrop or catch-all mailbox, we have the envelope recipient in the X-Original-To header
> (or similar header, depending on the server).
>
> I am not sure about the envelope sender. The e-mails I am looking at have no "Sender" header. We could use header "Return-Path" anyway. The
> getmail configuration can use %(sender) for that.

You're barking up the wrong tree by thinking you can get something from the headers to solve the problem. The final MDA (in your case at the ISP) has already made the decision not to bounce anything because you've asked for the catch-all which accepts everything.

> > But since they're designated as responsible for the domain, they've already acknowledged delivery.
> > You can't later on turn around and say "oh, that mailbox really doesn't exist, sorry..."
> > because you're seeking to remain only partially connected to the 'net.
>
> OK, but why not? What would exactly be the problem? After all, there are autoresponders like "on vacation" or "e-mails to this address will
> not be read" already.

You need to study the MDA and MTA roles and realize that in your case the ISP is the final MDA/MTA, not your server. Auto-responses are not bounces, don't mix the ideas. An auto responder can only be properly invoked for a valid mailbox.

> > The proper approach for a partially connected environment is to maintain a 1-1 correspondence between the mailboxes on
> > the internal server and the ISP's server so that the ISP can intelligently bounce non-deliverable messages.
>
> Yes, but I am still resisting. 8-)
>
> > The other approach is to have your domain's MX records pointing at the ISP's server, but arrange for
> > firewall rules that allow communication between your internal and the ISP's servers.
>
> Of course, but I am still resisting this one too!
>
> > Don't misunderstand Dovecot's ability to generate a bounce message, it is there because Dovecot
> > is typically deployed as an MDA with communication to an MTA. When the MTA hands off an undeliverable
> > message to Dovecot, Dovecot needs to be able to generate a bounce and hand it back to the MTA for delivery.
>
> Well, is that not exactly the case I have in mind? The MTA got the e-mail, the MDA tries to deliver it, and Dovecot rejects it.
>
> What is the difference? Is it that the original SMTP connection from the client is still up? But I doubt it, because if Dovecot has a
> setting to generate bounces, then the bounce mail is being sent afterwards on a separate SMTP connection. What is the matter if I send that
> bounce e-mail much later, like 2 hours later?

This has nothing to do with SMTP, other mail transports would have similar issues.

Your server is neither the MDA nor MTA because those functions have already been performed by the ISP's servers on behalf of your domain. Again, your catch-all config at the ISP means that's where the final mailbox is. Your use of getmail has given you the idea that your server is able to be something that it cannot be, thus why we're trying to tell you that getmail or Dovecot cannot generate bounce messages.

As an aside, you appear to be focusing on this because of security. Your DNS traffic requires open ports and in some respects represents a more significant risk than does a properly configured MTA. Don't think that just because you don't run an internet-connected SMTP MTA that you're secure, you're not. You'll likely be better served by choosing a good firewall and MTA than trying to bend or wedge getmail into a role that it wasn't really designed for.

> Thanks again,
> rdiez

Yup, but I know my answers ain't the ones you wanted. ;-}

--Larry