Opened 7 years ago

Closed 4 years ago

#11084 closed enhancement (wontfix)

Define criteria for sending out welcome mails using Onionoo's details documents

Reported by: karsten Owned by: karsten
Priority: Medium Milestone:
Component: Metrics/Tor Weather Version:
Severity: Keywords: weather-rewrite
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


The current Weather sends out welcome mails to operators of new relays. From the design document:

The database backing Tor Weather stores information about every router seen in consensus within the past year (or for as long as Tor Weather has been running, whichever is shorter). If a router in the database is flagged as stable, its operator has not been sent a welcome email, and its operator is not subscribed to Tor Weather, the router operator's email is parsed from the contact field in the descriptor file for that node. A welcome email containing information about Tor Weather is sent to these node operators if an email address was successfully parsed.

The welcome email thanks the operator for his/her contribution and encourages the operator to subscribe to Tor Weather. If the router allows exits to port 80, information is appended to the email containing links to legal help for exit relay operators.

The welcome emails are not a subscribable notification type and are sent to all new, stable relay operators who a) haven't subscribed to Tor Weather and b) provide a parsable (by our standards) email address in the contact field of their configuration file.

The welcome email is intended for new stable relay operators. To avoid sending the welcome email to long-term relay operators at startup, a 48-hour delay period has been implemented immediately following deployment. Any relays added to the database within the first 48-hours following deployment are exempt from the welcome email. That way, the operators who are emailed should largely be new to the network, and relay operators who have been running for a while shouldn't get the welcome email.

I think we can implement this with Onionoo's current details documents:

  • Only consider relays with first_seen > our_deployment_time to exclude relays that were already around before Weather was (re-)deployed.
  • Only consider relays with Stable in flags to exclude (currently) non-stable relays.
  • Attempt to parse the email address from contact.
  • Only send out a new welcome mail if we didn't send one before. Remember that we sent a welcome mail now.
  • Delete all entries from the database with a timestamp more than 6 months ago.
  • In fact, remember that cutoff time and only consider relays with first_seen > max(our_deployment_time, cutoff_time).

So, I guess what I want to say is that we probably don't need a special field in Onionoo that says when the relay first obtained the Stable flag. Unless we need it?

Let's keep this ticket open until we have good criteria and maybe even until we have implement them in a welcome-mail-sending script.

Child Tickets

Change History (2)

comment:1 Changed 6 years ago by sreenatha

Status: newneeds_review

I've used the django-API to interact with the database models which is supposedly better as pointed out by karsten. Picked up the deployment-time value from DeployedDatetime model and known relays from Router model. Utilized onionoo's 'flag' parameter for selecting stable relays instead of our utility method is_stable.

comment:2 Changed 4 years ago by karsten

Resolution: wontfix
Status: needs_reviewclosed

Tor Weather has been discontinued as of May 24, 2016: Batch-closing all remaining tickets as announced in #19382. A list of these tickets and any other Weather tickets modified after June 26, 2016 will be available here:^Metrics%2FTor+Weather

Note: See TracTickets for help on using tickets.