-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Saturday 22 November 2014 at 9:47:09 PM, in
, MFPA wrote:
> I don't know how Thunderbird+Enigmail handles this.
Having asked the question on PGPNET, I am told that
Thunderbird+Enigmail warns that users of some PGP Corp. products won't
be a
>> Cc: "michaelquig...@theway.org"
>> Date: 11/22/2014 04:16 PM
>> Subject: Re: Encryption on Mailing lists sensless?
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>>
>> Hi
>>
>>
>> On Wednesday 19 November 2014 at
MFPA <2014-667rhzu3dc-lists-gro...@riseup.net> wrote on 11/22/2014
04:16:38 PM:
> From: MFPA <2014-667rhzu3dc-lists-gro...@riseup.net>
> To: "michaelquig...@theway.org on GnuPG-Users"
> Cc: "michaelquig...@theway.org"
> Date: 11/22/2014 04:16 P
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Thursday 20 November 2014 at 9:54:50 PM, in
, Ingo Klöcker
wrote:
> KMail encrypts an individual copy for each BCC
> recipient. I thought Thunderbird+Enigmail would also
> do this.
I don't know how Thunderbird+Enigmail handles this.
The
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Wednesday 19 November 2014 at 7:50:32 PM, in
,
michaelquig...@theway.org wrote:
> Which of course would not be possible if the public
> mailing list was all encrypted.
Unless the search engine subscribed to the encrypted list and produce
On Nov 21, 2014 8:55 PM, "Ingo Klöcker" wrote:
>
> On Thursday 20 November 2014 14:36:35 Schlacta, Christ wrote:
> > On Nov 20, 2014 1:58 PM, "Ingo Klöcker" wrote:
> > > On Tuesday 18 November 2014 22:43:18 MFPA wrote:
> > > KMail encrypts an individual copy for each BCC recipient. I thought
> >
On Thursday 20 November 2014 14:36:35 Schlacta, Christ wrote:
> On Nov 20, 2014 1:58 PM, "Ingo Klöcker" wrote:
> > On Tuesday 18 November 2014 22:43:18 MFPA wrote:
> > KMail encrypts an individual copy for each BCC recipient. I thought
> > Thunderbird+Enigmail would also do this.
> >
> > Any mail
On Nov 20, 2014 1:58 PM, "Ingo Klöcker" wrote:
>
> On Tuesday 18 November 2014 22:43:18 MFPA wrote:
> KMail encrypts an individual copy for each BCC recipient. I thought
> Thunderbird+Enigmail would also do this.
>
> Any mail client not doing this completely subverts BCC (unless
--throw-keyids
> o
On Tuesday 18 November 2014 22:43:18 MFPA wrote:
> On Tuesday 18 November 2014 at 6:15:57 PM, in
> , Mirimir wrote:
> > As long as messages were separately encrypted to each
> > recipient, no third parties would be involved.
>
> For an email message with multiple recipients, I think most mail
> cl
He’s mainly explaining how do you fight spam in a centralized way, and
then explain how all the centralized techiques are unusable when using
crypto. That’s normal, crypto and decentralization comes together. You
need to think according other paradigms.
And the point I'm making is this: this set
"Gnupg-users" wrote on 11/19/2014 02:30:40
PM:
> - Message from "Robert J. Hansen" on Wed,
> 19 Nov 2014 12:08:42 -0500 -
>
> To:
>
> Nan , gnupg-users@gnupg.org
>
> Subject:
&
On 2014-11-19 at 18:17, Robert J. Hansen wrote:
N>> I agree with several other important points you raise, but this one is not
a big
>> deal. I have a highly customized mail setup. My SpamAssassin downloads rules
>> from the internet, but trains its Bayesian filter on only the e-mail I
>> personal
I agree with several other important points you raise, but this one is not a big
deal. I have a highly customized mail setup. My SpamAssassin downloads rules
from the internet, but trains its Bayesian filter on only the e-mail I
personally receive.
I don't mean to sound like I'm dismissing your
First, "charlatan" and "snake oil" imply deceit.
From Google: "A product, policy, etc. of little real worth or value that
is promoted as the solution to a problem."
So let me say it clearly: your product is of little real worth or value.
It's snake oil. It doesn't appear to bring anything to t
On 19 Nov 2014 12:28:04 Peter Lebbing wrote:
> looks like lighting the fuse
*Not* my intent. Just acknowledging that I understand it's important to you,
Robert. Feel free to ignore the paragraph.
If there's a blast, we'll all survive :)
Nan
GoodCrypto warning: Anyone could have read this me
Le 19/11/2014 à 12h17, Peter Lebbing a écrit :
> On 19/11/14 01:31, Robert J. Hansen wrote:
>> No. Client-side, you get to inspect (fully) only your data, and you
>> have to develop a statistical model of spam based on only your data.
>> When Gmail filters, it inspects (fully) traffic to *millions
On 19/11/14 09:54, Nan wrote:
> First, "charlatan" and "snake oil" imply deceit.
They often do, don't they? I doubt that is what is meant, though. If I look in
the Oxford online dictionary:
Definition of charlatan in English:
noun
A person falsely claiming to have a special knowledge or skill
De
On 19/11/14 01:31, Robert J. Hansen wrote:
> No. Client-side, you get to inspect (fully) only your data, and you
> have to develop a statistical model of spam based on only your data.
> When Gmail filters, it inspects (fully) traffic to *millions* of users,
> and uses that to create a model no ind
Robert, let's try to defuse this.
To quote Werner, Salam-Shalom.
First, "charlatan" and "snake oil" imply deceit. Goodcrypto:
* Is open source
* Uses GPG for mail encryption
* Links to "The limits of GoodCrypto" right on the front page
* Has asked for audits from many people, including:
Le 19/11/2014 à 01h31, Robert J. Hansen a écrit :
>> It’s completely true. However Mark’s right when saying it could help
>> to do it client-side...
>
> No. Client-side, you get to inspect (fully) only your data, and you
> have to develop a statistical model of spam based on only your data.
> When
> It’s completely true. However Mark’s right when saying it could help
> to do it client-side...
No. Client-side, you get to inspect (fully) only your data, and you
have to develop a statistical model of spam based on only your data.
When Gmail filters, it inspects (fully) traffic to *millions* o
On 2014-11-18 at 17:09, Robert J. Hansen wrote:
>> Would this not at the same time make it simple for MUAs to discover
>> that "this message is not from anyone you say you know. Delete
>> without reading?"
>
> Sure, but that also destroys the email ecosystem. One of email's
> strongest points has
On 11/18/2014 12:21 PM, NdK wrote:
> Il 18/11/2014 19:15, Mirimir ha scritto:
>
>> What distinguishes a mail list from email with bcc? Software? Size?
> That you're sending to a *single* address that hides the others.
As soon as a recipient replies, their address is no longer hidden.
>> As long
On 11/18/2014 03:43 PM, MFPA wrote:
> Hi
>
>
> On Tuesday 18 November 2014 at 6:15:57 PM, in
> , Mirimir wrote:
>
>
>> As long as messages were separately encrypted to each
>> recipient, no third parties would be involved.
>
> For an email message with multiple recipients, I think most mail
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Tuesday 18 November 2014 at 6:15:57 PM, in
, Mirimir wrote:
> As long as messages were separately encrypted to each
> recipient, no third parties would be involved.
For an email message with multiple recipients, I think most mail
clients a
The "third party" you don't trust is your own sysadmin. That person
already has access to the plain text messages right now. So does
everyone tapping your connections. We suggest that you limit that
risk to the sysadmin you already trust.
You're introducing a single point of failure -- and a SPO
Zitat von "Mark H. Wood" :
[...]
This raises an interesting point. If I bequeath my collected letters
to someone, how do I arrange the transmission of the necessary
passphrases as well? I wonder if the lawyer who draws up my will
would even understand the question.
If we want to leave our s
Il 18/11/2014 19:15, Mirimir ha scritto:
> What distinguishes a mail list from email with bcc? Software? Size?
That you're sending to a *single* address that hides the others.
> As long as messages were separately encrypted to each recipient, no
> third parties would be involved.
But:
1) you shou
On 2014-11-18 16:34, Nan wrote:
> Alexandre, do you really believe that anyone could "deserve to remain a
> slave"?
In the meaning “it’s normal/understandable/explainable to be a slave if
you want freedom without doing nothing to get it while other want you
not to be”, yes.
But all the importanc
>> ClawsMail, Thunderbird, etc.
>
> People usually don't want to change mail clients. Most have no idea
> how to configure crypto or manage keys.
They’re just the default and almost more used MUA. If you exclude
proprietary software and SaaSS (webmail). But asking for privacy using
proprietary se
On Mon, Nov 17, 2014 at 01:49:01PM -0500, Robert J. Hansen wrote:
[snip]
> The crypto dream is that the confidentiality of our messages will be
> preserved for centuries after our death, which sounds really great up
> until you consider what an archaeologist circa 4000 AD is going to be
> thinki
Thanks, Kristian. I will look into it.
GoodCrypto warning: Anyone could have read this message. Use encryption, it
works.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 11/18/2014 06:30 PM, Nan wrote:
>> third party -- your mailserver administrator
>
> The "third party" you don't trust is your own sysadmin. That
> person already has access to the plain text messages right now. So
> does everyone tapping your con
What distinguishes a mail list from email with bcc? Software? Size?
As long as messages were separately encrypted to each recipient, no
third parties would be involved.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/li
> third party -- your mailserver administrator
The "third party" you don't trust is your own sysadmin. That person already has
access to the plain text messages right now. So does everyone tapping your
connections. We suggest that you limit that risk to the sysadmin you already
trust.
> te
Would this not at the same time make it simple for MUAs to discover
that "this message is not from anyone you say you know. Delete
without reading?"
Sure, but that also destroys the email ecosystem. One of email's
strongest points has been that no introduction is necessary to begin a
conversat
Alexandre, do you really believe that anyone could "deserve to remain a slave"?
Assuming you don't, I'll address your calmer points.
> mygroup.org can be corrupted, menaced or cracked.
Sure, a server is a single point of failure for the group, and must be
carefully configured and protected. I
It's time to expose my ignorance again, hopefully to cure some of it.
On Mon, Nov 17, 2014 at 12:02:07PM -0500, Robert J. Hansen wrote:
> > But sorry, I disagree a little bit. If we want literally to jam the
> > secret service's attempts to decrypt mails, then it makes sense to use
> > encryption
On 2014-11-18 at 10:43, Nan wrote:
>> If you're running the mailserver and you can decrypt my secured messages,
>> then there's
>> nothing preventing the federal government from serving you with a subpoena
>> saying,
>> "please hand over the encryption keys."
>
> I agree. A third party should n
I agree. A third party should never handle the filtering of mail. If
my email is n...@mygroup.org, then mygroup.org handles the
encryption, decryption, spam filtering, etc.
A third party -- your mailserver administrator -- should never handle
the decryption or signing. (There may be a couple of
UX-designer-aproach to car design:
"We need to remove break and clutch pedals from cars because our user studies
say that a 3 pedal interface for driving an automobile is just way too
difficult."
I say those who can’t be arsed to learn how, do not deserve a driver’s license.
You let a child fa
On 11/17/2014 09:30 PM, Nan wrote:
> I think you'll find this has been solved for years. The solution is
PGP/etc. between mail servers, and TLS/SSL to the user.
Why use PGP between mail servers? SSL/TLS can be used for that, too.
Actually, opportunistic server-to-server TLS is supported by many ma
Hi Robert,
> Given that I've seen PGP-signed spam mails, no, I think you're being naive.
You use the same antispam/antivirus you use now. What people do today is a
little complex, so I understand why it's not clear:
your mail server -> your crypto server (decrypts) -> your mail server
(ant
On 2014-11-17 at 18:02, Robert J. Hansen wrote:
>> But sorry, I disagree a little bit. If we want literally to jam the
>> secret service's attempts to decrypt mails, then it makes sense to use
>> encryption for every single mail, private, business, nonsense and spam
>
> This would have the ulti
Well, no. The crypto dream is that powerful people will stop being
able to retrieve lot of informations on why they exerce power on, and
that these people will be able to inform and communicate in a
decentralized, horizontal and autonomous manner wathever this
autority wants.
Oh, please.
If I t
On 2014-11-17 at 19:49, Robert J. Hansen wrote:
>> Most of the technical reasons can be bypassed by making a single
>> subscriber key (public and private) available as a part of the
>> subscription process, but that eliminates most of the technical
>> advantages of encryption, so it's really a moot
I think you'll find this has been solved for years. The solution is
PGP/etc. between mail servers, and TLS/SSL to the user.
Given that I've seen PGP-signed spam mails, no, I think you're being naive.
Solutions like GoodCrypto integrate with your existing mail server.
Then I don't want it. I
Hi Robert,
>This would have the ultimate effect of destroying email as a platform. . .
>antispam . . . malware
I think you'll find this has been solved for years. The solution is PGP/etc.
between mail servers, and TLS/SSL to the user.
Solutions like GoodCrypto integrate with your existing ma
On 17-11-2014 17:10, Matthias Mansfeld wrote:
> But sorry, I disagree a little bit. If we want literally to jam the
> secret service's attempts to decrypt mails, then it makes sense to use
> encryption for every single mail, private, business, nonsense and spam
Makes spam filtering a lot hard
Most of the technical reasons can be bypassed by making a single
subscriber key (public and private) available as a part of the
subscription process, but that eliminates most of the technical
advantages of encryption, so it's really a moot point.
It also means there's pretty much no point in kee
I wouldn't say invite only. Contrarywise, when you send the subscribe
email, in the immediate, automatic response would be the public and private
key, optionally encrypted to the recipient. Open enrollment, public
availability. Just making the data obfuscated in transit.
On Nov 17, 2014 10:15 AM, "
On Mon, 17 Nov 2014 18:48, aarc...@aarcane.org said:
> Most of the technical reasons can be bypassed by making a single subscriber
> key (public and private) available as a part of the subscription process,
And by that you would disrupt the open discussion and knowledge culture
and return to an in
Most of the technical reasons can be bypassed by making a single subscriber
key (public and private) available as a part of the subscription process,
but that eliminates most of the technical advantages of encryption, so it's
really a moot point.
On Nov 17, 2014 8:52 AM, "Matthias Mansfeld" <
m.man
But sorry, I disagree a little bit. If we want literally to jam the
secret service's attempts to decrypt mails, then it makes sense to use
encryption for every single mail, private, business, nonsense and spam
This would have the ultimate effect of destroying email as a platform.
Email work
Zitat von Werner Koch :
On Mon, 17 Nov 2014 13:33, n...@goodcrypto.com said:
GoodCrypto warning: Anyone could have read this message. Use
encryption, it works.
That does not make any sense on a public mailling list. We write here
for the public - it is non-encrypted for a purpose.
scnr,
55 matches
Mail list logo
