Running into a problem where a “bad person” (unprivileged and unknown
by RT) can send an email to the RT system with someone else’s ticket
ID in the subject. RT will recognize the (guessed) ticket ID, and
permanently append the message (which may contain spam or nastiness)
to somebody’s ticket, even though the sender is not a valid party
listed on the ticket.
So some troublemaker can send 1 email with a random ticket ID, or
100,000 emails with all possible ticket ids and attack users’ tickets.
We want to allow people to create tickets by email and we do want RT
users to be automatically created if they don’t already exist. Is
there a way, though, to deny permission for unprivileged users to
"reply" to a ticket unless they are the Requestor or Cc?
but the above permissions do not seem to make any difference in the
ability of strangers being able to pollute random tickets with
messages.
It also seems that if an attacker forged his From address to appear to
come from one of our privileged email addresses (like
support@yourdomain), a permissions-only approach would not really make
much of a barrier.
Should some combination of permissions be able to work, or does
preventing this abuse require a Scrip?
Do any of you with RT installations ever run into situations where
someone mail bombs or attacks your users’ tickets by email in this
way?
Running into a problem where a “bad person” (unprivileged and unknown
by RT) can send an email to the RT system with someone else’s ticket
ID in the subject. RT will recognize the (guessed) ticket ID, and
permanently append the message (which may contain spam or nastiness)
to somebody’s ticket, even though the sender is not a valid party
listed on the ticket.
So some troublemaker can send 1 email with a random ticket ID, or
100,000 emails with all possible ticket ids and attack users’ tickets.
We want to allow people to create tickets by email and we do want RT
users to be automatically created if they don’t already exist. Is
there a way, though, to deny permission for unprivileged users to
“reply” to a ticket unless they are the Requestor or Cc?
but the above permissions do not seem to make any difference in the
ability of strangers being able to pollute random tickets with
messages.
It also seems that if an attacker forged his From address to appear to
come from one of our privileged email addresses (like
support@yourdomain), a permissions-only approach would not really make
much of a barrier.
Should some combination of permissions be able to work, or does
preventing this abuse require a Scrip?
Do any of you with RT installations ever run into situations where
someone mail bombs or attacks your users’ tickets by email in this
way?
What advice can you give?
Allen
Allen,
We run all of our RT E-mail into an anti-spam system with a
quarantine function, before we pass it to RT. The means that
attacks such as the above end up populating the quarantine,
but do not actually pollute the tickets. Emptying the quarantine
is a click away. It works quite well since it is not based on
the guessed header, but the content of the message.
Alternatively, if you could set up a “secured” channel for your
valid E-mail addresses to communicate with RT from your priviledged
servers, that might work as well.