[rt-users] powetmaster undeliverd loop prevention

[Bill Cole]

On 21 Jun 2016, at 8:40, Woody - Wild Thing Safaris wrote:

> Hello,
>
> I recently had an issue where one of the requestor emails was 
> bouncing, and a reply was sent from postmaster back to RT. The reply 
> also contained the subject tag, so caused a correspondence on the 
> ticket, mailing the bouncing requestor again and creating another 
> postmaster mail.
>
> I see there is bulk detection, and
>
> Set($RedistributeAutoGeneratedMessages, "privileged");
>
> But the loop was caused by mails from postmaster at domain.com  which 
> corresponded to requestor unknownuser at domain.com who was unprivileged.
>
> I'm unsure if i have things set up right - ideally any mails from 
> postmaster would never get sent to anyone.

One solution for bounces hitting RT: 
http://www.mailermailer.com/labs/projects/RT-Bounce-Handler.rwp


> secondly
>
> if i disable a user, mails that are rejected cause a mail to 
> OwnerEmail (faied to crete ticket) - i don't want a mail to OwnerEmail 
> as they're basically spam users that are disabled, but i do want 
> OwnerEmail to appear on the login page for support enquiries.
>
> I see i can turn off loop detection mails with
>
> Set($LoopsToRTOwner, 1);
>
> but don't see anything to stop the "fialed to create ticket" emails

It is best to handle that at the MTA rather than in RT. If you have 
widely-exposed addresses feeding into RT which autocreate users & new 
tickets, you really need a robust spam filtering rig protecting RT that 
is configured specifically for RT protection. The strong bias towards 
permanence in RT makes it a nuisance to try to clean up after the spam 
has gotten in; it's easier to just keep it out.

I don't have a spam problem with the RT I currently manage, but 
something I've done on past systems was to have a "Spammers" group in RT 
and periodically extract its members email addresses and use that as a 
bi-directional blacklist on the MTA, in my case as part of a 'make' 
process that rebuilt the Sendmail AccessDB. Once an address is blocked 
at the MTA, you can shred the bogus account and the ticket(s) it created 
in RT. I can't share my code and am not sure that I even still have a 
copy of it, but the concept is pretty easy to implement. If you're using 
Postfix it would be simpler than with Sendmail, since you don't have a 
monolithic BDB AccessDB to rebuild with each change.