No permission notify

Is there any way to not notify the sender when they don’t have permission? I don’t mind the root@ notification but spammers just hammer all our queues and the closed ones don’t have a spam filter on it … so it causes tons of backscatter (spoofed sender returns spam). All our public queues are controlled mostly through web forms and other apps, so there’s no reason to notify anyone about permissions in these cases for us. If there’s any reason why this would be a bad idea I wouldn’t mind hearing too.

/RT could not load a valid user, and RT’s configuration does not allow
for the creation of a new user for this email (spam@backscattervictim.com).

You might need to grant ‘Everyone’ the right ‘CreateTicket’ for the
queue queue::blah.

/Thanks
Curtis

Curtis,

Try removing those permissions from EVERYONE and UNPRIVILEGED to 

PRIVILEGED only. Hope this helps.

Kenn
LBNLOn 8/20/2008 10:48 AM, Curtis Bruneau wrote:

Is there any way to not notify the sender when they don’t have permission? I don’t mind the root@ notification but spammers just hammer all our queues and the closed ones don’t have a spam filter on it … so it causes tons of backscatter (spoofed sender returns spam). All our public queues are controlled mostly through web forms and other apps, so there’s no reason to notify anyone about permissions in these cases for us. If there’s any reason why this would be a bad idea I wouldn’t mind hearing too.


/RT could not load a valid user, and RT’s configuration does not allow
for the creation of a new user for this email (spam@backscattervictim.com).

You might need to grant ‘Everyone’ the right ‘CreateTicket’ for the
queue queue::blah.

/Thanks
Curtis


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

That’s how my private queues are set up, but that doesn’t prevent
spammers from trying every possible email address on my server, when
they do find a private one they get this return email. Perhaps I
misunderstood … is there a spot to change that behavior for everyone
and unprivileged?

Curtis

Kenneth Crocker wrote:

Curtis,

We don't get spam so my answer won't work for you. We have set up our 

RT so that no spam gets in. That way, RT can automatically create (&
grant ‘privileged’ to) users that pass authentication and all email
users get automatically created as ‘unprivileged’ users. That’s what we
do and it works fine.

Kenn
LBNLOn 8/21/2008 7:04 AM, Curtis Bruneau wrote:

That’s how my private queues are set up, but that doesn’t prevent
spammers from trying every possible email address on my server, when
they do find a private one they get this return email. Perhaps I
misunderstood … is there a spot to change that behavior for everyone
and unprivileged?

Curtis

Kenneth Crocker wrote:

Curtis,

Try removing those permissions from EVERYONE and UNPRIVILEGED to 

PRIVILEGED only. Hope this helps.

Kenn
LBNL

On 8/20/2008 10:48 AM, Curtis Bruneau wrote:

Is there any way to not notify the sender when they don’t have
permission? I don’t mind the root@ notification but spammers just
hammer all our queues and the closed ones don’t have a spam filter on
it … so it causes tons of backscatter (spoofed sender returns spam).
All our public queues are controlled mostly through web forms and
other apps, so there’s no reason to notify anyone about permissions
in these cases for us. If there’s any reason why this would be a bad
idea I wouldn’t mind hearing too.


/RT could not load a valid user, and RT’s configuration does not allow
for the creation of a new user for this email
(spam@backscattervictim.com).

You might need to grant ‘Everyone’ the right ‘CreateTicket’ for the
queue queue::blah.

/Thanks
Curtis


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Yeah I’m talking about backscatter, when someone sends spam as a spoofed
user and the smtp server bounces that spam back to the spoofed address,
effectively relaying spam for them. Postfix does recipient lists so the
majority won’t bounce for email addresses not in my /etc/aliases, I have
procmail and spamassassin on the entry of my public queue/emails so spam
is not getting in, but it will bounce back (the RT response) when
there’s no permission on a private queue. It’s not a major problem I was
just curious if those no permission replies can be disabled. Or at least
don’t attach the original message to the response.

Curtis.

Kenneth Crocker wrote:

Yeah I’m talking about backscatter, when someone sends spam as a spoofed
user and the smtp server bounces that spam back to the spoofed address,
effectively relaying spam for them. Postfix does recipient lists so the
majority won’t bounce for email addresses not in my /etc/aliases, I have
procmail and spamassassin on the entry of my public queue/emails so spam
is not getting in, but it will bounce back (the RT response) when
there’s no permission on a private queue. It’s not a major problem I was
just curious if those no permission replies can be disabled. Or at least
don’t attach the original message to the response.

Curtis.

Kenneth Crocker wrote: