[tor-bugs] #34286 [Applications/GetTor]: gettor appears to be in an email loop war with a .sk address
Tor Bug Tracker & Wiki
blackhole at torproject.org
Fri May 22 20:48:04 UTC 2020
#34286: gettor appears to be in an email loop war with a .sk address
---------------------------------+------------------------------
Reporter: arma | Owner: cohosh
Type: defect | Status: needs_review
Priority: Medium | Milestone:
Component: Applications/GetTor | Version:
Severity: Normal | Resolution:
Keywords: | Actual Points:
Parent ID: | Points:
Reviewer: phw | Sponsor:
---------------------------------+------------------------------
Changes (by cohosh):
* status: assigned => needs_review
* reviewer: => phw
Comment:
Here's a patch: https://gitlab.torproject.org/torproject/anti-censorship
/gettor-project/gettor/-/merge_requests/10
This was a really good catch.
Replying to [ticket:34286 arma]:
> There are probably smart guidelines for avoiding mail loop wars, like
not answering names that start with mailer-domain, checking for the
presence of an X-Something-Something header, or rate limiting responses to
a given address.
I couldn't find any best practices while poking around, so I went with
ignoring all emails from `mailer-daemon@` addresses. It will work for most
cases for now.
We have a rate-limiter in place, but it only ensures that a single user
doesn't request links too many times per minute. These means at least one
of these auto-generation loop emails is still getting in every minute. I
don't want to limit the total requests received from a given email because
it's reasonable to expect someone to want to download Tor multiple times
in their life (see also #33123).
>
> And this is a great case where unifying how bridgedb handles its email
answers, and how gettor does it, will save a lot of headache.
Yeah, from what I can tell it actually looks like bridgedb might handle
this by rate limiting (I'll need to look into it further). We might not
want to handle this in the same way since bridgedb's reasons for rate
limiting (preventing enumeration) are different from gettor's.
But in general I agree that this a case in which it is a pain to
repeatedly solve problems for each system separately.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/34286#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list