"David (Libra Designs)" <david(_at_)libra-designs(_dot_)co(_dot_)uk> writes:
Our internal mail server is a SuSE9.2 linux box running Fetchmail 6.2.5
to collect mail from our ISP's catchall POP3 mailbox (single mailbox so
we're using multi-drop) and then passes it to our internal Postfix
(2.1.6) server. Our ISP doesn't add any form of envelope-to headers
Please see <http://home.pages.de/~mandree/mail/multidrop> - this can
never work reliably. Note that you can never notice if the upstream mail
was Bcc:d - if the recipient knew this, it would constitute a major (as
in size of a barn door) information leak.
Initially I thought the problem was actually with our ISP
It is. They don't save the envelope header in spite of offering a domain
mailbox scheme.
as they run multiple MTAs and it seemed to be emails that had passed
through two particular MTAs that were causing the problem. However,
investigating further I now don't understand why our Fetchmail setup
works correct at all. All of our mail actually has our catchall
mailbox name as the first "Received" header that Fetchmail will
see. Looking at it now, I would therefore expect Fetchmail to try to
pass everything off to this catchall mailbox on our internal Postfix
server - Postfix will see that it doesn't exist and therefore "dump"
it to postmaster.......
You can see fetchmail's desperate guesswork by running fetchmail -Nvv.
Does anyone have any insight?
Try selling your ISP a clue, or switch to an ISP that has a clue about
domain mailboxes. It was the wrong decision to ever enable multi-drop in
fetchmail for setups that don't save the envelope information, and we'll
have to rectify this for the next major release. We'll already see
warnings in the next minor release.
--
Matthias Andree