Since RT 4.4 (as shipped by Debian 10/buster), I am getting bounces when a blocked user writes to RT.
In previous versions, we would “block” spammy users directly from the web interface, by unchecking the Let this user access RT box in the user Edit form. This was nice: RT admins could block the user from creating tickets without having to go on the commandline or config management to add a block rule in the MTA. The user would get a bounce, and we’d stop getting their junk.
But since 4.4., that behavior has changed, in this commit:
And indeed, this replicates the _NoAuthorizedUserFound functionality which was ripped out in that commit, which, as I understand it, was optional:
But now that behavior is enforced, and there’s no way to disable it. I think that’s a problem: we’re getting tens of bounces like this every night now.
So I would propose we revert that change, and have done so in this PR:
I would be fine with moving this into an (optional) plugin, but as an enforced mechanism, it seems really counter-productive…
Let me know if that should be reported to rt-bugs@bp.com instead!
Not totally sure about this but if you write your own mail plugin can you short circuit the existing MailError message.
use strict;
use warnings;
package RT::Interface::Email::Auth::TestMailPlugin;
use Role::Basic 'with';
with 'RT::Interface::Email::Role';
sub CheckACL {
my %args = (
Action => undef,
Message => undef,
CurrentUser => undef,
Ticket => undef,
Queue => undef,
@_,
);
# Send the reject email if user is disabled
if ( $args{'CurrentUser'}->Disabled ) {
MailError(
Subject => "Permission Denied",
Explanation => "You gave no right to create tickets",
FAILURE => 1
);
}
return 1;
}
1;
one problem i’m seeing is there are multiple places where RT can send such error messages… the latest find i got was an action plugin… but maybe the ACL would kick in before that?
in any case, that’s a great idea, and probably my next step, thanks again