Mike,
You’re right that using the EXITCODE hack causes RT to fail to realize
that there has been a successful delivery and continue to search for
a place to deliver the message. This is the behavior I referred to
in my posting.
I think your problem may be with the implementation of my proposed
solution. When I said:
"One solution to this problem is to set DEFAULT to /dev/null, i.e.,
DEFAULT=/dev/null
prior to the execution of the rt-mailgate recipes.",
I meant to do it prior to the entire (set of) recipe(s).
E.g.,
…
DEFAULT=/dev/null
:0
- ^TO rt@my.domain
| $RT_MAILGATE --queue $QUEUE --action $ACTION --url $RT_URL
…
It appears that you may have put DEFAULT assignment inside the RT
recipe itself.
Gary
Mike Friedman wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The issue of multiple copies which Duncan mentions below can lead to
problems when rt-mailgate fails if preventative measures are not taken.
When procmail is configured to set EXITCODE to the rt-mailgate return
code as specified below and rt-mailgate fails, procmail decides that
recipe has failed and continues to try subsequent recipes in the file.
If none succeeds, it will default to the DEFAULT action which, unless
explicitly configured otherwise, is to put the message in the user’s
spool file. After delivering the message to the spool file, procmail
exits and returns the value of EXITCODE to sendmail, causing sendmail
to requeue the message.
If RT is down for some time, a copy of the message is deposited in the
spool file on each retry. If there are many messages, it can add up to
a lot of disk space.
One solution to this problem is to set DEFAULT to /dev/null, i.e.,
DEFAULT=/dev/null
prior to the execution of the rt-mailgate recipes.
Gary,
I’m having a similar problem, but the symptoms are somewhat different
and your suggestion isn’t working (in fact it makes things worse).
First, I followed Duncan’s suggestion and replaced this:
| $RT_MAILGATE --queue $QUEUE --action $ACTION --url $RT_URL
with this:
EXITCODE=| $RT_MAILGATE --queue $QUEUE --action $ACTION --url $RT_URL
; echo $?
What happened then is that all mail successfully delivered to RT
queues also ended up in the default inbox of the user running procmail.
So, I just tried your suggestion. Immediately proceeding the execution
of rt-mailgate, I inserted this line:
DEFAULT=/dev/null
But then a test mail I sent still ended up in the default inbox, but it
didn’t get delivered to RT!
The .forward file for the user running procmail looks like this:
“|IFS=’ ’ && p=/usr/local/bin/procmail && test -f $p && exec $p -Yf-
|| exit 75”
This was recommended in some documentation I saw, though I’m not sure I
understand why I can’t just use this:
“|exec /usr/local/bin/procmail || exit 75”
(although my symptoms are the same with the above as well).
Do you have any ideas about this?
Thanks.
Mike
Mike Friedman IST/System and Network Security
mikef@ack.Berkeley.EDU 2484 Shattuck Avenue
1-510-642-1410 University of California at Berkeley
Socrates and Berkeley Scholars Web Hosting Services Have Been Retired | Web Platform Services http://security.berkeley.edu
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8
iQA/AwUBRRrVqq0bf1iNr4mCEQKJMQCg+1SPsbxLZeUxbFwx/IiiV9DN6I8AoISn
V0yhaZKaKC1MBLjUimgwkHMb
=vUIK
-----END PGP SIGNATURE-----
Gary Hall hall@fas.sfu.ca | Voice (604) 291-5925
Faculty of Applied Sciences | Fax (604) 291-5404
Simon Fraser University |
Burnaby, B.C. V5A 1S6 |
you need