[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: procmail slow email delivery



    "Richard" == Richard Otte <otte@ucsc.edu> writes:

    Richard> It was not like this in /etc/exim/exim.conf, where I had:
    Richard> qualify_domain = otte.ucsc.edu local_domains =
    Richard> localhost:otte.ucsc.edu (I suspect the .conf~ file is a
    Richard> backup that didn't get removed).  So I removed
    Richard> /etc/exim.conf~,and restarted the machine.

Richard,

I think your local_domains should be "localhost:otte:otte.ucsc.edu"
(though I'm not an exim expert by any means). I'm saying this because
you seem to get mail at this machine addresses as ric@localhost,
ric@otte, and ric@otte.ucsc.edu.


 >> 2002-11-08 08:47:06 18ACHh-0000Gb-00 <= otte@ucsc.edu H=otte (localhost)
 >> [127.0.0.1] P=esmtp S=1214 id=20021108164942.GE262@perelandra
 >> 2002-11-08 08:47:06 18ACHh-0000Gb-00 => ric@otte R=smarthost T=remote_smtp
 >> H=smtp.ucsc.edu [128.114.129.35]
 >> 2002-11-08 08:47:06 18ACHh-0000Gb-00 Completed

This is the key part. Your mail is being delivered to ric@otte, and
I'm guessing this is fetchmail. But "otte" is not a local domain, so
it is being sent to your smart host. My question would be: where
exactly did you ask fetcmail to drop your mail (what is on the line
ending with "is xxx here")? 

 >> 2002-11-08 08:47:16 18ACHs-0000Gi-00 <= otte@ucsc.edu H=cats-mx2.ucsc.edu
 >> (ucsc.edu) [128.114.129.35] P=esmtp S=1628 id=20021108164942.GE262@perelandra
 >> 2002-11-08 08:47:16 18ACHs-0000Gi-00 => ric <ric@otte.ucsc.edu> D=procmail
 >> T=procmail_pipe
 >> 2002-11-08 08:47:16 18ACHs-0000Gi-00 Completed

And now your smart host is sending it back to you directly (no
fetchmail) at ric@otte.ucsc.edu, which exim now recognizes as being
"here" since it matches local_domains. 

    Richard> I then fetched the exact same message from my home
    Richard> machine (which works fine) and noticed the log file deals
    Richard> with the message once:

    Richard> 2002-11-08 09:13:29 18AChF-0000eM-00 Completed 2002-11-08
    Richard> 09:13:29 18AChF-0000eM-01 <= otte@ucsc.edu H=perelandra
    Richard> (localhost) [127.0.0.1] P=esmtp S=1237
    Richard> id=20021108164942.GE262@perelandra 

    Richard> 2002-11-08 09:13:29 18AChF-0000eM-01 => ric
    Richard> <ric@localhost> D=procmail T=procmail_pipe 2002-11-08
    Richard> 09:13:29 18AChF-0000eM-01 Completed

    Richard> This puzzles me, because the exim.conf files are almost
    Richard> identical; the differences are in the localhost names.

Puzzles me too. Perhaps you fetchmailrc script delivers to different
addresses? When you say the differences are in localhost names, can
you precisely point to which entries in exim.conf are different?

    Richard> Furthermore, both of these machines have the same
    Richard> .forward file, which reads: |/usr/bin/procmail -t and
    Richard> .fetchmailrc is the same for both.  

Incidentally, you do not need the .forward file. The way exim is
configured it would process the .procmailrc file anyway. The extra
.forward file probably does nothing here but confuse the issue a
little bit ;-)

    Richard> So I don't know why my home machine gets the message and
    Richard> sends it to ric <ric@localhost> and my office machine
    Richard> sends it to ric@otte.  I can understand why it would have
    Richard> done that with the old exim.conf~ file (with qualify
    Richard> domain=otte), but now that I've removed that, shouldn't
    Richard> it use /etc/exim/exim.conf where it is listed as (qualify
    Richard> domain=otte.ucsc.edu)?

Yes. It really should, unless fetchmail is qualifying the name to
start with.

    Richard> I may have misspoken when I said it worked fine when I
    Richard> took out the procmailrc.  What I noticed was that a
    Richard> couple of messages didn't have the long delay; but that
    Richard> may have been a quirk, and they may still have been
    Richard> processed twice.  I'm going into my office in a while,
    Richard> and I will experiment some more with this.  If anyone has
    Richard> any suggestions on things to try, I'm open.

That was probably because your campus mail exchanger worked really
quickly some of the time, and at other times it took a while.

Good luck. 

/Shyamal



Reply to: