Pros and cons of PGP/MIME for outgoing e-mail?

Werner Koch wk at
Wed Nov 26 09:48:09 CET 2014

On Mon, 24 Nov 2014 14:24, bre at said:

> Similarly, when generating messages I had to fork the Python lib's
> generator and disable various "helpful" hacks that were randomly

Hmmm, one more reasons for me to start writing a gpgsendmail tool to
create encrypted or signed mails with attachments and that all.  Doing
this with a script and sendmail is possible but it comes to problems if
you need to insert user data which might reqyuired a different encoding.

> You want to verify that the message composed by the user did not
> change - the technicalities of the container it is placed in could
> well have been considered out of scope. Requiring that white space
> placement and irrelevant things like boundary strings stayed unchanged
> is unnecessary and in practice counterproductive because it tightly

You can do messy things by changing boundary strings, for example to
bypass DKIM.  If a message including attachments is signed you do not
want that anything changes.  And some people actually use the boundary
as a side-channel (check mine) ;-).  I agree that things could be done
easier by rewriting the boundary - but it will end up with a chain of
other changes you need to allow, for example you also need to change the
Content-Type to identify the new boundary and why not also fix other
things in this header, where to stop.  All too complicated.  Better
don't touch any signed stuff.

> It would be far, far more useful to have a signature for each part so
> instead of a binary pass/fail, you get a more granular result saying
> "Message body was fine", "Attachment 2-5 are fine", and "Something

Too complicated and allows for replacement-attacks: Split a signed
message and replace one attachment (e.g. a document with the price list)
by an earlier version.  Or remove one attschment.  PGP uses this to get
around Outlook problems ("partitioned mail" or so) but they knew that it
has its limitations.

> That is basically the kind of workflow my proposal emulates, is
> compatible with and attempts to improve upon.

Early kmail versions did the same.

> way it can validate contents and structure, and also transmit headers we
> would like to omit from the public RFC2822 header - without assuming or
> imposing anything about the low level technical structure of the MIME

MIME, is 22 years old and thus a year older than the first graphical web
browser (Mosaic) which is believed to gave birth of the non-academic
Internet.  We have seen generations of different software hypes come and
go but still some dislike to properly implement an easy and good way to
partition data.  I don't get it.



Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

More information about the Gnupg-users mailing list