MIME or inline signature ?
Hugo Osvaldo Barrera
hugo at barrera.io
Sat Feb 14 22:45:16 CET 2015
On 2015-02-14 13:36, Doug Barton wrote:
> FWIW, I hate this debate, and try hard to stay out of it. But it really
> bothers me when people spread factually incorrect information, especially
> when they try to use that as the basis of their arguments for/against one
> method or the other.
> On 2/14/15 7:49 AM, Hugo Osvaldo Barrera wrote:
> >Pros of GPG/Mime:
> >* It's a lot less ugly for users with no gpg support. The large signature block
> > at the end and the gpg marks are hard to ignore.
> Why are you signing mail that is being sent to people without PGP support in
> the first place?
I've no way of determining who has gpg support and who has not really and I
prefer to sign by default. Validating (or not) the signature is up to the
They may also gain gpg support in future, and can back-validate previous
> >* AFAIK, inline gpg has issues with non-ascii characters. 😞 Correct me if I'm
> > wrong.
> This hasn't been true for almost a decade, assuming that the person using
> the non-ASCII characters has correctly set up their environment. And FWIW,
> it's also not true that PGP/MIME will be 100% successful when one of the
> communicants has not correctly set up their environment.
Ah, I'm sorry for the misinformation in that case. I may never have been
updated to the latest on this, and I appreciate the correction - I'll avoid
repeating this again.
> >* Inline-gpg includes a signature for each attachment. This allows third
> > parties to count how many files are attached (and their filenames, I
> > believe). gpg/mime include one huge blob, so third parties can't tell this
> > sort of metadata.
> Nothing you wrote in this section is 100% correct. You *can* send one
> signature per attachment, but you don't have to. You can also bundle the
> attachment and signature in an archive, or you can bundle a lot of
> attachments in the same archive, and sign that, or you can bundle all of the
> attachments and signatures in one archive .... etc.
> It's also not true that PGP/MIME protects you from metadata analysis. The
> messages are not "one big blob," they are actually separated into parts,
> including the attachments. It's trivial to see how many attachments are in a
> message just by analyzing the MIME headers, whether the message/attachments
> are encrypted or not.
From my experience, pgp/mime emails with encrypted into a are a single
msg.asc, which needs to be decrypted to determine the mime parts inside. Is
The (admitedly few) clients I've tried with gpg-inline attached a single
additional mime part per attachment when encrypting, making attachment count
and filenames visible. There may be a way to do this differently, but no email
client seems to do it, so it's sort of a moot point. Expecting users to do this
manually is a bit burdensome, compared to gpg/mime.
> >In the end, I'd suggest you go with what you prefer on a whim, more than
> >techinical reasons.
> ... or, you could use what your correspondents are able to handle, since
> theoretically that's the point of communication in the first place? :)
There will always be people who can handle one and not the other (and let's not
forget you'll probably know more people in future). There's no single mechanism
that'll work for everyone.
> hope this helps,
Yes, thanks for the insight. Especially on the non-ascii related information,
for which it seems I was out-of-date.
Hugo Osvaldo Barrera
A: Because we read from top to bottom, left to right.
Q: Why should I start my reply below the quoted text?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: not available
More information about the Gnupg-users