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

 > [...]
> getmail DOES NOT generate bounce messages, nor should it because the responsibility for bouncing a message has already been handled by the upstream MTA/MDA pair that "own" the destination mailbox.

First of all, thanks for your help.

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

I am hoping that this information may not only help me, but other people too.


> 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? 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.


> 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.


> 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?


Thanks again,
   rdiez