Opened 9 months ago

Last modified 8 months ago

#33314 needs_review defect

RT spams TPA with bounces

Reported by: anarcat Owned by: anarcat
Priority: Very High Milestone:
Component: Internal Services/Services Admin Team Version:
Severity: Minor Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by anarcat)

Since I fixed the root aliases everywhere, we seem to be getting spam mail bounced back to the tpa alias, from the root@rude email account.

It seems that this mail was previously being delivered locally to the nobody mailbox, which is now a whopping 630MB:

root@rude:/var/mail# ls -al /var/mail/*
-rw-rw---- 1 amavis        mail      5688 May  4  2016 /var/mail/amavis
-rw-rw---- 1 nobody        mail 660486247 Feb 12 21:46 /var/mail/nobody
-rw-rw---- 1 rtmailarchive mail     28174 Sep  1  2016 /var/mail/rtmailarchive

Since #32283 was deployed, that has stopped growing but instead we're all getting spammed with that junk, which isn't much of an improvement. But at least those problems will have to get fixed.

The first problem is messages in the form:

From: rt@…
Subject: Failed attempt to create a ticket by email, from <email>

<email> attempted to create a ticket via email in the queue help-es; you

might need to grant 'Everyone' the CreateTicket right.

We got 23 such emails since the alias was fixed, and this will probably just keep going forever.

I reported this as a bug in the upstream forum, in:

I also filed this as a bug in Debian:

and filed a patch in:

That latter patch is directly applied on rude right now, with:

wget -O ~anarcat/PR-291-no-err-on-deny.patch
cd /usr/share/request-tracker4
patch -p1 < ~anarcat/PR-291-no-err-on-deny.patch
service apache2 restart

just skip the t/ chunk.

I'll wait and see what feedback I get from upstream and Debian before deciding what to do with this in the long term. Options include:

  1. blocking users at the MTA level - requires TPA operation which we'd like to avoid, we want to train RT admins to be autonomous
  2. patch the bug in Debian and follow that process to get rude updated in the long term
  3. hotfix the Debian package in our archive

we also need to decide what to do about that 600M mail archive... i'll probably just delete it once i'm happy with our solution.

Child Tickets

Change History (6)

comment:1 Changed 9 months ago by anarcat

Description: modified (diff)

comment:2 Changed 9 months ago by anarcat

Description: modified (diff)
Status: assignedneeds_review

patch didn't work: RT runs in mod_perl so we need to restart apache too. amended the instructions and tested if bounces make it back to TPA with this command on rude:

swaks -t -s localhost -f newsletter

so far nothing: TPA doesn't get the bounce! so in the short term that issue seems to have been fixed.

in the mid term, we also need to clear out /var/mail. we might also want to consider purging ~rtarchive/Maildir/ eventually?

comment:3 Changed 9 months ago by anarcat

Keywords: tpa-roadmap-february removed

comment:4 Changed 8 months ago by anarcat

patch was refused upstream, suggesting we replace the "Default" plugin with our own instead, which I don't find very satisfying as a response.

also, got another bounce during the weekend, and removed another MailError. Feels like i'm playing whack-a-mole, but i'll let this one sit a little longer and see if we have fixed it before deciding where to go.

new commit:

...on the no-err-on-deny branch in:

comment:5 Changed 8 months ago by anarcat

sigh. got another one today:

Subject: Ticket creation failed: [SPAM SUBJECT REMOVED]

No permission to create tickets in the queue 'help'

comment:6 Changed 8 months ago by anarcat

applied but it now feels like we're really doing something wrong, as this is a different module and that code has been there since at least 13 years now...

maybe we'll need to find another way to deny users...

Note: See TracTickets for help on using tickets.