[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #34286 [Applications/GetTor]: gettor appears to be in an email loop war with a .sk address
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs