Shut down without losing mail?

Is there a clean way to stop RT (to upgrade versions for
example…) without dropping any inbound email? Does
sendmail take some magic return value from a pipe delivery
as a temporary failure and retry later?

Is there a clean way to stop RT (to upgrade versions for

example…) without dropping any inbound email? Does

sendmail take some magic return value from a pipe delivery

as a temporary failure and retry later?

No, not really.

If you are in the middle of an upgrade and RT does not run (the most likely
cause for that seems a misconfiguration to me), rt-mailgate generates an
error and sendmail bounces the email back to the sender, who will hopefully
try again in a few hours.

The cleanest solution I can think of is (untested): point the alias for RT
to a spool file (/var/spool/mail/rt or similar) during the upgrade. After
the upgrade, change the alias back to RT and pipe all mail in the spool file
into rt-mailgate, with the appropriate options.

Regards,

Martin

Is there a clean way to stop RT (to upgrade versions for
example…) without dropping any inbound email? Does
sendmail take some magic return value from a pipe delivery
as a temporary failure and retry later?

Not by default, no. See 3).

  1. Shutdown the mailserver, or just disable incoming mail if
    it’s a mailserver dedicated to RT.

  2. Use MTA-specific magic to defer mails addressed to RT alias
    instead of giving them to RT.

  3. Permanently use MTA-specific magic to defer mails addressed
    to RT alias if giving them to RT results in an error (not
    quite off-the-cuff certain how to do this but pretty sure
    it’s possible with exim, otherwise writing a wrapper should
    be very simple, could be incorporated into procmailrc below)

  4. Never needed previous solutions because I send my incoming RT
    mail through procmail, to handle the REALLY big attachments,
    the most blatant spam, etc. Promail either sends to RT or to
    a spoolfile. Mutt reads the spoolfile, and I have a macro to
    send to RT directly, bypassing procmail.

    That’s nice in itself, so once you have that, it’s just a
    matter of putting a comment in a strategic place in the
    procmailrc, and everything goes to the spoolfile until you
    macro it onwards.

    (OK this is for an old RT install but I don’t see that RT3
    should be different)

HTH, HAND
#include <std_disclaim.h> Lorens Kockum

Well, if you had Postfix, you could issue a temporary code, i.e. 451 based
on recipient…

Postfix makes controlling mail a lot easier. We use separate access files
for client (ip/host/net), sender (from) and recipient (to) fields, which
makes it easier to control. We also filter on helo parameters, but that’s
another chapter…

Still would like to see a combo setup though, where one could say: if from
x, sent to y, block…

Sigh, the dreams…

Regards, Jörn Hass
Senior Systems Engineer, Infrastructure.
Internet Solutions
E-mail: jorn.hass@is.co.za
WWW: http://www.is.co.za

-> -----Original Message-----
-> From: Lorens Kockum [mailto:rt-id-45@lists.lorens.org]
-> Sent: 01 April 2003 13:36 PM
-> To: Les Mikesell
-> Cc: rt-users@lists.fsck.com
-> Subject: Re: [rt-users] shut down without losing mail?
->-> On Mon, Mar 31, 2003 at 11:48:07AM -0600, Les Mikesell wrote:
-> > Is there a clean way to stop RT (to upgrade versions for
-> > example…) without dropping any inbound email? Does
-> > sendmail take some magic return value from a pipe delivery
-> > as a temporary failure and retry later?
->
-> Not by default, no. See 3).
->
-> 1) Shutdown the mailserver, or just disable incoming mail if
-> it’s a mailserver dedicated to RT.
->
-> 2) Use MTA-specific magic to defer mails addressed to RT alias
-> instead of giving them to RT.
->
-> 3) Permanently use MTA-specific magic to defer mails addressed
-> to RT alias if giving them to RT results in an error (not
-> quite off-the-cuff certain how to do this but pretty sure
-> it’s possible with exim, otherwise writing a wrapper should
-> be very simple, could be incorporated into procmailrc below)
->
-> 4) Never needed previous solutions because I send my incoming RT
-> mail through procmail, to handle the REALLY big attachments,
-> the most blatant spam, etc. Promail either sends to RT or to
-> a spoolfile. Mutt reads the spoolfile, and I have a macro to
-> send to RT directly, bypassing procmail.
->
-> That’s nice in itself, so once you have that, it’s just a
-> matter of putting a comment in a strategic place in the
-> procmailrc, and everything goes to the spoolfile until you
-> macro it onwards.
->
-> (OK this is for an old RT install but I don’t see that RT3
-> should be different)
->

"This e-mail may contain confidential information and may be legally
privileged and is intended only for the person to whom it is addressed. If
you are not the intended recipient, you are notified that you may not use,
distribute or copy this document in any manner whatsoever. Kindly also
notify the sender immediately by telephone, and delete the e-mail. When
addressed to clients of the company from where this e-mail originates ("the
sending company “) any opinion or advice contained in this e-mail is subject
to the terms and conditions expressed in any applicable terms of business or
client engagement letter . The sending company does not accept liability for
any damage, loss or expense arising from this e-mail and/or from the
accessing of any files attached to this e-mail.”

As of RT 3.0, RT should exit with “TEMPFAIL” and spool the mail until
the mailgate is happily working again. If this isn’t what it’s doing,
it’s a bug.

-jOn Tue, Apr 01, 2003 at 11:04:27AM +0200, Martin Schapendonk wrote:

Is there a clean way to stop RT (to upgrade versions for

example…) without dropping any inbound email? Does

sendmail take some magic return value from a pipe delivery

as a temporary failure and retry later?

No, not really.

If you are in the middle of an upgrade and RT does not run (the most likely
cause for that seems a misconfiguration to me), rt-mailgate generates an
error and sendmail bounces the email back to the sender, who will hopefully
try again in a few hours.

The cleanest solution I can think of is (untested): point the alias for RT
to a spool file (/var/spool/mail/rt or similar) during the upgrade. After
the upgrade, change the alias back to RT and pipe all mail in the spool file
into rt-mailgate, with the appropriate options.

Regards,

Martin


rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

http://www.bestpractical.com/rt – Trouble Ticketing. Free.

“MS” == Martin Schapendonk martin.schapendonk@whitehorses.nl writes:

MS> If you are in the middle of an upgrade and RT does not run (the most likely
MS> cause for that seems a misconfiguration to me), rt-mailgate generates an
MS> error and sendmail bounces the email back to the sender, who will hopefully
MS> try again in a few hours.

The rt-mailgate should exit with EX_TEMPFAIL in situations where it
cannot contact the DB (or the web server for RT3). Anything else
would be a seriously wrong thing to do.

Your best bet is to convince your mail server to “hold” all
rt-destined mail. This is easy when RT mail addresses are in their
own domain and you use a modern mail server like postfix.

Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: khera@kciLink.com Rockville, MD +1-240-453-8497
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/