Michael Abbott wrote:
Unfortunately, it seems I now need to open the complicated box labelled
"e-mail file locking", and I don't know how my system does it.
Now you know why fetchmail wants to talk to SMTP by default, and why ESR
doesn't like the mda option. (I insisted that it stay when he wanted to
remove it.)
I'm on FreeBSD 4.9 running sendmail with mail delivery to old fashioned
Unix mailboxes in /var/mail.
Why not let fetchmail talk to your sendmail then?
Well, that's what I do at the moment, and I agree it's the obvious thing
to do, and it's what I'd much rather do.
Unfortunately, there's a rather nasty bit of grit in the ointment here
(this is what I referred to as "impedance mismatching" in my original
message). It appears that fetchmail retrieves messages one at a time and
hands them on the sendmail one at a time, which means that the POP
retrieval session is held open waiting for sendmail to respond.
Alas, some e-mails cause sendmail to sit on its hands for ages (a minute
or two, I guess; not exactly sure), probably resolving nonexistent
domains. Also unfortunately my ISP's POP server sometimes loses patience
when this happens and the session is broken.
This means that when an e-mail of this type is encountered it sticks in
the queue and can cause mails preceding it to be delivered over and over
and over (etc). I reported this problem earlier in the year, someone then
suggested I deliver directly to procmail, which I tried, but it didn't
work (for the two reasons that have shown themselves today).