Paul, Why would you want to block an IP before a problem occurs? And how would you know that the IP is going to be problematic before a problem occurs?
We utilize RTIR for our Abuse handling. External sites email us to [email protected], which drops into RTIR's Incident Reports queue. From there, our Abuse Admins verify the issue, then proceed to open an Incident & Investigation(outbound ticket to our customer) simultaneously. If the customer does not correct the problem within ___ amount of time, our Abuse Admins will then open a Block, blocking the customer IP until they fix the issue. It may just be how you are using it that causes you to feel the logic is flawed. As from my example above, it fits perfectly in the logical workflow. Max [email protected] wrote: > Has anyone modified RTIR to allow Blocks to be linked to Incident Reports > instead of Incidents? If so, how? > > I don't like the fact that I have to create an Incident Report and then > an Incident to create a Block. That logic is flawed. It assumes it takes > an actual incident to put a block in place, where as you should want to be > proactive and block prior to an incident. > > Thanks, > Paul J > _______________________________________________ > http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users > > Community help: http://wiki.bestpractical.com > Commercial support: [email protected] > > > Discover RT's hidden secrets with RT Essentials from O'Reilly Media. > Buy a copy at http://rtbook.bestpractical.com > _______________________________________________ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [email protected] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
