Protecting RT

Lo RT-Likes,

Instance: RT2.

Imagine a case where some moron sends an e-mail to one of RT queues with a
non-existent address (local_part) on a valid domain name.

Today I had a situation where RT ended up creating hundreds of tickets in
a similar case.

One moron sent an e-mail from postmaster@domain.name. This postmaster
account/alias is not defined on their server. RT got the e-mail and
promptly used the AutoReply feature in the relevant queue. The message
hit the original submiter’s server and the server responded with a
“Mail Delivery Failure” to RT, which created a second ticket and so on…
and so forth. This was NOT a mail loop, AFAIK.

So RT was acting correctly, creating new tickets as it’s supposed to,
but this turns to be such a nasty experience. Hundreds of useless tickets.

If there was a way RT could look at the message body and extract a ticket
number, it would be a nice feature, since that way it could relate it
to an existing ticket and just add the new mail as a correspondence.

I checked etc/config.pm but could not see anything like this.

Would appreciate any pointers.

    cheers
   - wash 

Odhiambo Washington, wash@wananchi.com . WANANCHI ONLINE LTD (Nairobi, KE) |
http://ns2.wananchi.com/~wash/ . 1ere Etage, Loita Hse, Loita St., |
GSM: (+254) 722 743 223 . # 10286, 00100 NAIROBI |
“Oh My God! They killed init! You Bastards!”
–from a /. post

This message was transferred with a trial version of CommuniGate™ Pro
An X-loop-detect SMTP header should probably be inserted also. Somce
MTAs don’t include the body of the message with a bounce.

SteveN

ODHIAMBO Washington wrote:

hit the original submiter’s server and the server responded with a
“Mail Delivery Failure” to RT, which created a second ticket and so on…
and so forth. This was NOT a mail loop, AFAIK.

So RT was acting correctly, creating new tickets as it’s supposed to,
but this turns to be such a nasty experience. Hundreds of useless tickets.

It appears RT3 handles these gracefully. Instead of creating a ticket, I
(as the administrator of RT) receive an e-mail from RT stating something
like “RT believes the following message is a bounce”…

“b” == bill bill@daze.net writes:

b> It appears RT3 handles these gracefully. Instead of creating a ticket, I
b> (as the administrator of RT) receive an e-mail from RT stating something
b> like “RT believes the following message is a bounce”…

Happens with rt 2.0.15 as well. However, if the remote system’s
response doesn’t match RT’s idea of a bounce, you’re hosed. There was
a bug in versions prior to this (and some Perl modules as well) that
made the bounce detection reliably FAIL. So make sure you’re modules
and software are up to date!

“b” == bill bill@daze.net writes:

b> It appears RT3 handles these gracefully. Instead of creating a ticket, I
b> (as the administrator of RT) receive an e-mail from RT stating something
b> like “RT believes the following message is a bounce”…

Happens with rt 2.0.15 as well. However, if the remote system’s
response doesn’t match RT’s idea of a bounce, you’re hosed. There was
a bug in versions prior to this (and some Perl modules as well) that
made the bounce detection reliably FAIL. So make sure you’re modules
and software are up to date!

Actually, at some point I used to get mails saying “RT believes the following
message is a bounce…”
I haven’t changed my RT much except add some contrib scrips.

The remote system here is M$ Exchange. I don’t know is that would explain anything
but I’d still appreciate some pinpointing on what to check exactly.

    cheers
   - wash 

Odhiambo Washington, wash@wananchi.com . WANANCHI ONLINE LTD (Nairobi, KE) |
http://ns2.wananchi.com/~wash/ . 1ere Etage, Loita Hse, Loita St., |
GSM: (+254) 722 743 223 . # 10286, 00100 NAIROBI |
“Oh My God! They killed init! You Bastards!”
–from a /. post

Actually, at some point I used to get mails saying “RT believes the following
message is a bounce…”
I haven’t changed my RT much except add some contrib scrips.

The remote system here is M$ Exchange. I don’t know is that would explain anything
but I’d still appreciate some pinpointing on what to check exactly.

The three functions - CheckForLoops, CheckForSuspiciousSender and
CheckForAutoGenerated in Interface/Email.pm perform these checks
in RT 2.0.15. From what I figure from the code, they check for
X-RT-Loop-Prevention, postmaster/mailer-daemon address, and Precedence:
bulk/junk respectively in the headers.

Your bounces trigger loop checks.

Personally, RT behind spamassassin is all the check I have needed so far -
with MICROSOFT_EXECUTABLE bumped up.

Binand

ODHIAMBO Washington wrote:

One moron sent an e-mail from postmaster@domain.name. This postmaster
account/alias is not defined on their server. RT got the e-mail and
promptly used the AutoReply feature in the relevant queue. The message
hit the original submiter’s server and the server responded with a
“Mail Delivery Failure” to RT, which created a second ticket and so on…
and so forth. This was NOT a mail loop, AFAIK.

Yes, this happens when the remote system:

  • does not honour “Precedence: bulk” headers
  • does not generate “Precedence: bulk” headers
  • does not preserve the subject header
  • does not preserve any other headers that RT adds in the reply

which makes it programatically impossible to determine that the
message received is in reply to something we sent.

Bruce Campbell wrote an excellent pair of scrips, UpdateSquelch
and AutoReplySquelch, that you can find in the contrib area.
They do a damn good job of limiting the damage that such broken
systems can cause, by keeping count of the number of messages
received from an address and disabling the autoreply when a
configurable threshhold is reached.
�|� Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.

Also the pacthes I wriote for RT would catch this and also insert the
bounce message into the appropriate ticket. (providing the system is
bouncing to the envelope sender).

THe patches I did are for RT3 and should be somewhere in the
archives…of course the patches could give you other problems.

StewartOn Mon, 14 Apr 2003, Phil Homewood wrote:

Date: Mon, 14 Apr 2003 09:28:42 +1000
From: Phil Homewood pdh@bestpractical.com
To: rt-users@lists.fsck.com
Cc: ODHIAMBO Washington wash@wananchi.biz
Subject: Re: [rt-users] Protecting RT

ODHIAMBO Washington wrote:

One moron sent an e-mail from postmaster@domain.name. This postmaster
account/alias is not defined on their server. RT got the e-mail and
promptly used the AutoReply feature in the relevant queue. The message
hit the original submiter’s server and the server responded with a
“Mail Delivery Failure” to RT, which created a second ticket and so on…
and so forth. This was NOT a mail loop, AFAIK.

Yes, this happens when the remote system:

  • does not honour “Precedence: bulk” headers
  • does not generate “Precedence: bulk” headers
  • does not preserve the subject header
  • does not preserve any other headers that RT adds in the reply

which makes it programatically impossible to determine that the
message received is in reply to something we sent.

Bruce Campbell wrote an excellent pair of scrips, UpdateSquelch
and AutoReplySquelch, that you can find in the contrib area.
They do a damn good job of limiting the damage that such broken
systems can cause, by keeping count of the number of messages
received from an address and disabling the autoreply when a
configurable threshhold is reached.