Re: [tor-relays] Fwd: 2017-06-07 15:37: 65 new tor exits in 30 minutes

[grarpamp]

On Thu, Jun 8, 2017 at 12:15 AM, Arisbe  wrote:

Content-Type: text/html :(

> Seems like none of us have the time to research these events or those before. 
>  If people can't play by written and unwritten rules regarding Tor contact 
> info, family members, etc. and they 'could' be a danger to anonymity, why 
> does Tor bother with them?  If people are sincere about helping the Tor 
> network, they will express that in their offers--otherwise, as in this 
> situation, they should be removed until sufficient information is provided.

Both anonymity and nymity provide strengths and weakness to networks.
Certainly everyone can imagine some.

In that understanding, finding / creating "good" relays is as useful as
hunting for "bad" relays.

As before, if some set of rules and metrics might be felt important
to you or others in choosing relays to use, why not start a project to collate
and publish lists of relays based on that, then users can subscribe it.

Thanks to the appreciated efforts of those volunteering their time and
research to find things, these relays are up for a fat k-line real soon now :)
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] 2017-06-07 15:37: 65 new tor exits in 30 minutes

[Roger Dingledine]

On Wed, Jun 07, 2017 at 03:50:54PM -0400, David Goulet wrote:
> On 07 Jun (19:41:00), nusenu wrote:
> > DocTor [1] made me look into this.
> > 
> > _All_ 65 relays in the following table have the following characteristics:
> > (not shown in the table to safe some space)
> 
> Yah, we got a report on bad-relays@ as well... We are looking into this but
> seems there is a distinctive pattern for most of them.

Update: we set things in motion this afternoon to cut the relays out of
the network. Also, we have a plausible guess about where they came from,
and we contacted the company that we think controls the IP addresses, so
they can figure it out / clean up as needed.

Thanks!
--Roger

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Mail delivery failed : returning message to sender

[6465ec09]

This message was created automatically by mail delivery software at Junk Email 
Filter. 

The message from "lists.torproject.org [Masked]" 

 is being returned by server opayq-outbound.junkemailfilter.com on Wed, 07 Jun 
2017 21:17:32 -0700

A message that you sent could not be delivered to all of its recipients.

NOTE: And this is important - Junk Email Filter is a front end spam filtering 
service. We accept email for our customers, filter it, and pass the good email 
on. Sometimes when we forward email as good the server we forward to rejects 
it. Generally if you are getting this message it is because the server we 
forwarded to  * NOT JUNK EMAIL FILTER * has rejected the message.

If you see below the phrase "error from remote mail server" then it is the 
server who we are forwarding to, NOT US who is rejecting the email. Read the 
reason carefully and see if you can correct the cause of the rejection.

The following address(es) failed:

  m.terli...@gmx.de
host mx01.emig.gmx.net [212.227.17.5]
SMTP error from remote mail server after HELO 
opayq-out-00.junkemailfilter.com
opayq-outbound.ctyme.com: 500 Syntax error, command unrecognized
Reporting-MTA: dns; opayq-outbound.junkemailfilter.com

Action: failed
Final-Recipient: rfc822;m.terlinde@gmx.de
Status: 5.0.0
Remote-MTA: dns; mx01.emig.gmx.net
Diagnostic-Code: smtp; 500 Syntax error, command unrecognized
Return-path: 
Received: from smtp4.opayq.com ([23.21.143.60]:3804) helo=[23.21.143.60]
	by opayq-outbound.junkemailfilter.com with esmtps (TLSv1.2:AES256-SHA256:256)
	(Exim 4.89)
	id 1dIot1-00032k-3j on interface=184.105.182.150
	for m.terli...@gmx.de; Wed, 07 Jun 2017 21:17:31 -0700
DKIM-Signature: v=1; d=opayq.com; t=1496895450; b=FYwmhRpVCw4Q7Q9PlWYsP8amnJ8q568GYc+cF5uNS2z9OGu7w1nyrrd5YSnuiskxYZlRFoMYzjQpgKzyQ0plVIz21gN1PRx4aYLzZLN5Luv8dSG6GR1D6ncN0QC1jnHqErDkjmkhtcbpfxvz1x0jUw2LwiiIgE5iSekVM/C/Idk=; s=abine; c=relaxed/relaxed; a=rsa-sha256; bh=oKr4q2gTA0h1IHKrS6+15jBfGmjsMslDVdIe5t9IjTw=; h=Date:From:Reply-To:Subject:To:List-Unsubscribe;
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-GetAbine-Processed: 1
From: "lists.torproject.org [Masked]" 
Sender: "lists.torproject.org [Masked]" 
Reply-To: 
	FWD-737QLY3MGNAYQYGGAHICDII6EY4CAKZCFW6DEJZFHAADYYFABL5ABZTBS4AFSQCOACGAA6IMFJSMAAZAJZAAAIA=@opayq.com
To: 6465e...@opayq.com
X-GetAbine-Sender: tor-relays-boun...@lists.torproject.org
X-GetAbine-Disposable: 6465e...@opayq.com
X-GetAbine-Host-Address: 23.21.143.60
Subject: =?utf-8?q?tor-relays_Digest=2C_Vol_77=2C_Issue_8?=
Date: Thu, 08 Jun 2017 04:15:46 +
Message-ID: 
X-BeenThere: tor-relays@lists.torproject.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: "support and questions about running Tor relays \(exit, non-exit,
 bridge\)" 
List-Unsubscribe: , 
 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
 
X-Sender-Domain: torproject.org
X-Spamfilter-host: plato.junkemailfilter.com - http://www.junkemailfilter.com
X-Key-ID: NjQ2NWVjMDlAb3BheXEuY29tIHRvci1yZWxheXMtYm91bmNlc0BsaXN0cy50b3Jwcm9qZWN0Lm9yZyAyMDE3LTA2LTA3IDIxOjE3OjI2IDFkSW9zdy0wMDAyMHMtQVI=
X-Content-flags: news 
X-Domain-list: torproject.org your-server.de opayq.com
X-Mail-from: tor-relays-boun...@lists.torproject.org
X-Spam-Class: HAM-VERY-WHITELIST - white - Sender Host Domain [eugeni.torproject.org] is WHITE listed whitelist hostkarma.junkemailfilter.com - X=plato H=eugeni.torproject.org [138.201.14.202]:34127 HELO=[eugeni.torproject.org] SN=[tor-relays-boun...@lists.torproject.org] T=[6465e...@opayq.com] FR=[tor-relays-requ...@lists.torproject.org] S=[tor-relays Digest, Vol 77, Issue 8]
X-Spam-Class: HAM-VERY-WHITELIST - white - Sender Host Domain [eugeni.torproject.org] is WHITE listed whitelist hostkarma.junkemailfilter.com - X=plato H=eugeni.torproject.org [138.201.14.202]:34127 HELO=[eugeni.torproject.org] SN=[tor-relays-boun...@lists.torproject.org] T=[6465e...@opayq.com] FR=[tor-relays-requ...@lists.torproject.org] S=[tor-relays Digest, Vol 77, Issue 8] - X=plato H=eugeni.torproject.org [138.201.14.202]:34127 HELO=[eugeni.torproject.org] SN=[tor-relays-boun...@lists.torproject.org] T=[6465e...@opayq.com] FR=[tor-relays-requ...@lists.torproject.org] S=[tor-relays Digest, Vol 77, Issue 8]
X-Sender-Host-Address: 138.201.14.202
X-Sender-Host-Name: eugeni.torproject.org
X-Key-ID: bS50ZXJsaW5kZUBnbXguZGUgZndkLTczN3FseTNtZ25heXF5Z2dhaGljZGlpNmV5NGNha3pjZnc2ZGVqemZoYWFkeXlmYWJsNWFienRiczRhZnNxY29hY2dhYTZpbWZqc21hYXphanphYWFpYT1Ab3BheXEuY29tIDIwMTctMDYtMDcgMjE6MTc6MzEgMWRJb3QxLTAwMDMyay0zag==
X-Exim-DSN-Information: Due to administrative limits only headers are return

[tor-relays] Fwd: 2017-06-07 15:37: 65 new tor exits in 30 minutes

[Arisbe]

  
  
To All, 

Seems like none of us have the time to research these events or
  those before.  If people can't play by written and unwritten rules
  regarding Tor contact info, family members, etc. and they 'could'
  be a danger to anonymity, why does Tor bother with them?  If
  people are sincere about helping the Tor network, they will
  express that in their offers--otherwise, as in this situation,
  they should be removed until sufficient information is provided.
Arisbe


  
   Forwarded Message 
  

  
Subject:

[tor-relays] 2017-06-07 15:37: 65 new tor exits in 30
  minutes
  
  
Date: 
Wed, 07 Jun 2017 19:41:00 +
  
  
From: 
nusenu 
  
  
Reply-To:

tor-relays@lists.torproject.org
  
  
To: 
tor-relays@lists.torproject.org
  

  
  
  
  DocTor [1] made me look into this.



_All_ 65 relays in the following table have the following characteristics:
(not shown in the table to safe some space)

- OS: Linux
- run two instances per IP address (the number of relays is only odd
because in one case they created 3 keys per IP)
- ORPort: random
- DirPort: disabled
- Tor Version: 0.2.9.10
- ContactInfo: None
- MyFamily: None
- Joined the Tor network between 2017-06-07 15:37:32 and 2017-06-07
16:08:54 (UTC)
- Exit Policy summary: {u'reject': [u'25', u'119', u'135-139', u'445',
u'563', u'1214', u'4661-4666', u'6346-6429', u'6699', u'6881-6999']}
- table is sorted by colmns 3,1,2 (in that order)


- Group diversity:
 - 20 distinct autonomous systems
 - 18 distinct countries

https://gist.githubusercontent.com/nusenu/81337aed747ea5c7dec57899b0e27e94/raw/c7e0c4538e4f424b4cc529f3c2b1cabf6a5df579/2017-06-07_tor_network_65_relays_group.txt



Relay fingerprints are at the bottom of this file.

This list of relays is NOT identical to the one from DocTor (even though
the number is identical (65)):
[1]
https://lists.torproject.org/pipermail/tor-consensus-health/2017-June/007968.html

https://twitter.com/nusenu_/status/872536564647198720


-- 
https://mastodon.social/@nusenu
https://twitter.com/nusenu_




  



signature.asc
Description: PGP signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] libzstd and/or liblzma

[Felix]

>> Can somebody please help me understand the change log for
>> 3.1.x: "Support for these algorithms requires that tor is
>> built with the libzstd and/or
>> liblzma libraries available." Is it AND or OR or something whatever
>> different ?
>
>
> Hi!  Let me try to clear it up:
>
> If Tor is built with liblzma available, it will use liblzma when
> appropriate.  The lzma format is expensive to calculate, but it
> provides very good compression, so we only use it for cases when we
> can compress something once and server it many many times -- like
> consensus documents, or consensus diffs.
>
> If Tor is built with libzstd available, it will use libzstd when
> appropriate. The zstd format is cheap to calculate, but appears to
> provide better compression than zlib on our data.
>
> If Tor is built with both libraries available, it will use either one
> when appropriate.
>
> Of course, we can only use these compression formats when both sides
> support them.

Thanks. Clear to me. So 'Liblzma N/A' should not be an issue.

--
Cheers Felix
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] libzstd and/or liblzma

[Felix]

Hi nusenu

thanks again for your responses !

> the context of that line is longer in the original changelog:
> 
https://gitweb.torproject.org/tor.git/tree/ChangeLog?id=tor-0.3.1.2-alpha#n43


That's where I got it from

>> Might ports archivers/zstd only do the job (OR-type):
>>
>> Tor 0.3.1.2-alpha (git-61625b8f26384a4a) running on
>> FreeBSD with Libevent 2.1.8-stable, OpenSSL LibreSSL 2.5.3,
>> Zlib 1.2.8, Liblzma N/A, and Libzstd 1.2.0
>
> see the related comment by the FreeBSD port maintainer:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219571#c2

Good hint. When I follow the link I find the archivers/zstd port will be 
included which seems up to date (libzstd.so.1.2.0, 30 Jul 2016). That's 
what I did. Fine.


Which is the right port for lzma ? When I try to include 
archivers/lzmalib (liblzma.so.1.1.0, 23 Sep 2008) I find it 
un-maintained, old and Tor does not configure for it:


checking for LZMA... no
configure: WARNING: Unable to find liblzma.
checking for ZSTD... yes

Is there a better lzma port ?

--
Cheers, Felix
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] 2017-06-07 15:37: 65 new tor exits in 30 minutes

[David Goulet]

On 07 Jun (19:41:00), nusenu wrote:
> DocTor [1] made me look into this.
> 
> _All_ 65 relays in the following table have the following characteristics:
> (not shown in the table to safe some space)

Yah, we got a report on bad-relays@ as well... We are looking into this but
seems there is a distinctive pattern for most of them.

David

> 
> - OS: Linux
> - run two instances per IP address (the number of relays is only odd
> because in one case they created 3 keys per IP)
> - ORPort: random
> - DirPort: disabled
> - Tor Version: 0.2.9.10
> - ContactInfo: None
> - MyFamily: None
> - Joined the Tor network between 2017-06-07 15:37:32 and 2017-06-07
> 16:08:54 (UTC)
> - Exit Policy summary: {u'reject': [u'25', u'119', u'135-139', u'445',
> u'563', u'1214', u'4661-4666', u'6346-6429', u'6699', u'6881-6999']}
> - table is sorted by colmns 3,1,2 (in that order)
> 
> 
> - Group diversity:
>  - 20 distinct autonomous systems
>  - 18 distinct countries
> 
> https://gist.githubusercontent.com/nusenu/81337aed747ea5c7dec57899b0e27e94/raw/c7e0c4538e4f424b4cc529f3c2b1cabf6a5df579/2017-06-07_tor_network_65_relays_group.txt
> 
> 
> 
> Relay fingerprints are at the bottom of this file.
> 
> This list of relays is NOT identical to the one from DocTor (even though
> the number is identical (65)):
> [1]
> https://lists.torproject.org/pipermail/tor-consensus-health/2017-June/007968.html
> 
> https://twitter.com/nusenu_/status/872536564647198720
> 
> 
> -- 
> https://mastodon.social/@nusenu
> https://twitter.com/nusenu_
> 




> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


-- 
F3vakg18tijjqFR690AknN2mb+hDT7jRDxYnpDPmVjY=


signature.asc
Description: PGP signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] 2017-06-07 15:37: 65 new tor exits in 30 minutes

[nusenu]

DocTor [1] made me look into this.



_All_ 65 relays in the following table have the following characteristics:
(not shown in the table to safe some space)

- OS: Linux
- run two instances per IP address (the number of relays is only odd
because in one case they created 3 keys per IP)
- ORPort: random
- DirPort: disabled
- Tor Version: 0.2.9.10
- ContactInfo: None
- MyFamily: None
- Joined the Tor network between 2017-06-07 15:37:32 and 2017-06-07
16:08:54 (UTC)
- Exit Policy summary: {u'reject': [u'25', u'119', u'135-139', u'445',
u'563', u'1214', u'4661-4666', u'6346-6429', u'6699', u'6881-6999']}
- table is sorted by colmns 3,1,2 (in that order)


- Group diversity:
 - 20 distinct autonomous systems
 - 18 distinct countries

https://gist.githubusercontent.com/nusenu/81337aed747ea5c7dec57899b0e27e94/raw/c7e0c4538e4f424b4cc529f3c2b1cabf6a5df579/2017-06-07_tor_network_65_relays_group.txt



Relay fingerprints are at the bottom of this file.

This list of relays is NOT identical to the one from DocTor (even though
the number is identical (65)):
[1]
https://lists.torproject.org/pipermail/tor-consensus-health/2017-June/007968.html

https://twitter.com/nusenu_/status/872536564647198720


-- 
https://mastodon.social/@nusenu
https://twitter.com/nusenu_



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] libzstd and/or liblzma

[Nick Mathewson]

On Tue, Jun 6, 2017 at 8:08 PM, Felix  wrote:
> Hi everybody
>
> Can somebody please help me understand the change log for 3.1.x: "Support
> for these algorithms requires that tor is built with the libzstd and/or
> liblzma libraries available." Is it AND or OR or something whatever
> different ?


Hi!  Let me try to clear it up:

If Tor is built with liblzma available, it will use liblzma when
appropriate.  The lzma format is expensive to calculate, but it
provides very good compression, so we only use it for cases when we
can compress something once and server it many many times -- like
consensus documents, or consensus diffs.

If Tor is built with libzstd available, it will use libzstd when
appropriate. The zstd format is cheap to calculate, but appears to
provide better compression than zlib on our data.

If Tor is built with both libraries available, it will use either one
when appropriate.

Of course, we can only use these compression formats when both sides
support them.

best,
--
Nick
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays