Re: Setpref is not working or is it a bug or something?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Sunday 30 November 2014 at 9:46:40 AM, in
, gnupgp...@on.yourweb.de wrote:
> Yes, that's true, SMTP-Filter is running for outgoing
> mails:
> http://lab1.de/Central/Software/Internet/E-Mail/SMTP-Filter/
> It deletes for security/privacy reasons:
> IN-REPLY-TO:
That header is used to tell the recipient's email software what
message-ID the reply is to, so that the response can be threaded.
> MESSAGE-ID:
If you delete the message-ID, a new one is added by the next server
that handles the message.
> ORGANIZATION:
If you are going to delete this, why supply it in the first place?
> REFERENCES:
This is used along with the IN-REPLY-TO header for threading. It may
contain more Message-IDs from the thread. Useful on a mailing list in
case someone following the thread has blocked some contributors or
deleted/not received the message to which you just replied.
> X-MSMAIL-PRIORITY:
Given that you set this on a per-message basis as High/Normal/Low,
it's not a security/privacy issue at all. Deleting it just means all
your messages default to Normal priority.
> Hidden header 'In-Reply-To:
> <1CD78A.547AEDEA.0002@machine>': IN-REPLY-TO and
> REFERENCES for example include ...@machine, which is
> always the same... This is not wanted because of the
> possibility of tracking cross over the web ("who posts
> which content...")
Having it in those headers in the messages you post means you are
replying to a thread containing the content, not that you posted the
content.
Besides, unless the user has specifically set their mailer to do
something different, the bit after the "@" often defaults to the
domain in their email address.
> So, how to deal with this behavior? Keeping subject
> untouched seems to be enough for identifying and
> associating to thread, isn't it?
Only if for each thread you use a unique subject line that will never
be repeated, and you can guarantee that everybody reading the threads
only ever receives email from people who do the same.
- --
Best regards
MFPAmailto:2014-667rhzu3dc-lists-gro...@riseup.net
When duty calls...hang up immediately
-BEGIN PGP SIGNATURE-
iPQEAQEKAF4FAlR74ZpXFIAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0
N0VDQTAzAAoJEKipC46tDG5puYsD/RjtmsGTj/6/qSiX2u4u0QBKYA536SOSBhpp
800sD3j71cmxWHQN0JF01NdwsJRk2NHnOD/nvwB5vPSwemMg9uuF43IinKvwIr1o
rYdEKpS1ytW/SmuyFkz7uV8hFH/XJugNSRnqfx/TGHmORTv387aQIzXX3nETsPtb
/D4Ha/I9iQF8BAEBCgBmBQJUe+GaXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRp
b25zLm9wZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZB
NUEwRjU2QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwmt8H/iV9MEXIHHUyXDNk
uxIv6Q2GBOVPHLNF3JAumuDFkcdFnjuM3vUMa9nHCb0Pr+pYNaUKbJWXwlO1nqHI
SA0ehkEjYhdzDFHID4YRmO+Di4gMELY5UR2FJzof6GVn3BFtEUp924HgSo7cYNGG
ZpAvBsYWzN5kD36NV0OKDjRYkr4FWEsgmXrJEuWjooUECBqECbz3un32MdjmGCHs
NdcL/huThZbjCbgoF4XF3WxS6FntIgVNDdszHV9NQXsQrZRN3R48u6k+i8nhPpl0
fV643aa6Bk8DpUUXxA5U1Zi/Njg7NaZQxhD/N4ljRomVgAfHQj2Oj1uG9gGyChr4
2/z3Lkk=
=l43K
-END PGP SIGNATURE-
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Order/changing of subkeys derogates compatibility!?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Sunday 30 November 2014 at 7:21:09 PM, in , gnupgp...@on.yourweb.de wrote: > So, is there a known issue regarding the order of > DSA-subkeys for signing? How to change order of subkeys > for testing purpose? - From (possibly inaccurate) memory, PGP was up to somewhere around version 8.x before it supported signing subkeys. IIRC, older PGP versions would choke on trying to encrypt to a key whose newest subkey was flagged for signing but not encryption, and would use the main key to sign with. (I have no recollection of what happened trying to verify signatures.) - -- Best regards MFPAmailto:2014-667rhzu3dc-lists-gro...@riseup.net Ultimate consistency lies in being consistently inconsistent -BEGIN PGP SIGNATURE- iPQEAQEKAF4FAlR72ABXFIAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pOzwD/3c6wAOrasH0OnbKbtt2vIyICXtII/ziOsc3 bKdIR6//JSMesoWejVQOQocH5xq0mAbvhsCW41LCy4yOxVHuyQ7F3s3dU/WQLKWW qlMnBJ/ATIFAgGJ34DL1SUrRLEwU+hbX6gzk8Bsq+IM1LxdxNORg6BYbTMcKBRPE nGgf41W1iQF8BAEBCgBmBQJUe9gAXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRp b25zLm9wZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZB NUEwRjU2QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwUSAH/2rJW01PxmMFvRgw WiWJ5GOfFoqlXApF6pBCgq9jwBwH2hxanc0F1xy7cTs04MMN4vmGjRzruBqO5V4c BeWQSNTkc+RR6YZ+3GF9/ERA/mCOLnUu4irQCs1Akg7n7+ifU3ZFUi4Ip+4Rip5L uYfBuJ7ngsSM1xGQG1wpLI1XNo9B6onphMAaAOY3QYgQy7cyUF5kK3he1DvKwOTM PxgO3cZxyICml+Y8BWeVA7YArm9snrBKKFGGXMdOKXNuKy0IyqTU/vguynxrY9rv D+9tMEpSBaRjKcpvuB0ZDkrXEAQy4+UzFLgKSHUAjE4AQUjQk5eTsEoZ+ARD1Y9a MZyjAWM= =ic9w -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Setpref is not working or is it a bug or something?
On Sunday 30 November 2014 10:46:40 gnupgp...@on.yourweb.de wrote:
> >> I am sorry, all my replies are sent to gnupg-users@gnupg.org only,
> >
> > Yes, that's the right procedure.
> > The problem Peter mentioned is caused by the fact that your replies lack
> > the message headers (In-reply-to and References) that usually link
> > replies to the replied-to messages.
>
> Yes, that's true, SMTP-Filter is running for outgoing mails:
> http://lab1.de/Central/Software/Internet/E-Mail/SMTP-Filter/
>
> It deletes for security/privacy reasons:
> IN-REPLY-TO:
> MESSAGE-ID:
> ORGANIZATION:
> REFERENCES:
> THREAD-INDEX:
> THREAD-TOPIC:
> X-MAILER:
> X-MIMEOLE:
> X-MSMAIL-PRIORITY:
> X-Relayed-By: GPGrelay
>
> Hidden header 'In-Reply-To: <1CD78A.547AEDEA.0002@machine>':
> IN-REPLY-TO and REFERENCES for example include ...@machine, which is always
> the same... This is not wanted because of the possibility of tracking cross
> over the web ("who posts which content...")
IMHO that's nonsense. Those headers do not identify your machine. Those
headers reference the messages you reply to, so if anything then those headers
identify the machine of the person you reply to.
> So, how to deal with this behavior?
I suggest that you stop deleting the In-reply-to and the References header.
> Keeping subject untouched seems to be enough for identifying and associating
> to thread, isn't it?
Yes. At least for email clients that also thread messages by the Subject
header. But even those mail clients usually don't know which original message
your reply belongs to and therefore those mail clients will put your message
below an arbitrary other message in the thread. This makes reading longer mail
exchanges with multiple participants (e.g. like here on this mailing list) a
PITA.
Regards,
Ingo
signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Difference Kleopatra vs WinPT
> Which one is better/more used? WinPT only works with the 1.4 branch of GnuPG and hasn't had a new release in the last five years. I'm under the impression Timo (the author) has stopped working on it or supporting it. Given that, I'd have to recommend not using WinPT. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Order/changing of subkeys derogates compatibility!?
> while creating some new v4-RSA keypairs a compatibility issue occurs with > old PGP-6.5.x: 6.5.8 is about sixteen years old now and has many known security problems. Please stop using it. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Order/changing of subkeys derogates compatibility!?
Hello to all, while creating some new v4-RSA keypairs a compatibility issue occurs with old PGP-6.5.x: C,E should be RSA, S should be DSA (2048 with SHA256 for smaller signatures...) Sec/pub keyset is used with GPG-1.4.18 (Win7-64), pub key is exported to PGP-6.5.x only for testing purpose on another machine. First attempt, everything is working in PGP-6.5.x too: pub 3072R/D956D57E erzeugt: 2014-11-30 verfällt: niemals Aufruf: C Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt sub 2048D/A916DB9A erzeugt: 2014-11-30 verfällt: niemals Aufruf: S sub 3072R/599E4462 erzeugt: 2014-11-30 verfällt: niemals Aufruf: E [ uneing.] (1). rsa3072 name (kom) Second attempt, editing: After test-editing the subkeys with changing DSA-subkey it gets last position and is not working in PGP-6.5.x pub 3072R/D956D57E erzeugt: 2014-11-30 verfällt: niemals Aufruf: C Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt sub 3072R/599E4462 erzeugt: 2014-11-30 verfällt: niemals Aufruf: E sub 2048D/01D27D06 erzeugt: 2014-11-30 verfällt: niemals Aufruf: S [ uneing.] (1). rsa3072 name (kom) Third attempt, everything is working in PGP-6.5.x too, RSA only: pub 3072R/D956D57E erzeugt: 2014-11-30 verfällt: niemalsAufruf: C Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt sub 3072R/599E4462 erzeugt: 2014-11-30 verfällt: niemalsAufruf: E sub 3072R/B65BF3EE erzeugt: 2014-11-30 verfällt: niemalsAufruf: S [ uneing.] (1). rsa3072 name (kom) No difference, if using RSA-2048 bit. No Difference, if using DSA-1024 bit. If new keypair is created 'by hand' in this order: RSA C 3072 DSA S 2048 RSA E 3072 everything works till editing any of subkey. But this option is needed because of future changings in subkey set while keeping main key ID... So, is there a known issue regarding the order of DSA-subkeys for signing? How to change order of subkeys for testing purpose? Thanks and best regards, Chris ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Keygrip v fingerprint ?
On 30/11/14 01:32, Kristian Fiskerstrand wrote: > The keygrip is protocol-agnostic whereby the fingerprint would differ > e.g. between OpenPGP and X.509. From [0] (note "[2]"): > > The keygrip is a unique identifier for a key pair, it is > independent of any protocol, so that the same key can be used with > different protocols. PKCS-15 calls this a subjectKeyHash; it can be > calculated using Libgcrypt's gcry_pk_get_keygrip (). Thank you, Kristian signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
RE: Setpref is not working or is it a bug or something?
>> I am sorry, all my replies are sent to gnupg-users@gnupg.org only,
> Yes, that's the right procedure.
> The problem Peter mentioned is caused by the fact that your replies lack
> the message headers (In-reply-to and References) that usually link
> replies to the replied-to messages.
Yes, that's true, SMTP-Filter is running for outgoing mails:
http://lab1.de/Central/Software/Internet/E-Mail/SMTP-Filter/
It deletes for security/privacy reasons:
IN-REPLY-TO:
MESSAGE-ID:
ORGANIZATION:
REFERENCES:
THREAD-INDEX:
THREAD-TOPIC:
X-MAILER:
X-MIMEOLE:
X-MSMAIL-PRIORITY:
X-Relayed-By: GPGrelay
Hidden header 'In-Reply-To: <1CD78A.547AEDEA.0002@machine>':
IN-REPLY-TO and REFERENCES for example include ...@machine, which is always
the same... This is not wanted because of the possibility of tracking cross
over the web ("who posts which content...")
So, how to deal with this behavior?
Keeping subject untouched seems to be enough for identifying and associating
to thread, isn't it?
Thanks + regards,
Chris
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
