Hi!
tl;dr: We're thinking about introducing an auto responder to abuse mail which then requires clicking a link or replying to the mail again before the complaint actually reaches a human. What do you think? Can you help us set this up?
So far, we do not have any auto responder for abuse mails. I always thought it was important to be friendly and get back to everyone individually, even if at the core we're reusing mail templates. There is a difference if a human gets back to you within a few hours, or you immediately get clearly a auto-sent something that basically tells you there's not much that can be done.
But actually, most of what we're seeing is automated notification mail, and lately we also see more and more spam that survives the spamassassin. An ideal system would track used addresses, and only send an auto-response from our end once per sender every few months.
We have very limited resources for abuse management, and it would be great to filter out the noise better than we currently do.
Did anyone set up an infrastructure like that before? How would you do it?
Also, if you just want to help with our abuse management, let me know! We can always use one or two more hands, it's fun, and it teaches you a lot about Tor exit operation.
On 13.09.17 15:49, Moritz Bartl wrote:
We're thinking about introducing an auto responder to abuse mail which then requires clicking a link or replying to the mail again before the complaint actually reaches a human. What do you think?
For my exit nodes, I have tested rejecting obviously auto-generated complaints on arrival (SMTP code 5xx), with a customised text stating how a human can get in touch with me via a different, unpublished mail address. No human has yet used this second address, but my method sure saves me time by weeding out most robot-generated complaints.
-Ralph
On 13.09.2017 16:08, Ralph Seichter wrote:
For my exit nodes, I have tested rejecting obviously auto-generated complaints on arrival (SMTP code 5xx), with a customised text stating how a human can get in touch with me via a different, unpublished mail address.
Cool. Mind sharing that configuration, and maybe even the filters you already set up?
On 13.09.17 18:48, Moritz Bartl wrote:
Mind sharing that configuration, and maybe even the filters you already set up?
My method is highly Postfix-specific, but I can see that you use Postfix as well. ;-) Here is an example for sender-based rejection (incomplete):
smtpd_sender_restrictions = check_sender_access pcre:${config_directory}/sender_access
# pcre:sender_access /abuse-reporting.webiron.com/ REJECT
That line alone catches most of the useless generated complaints. W.I. holds a special place in my heart due to past misbehaviour, so I don't even bother telling them how to contact me any more and flatly reject all their robot messages.
Combine this with recipient-based checks (incomplete again):
smtpd_recipient_restrictions = check_recipient_access pcre:${config_directory}/recipient_access
# pcre:recipient_access /^abuse@tordom.tld$/ REJECT Please use https://foo/ to report abuse
I imagine you already have a (captcha-protected) ticket system in place. Finally, sprinkle header- and/or body-based checks into the mix:
header_checks = pcre:${config_directory}/header_checks
# pcre:header_checks /^Subject:.+fail2ban generated abuse report/ DISCARD
Not that I actually recommend using DISCARD, mind you, it is just another example. Should you require more specific information about what Postfix checks can do, contact me off-list. I'm guessing you know about these very powerful checks already.
-Ralph
Hello Moritz,
we run such an setting since several years.
Whois records show our ripe object with abuse-ripe@...as abuse-mailbox address. This is connected to an auto-responder.
In auto-responder mail we explain what is going on and offer to write to our abuse@.... email address. This really is then distributed to the abuse team for response.
There is not much coming in this way. Some people directly go for our website our write to our office address.
Recently we received a lot of automatic fail2ban messages due to ssh abuse. The downside here is they also wrote to our provider.
But this seems to be the setting of fail2ban which checks also the network abuse record.
best regards
Dirk
On 13.09.2017 15:49, Moritz Bartl wrote:
Hi!
tl;dr: We're thinking about introducing an auto responder to abuse mail which then requires clicking a link or replying to the mail again before the complaint actually reaches a human. What do you think? Can you help us set this up?
So far, we do not have any auto responder for abuse mails. I always thought it was important to be friendly and get back to everyone individually, even if at the core we're reusing mail templates. There is a difference if a human gets back to you within a few hours, or you immediately get clearly a auto-sent something that basically tells you there's not much that can be done.
But actually, most of what we're seeing is automated notification mail, and lately we also see more and more spam that survives the spamassassin. An ideal system would track used addresses, and only send an auto-response from our end once per sender every few months.
We have very limited resources for abuse management, and it would be great to filter out the noise better than we currently do.
Did anyone set up an infrastructure like that before? How would you do it?
Also, if you just want to help with our abuse management, let me know! We can always use one or two more hands, it's fun, and it teaches you a lot about Tor exit operation.
tor-relays@lists.torproject.org