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

R. Diez,

You mentioned earlier that you were somewhat new to the administration of mail systems, thanks for letting us know where you're coming from. I can totally understand that from your perspective, what you would like to accomplish would seem to be a straight-forward exercise in software configuration. However the universe of mail is quite a bit more complicated and this complexity is largely based upon the evolution of the mail protocols, tools, and best practices over the past 3 decades or so.

Early on mail systems were focused on just being able to communicate with each other because the standards and protocols had yet to be developed. As disparate systems began to be able to communicate, they started to establish norms of expected behavior. Some of this was by design, but there were whole areas that were not thought of at the time. The issues we deal with today (spam, phishing, forgery, privacy, security) are all areas that were "bolted on" well after the basic protocols were defined. Early on the two primary roles were MUA and MTA, but later the MDA role was added. A study of how these roles are intended to operate as well as what they're expected to do and not do will help you to understand why you're getting the advice not to do what you're trying to do. I would suggest that just because you see that a particular tool can do something is not a justification for the configuration you'd like to have; lots of tools can be used incorrectly or were just designed poorly from the outset.

To the point of what you're trying to accomplish. E-mail needs to be thought of as an end to end delivery process whereby there is a chain of acknowledgement that extends from the recipient's mailbox back to the sender. The MUA, MTA, and MDA roles carefully implement that chain of acknowledgement according to specific standards. Seeking to change this behavior without fully understanding the standards is a recipe for troubles. Tools like fetchmail and getmail are special purpose tools that don't really fit into the classic roles, they're somewhat of a hybrid. Getmail does a great job of reading messages that have already been fully delivered by an MTA/MDA pair into what is considered to be a final destination mailbox & acknowledgment of that delivery has already been passed back to the sender. Specifically (as Charles has already stated), 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.

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

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.

Bottom line, there is a lot of history in how these tools work & you deviate from accepted best practices at your peril. Study the best practices guides and learn from those who've gone down these roads before, you'll learn some cool stuff and your life will be a lot easier. :-)

--Larry


Larry Fahnoe, Fahnoe Technology Consulting, [email protected]
           Minneapolis, Minnesota       www.FahnoeTech.com