On 10/21/06, Tim Johnson <tim(_at_)johnsons-web(_dot_)com> wrote:
* Bart Schaefer <barton(_dot_)schaefer(_at_)gmail(_dot_)com> [061021 10:19]:
On 10/20/06, Tim Johnson <tim(_at_)johnsons-web(_dot_)com> wrote:
*but* it takes some time before it is actually delivered.
Hello Bart:
Do you have fetchmail delivering directly to procmail, or does it
delver first to the local MTA (e.g., sendmai)l and then the MTA
delivers to procmail?
Check your MTA mail queues (remember there is a separate "submit
queue" if you're running a recent version of sendmail, so you need to
check both queues; "mailq" and "mailq -Ac"). Depending on how
fetchmail talks to the MTA, the mail coming in that way may be getting
queued first and then delivered later during the scheduled queue runs,
whereas the mail coming from mutt is never queued.
I just ran several checks: turnaround was consistantly 3 minutes,
still less that the almost imediate as when I send from mutt
to netscape...
mailq and mailq -Ac both consistantly show empty.
Another possibility is that the mail coming from fetchmail is
undergoing DNS checks that are taking extra time, but I wouldn't
expect 10 minutes for that.
but perhaps 3 minutes?
Also, check the process table while you are waiting for the mail to
arrive. It may be that a problem procmail process is locking the
mailbox. Then subsequent procmail processes would queue up and wait
for the lock to be released. It's a long shot, but I've run into this
problem before with a botched recipe.
If procmail runs into a situation like this the variables LOCKTIMEOUT
and TIMEOUT come into play. Their defaults are 16 to 17 minutes.
--
-- Matt Dunford -- zenmatic(_at_)gmail(_dot_)com
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail