possible solution Re: mail missing between exim and mutt
On Mon, Sep 01, 2008 at 04:08:25PM -0500, Mark Copper wrote:
> On Mon, Sep 01, 2008 at 01:07:45PM -0500, Mark Copper wrote:
> > On Sun, Aug 31, 2008 at 07:39:32PM +0300, Andrei Popescu wrote:
> > > On Fri,29.Aug.08, 15:44:14, Mark Copper wrote:
> > > > Hi,
> > > >
> > > > I would like to request help understanding how some email went missing.
> > > >
> > > > exim's log shows the missing pieces going into maildir:
> > > > 2008-08-26 18:23:08 1KY7sS-0003mR-Be => me <myaddress> R=local_us er T=maildir_home
> > > >
> > > > fetchmail should have retrieved the mail:
> > > > poll myserver proto imap
> > > > user "me", with password "secret", is "me" here, ssl
> > > >
> > > > The mail log shows emails being retrieved and flushed one by one:
> > > > Aug 28 00:17:38 algol fetchmail[2677]: reading message me@myserver:1
> > > > 205 of 1231 (804 header octets) (853 body octets) flushed
> > > >
> > > > Only I ended up missing a number of emails.
> > > >
> > > > Where could the weak link be?
> > >
Here's my theory: having fetched 1200 emails, the system sent each
through spamassassin. Then suddenly the nameservers stop responding.
(Would an ISP do this intentionally? I *know* the network was up since
we were using VOIP at the same time.) So each message is held back until
the SA network requests time out. After this happens an undetermined
number of times, the backlog becomes so long that exim starts timing
messages out and attempts to bounce them (only my correspondents never
knew because my ISP blocked those messages, too).
On this theory, I've installed a local DNS server as advised by SA under
"FasterPerformance" and I've throttled back the rate at which fetchmail
will feed emails into the queue with "set daemon" and fetchlimit.
But that's still just not right is it? A couple thousand email backlog
to a home computer, 80-90% spam, channeled through a spam filter,
should be common enough that default settings on basic packages should
provide a sufficiently robust system...
Mark
Reply to: