*** bug 210041 has been marked as a duplicate of this bug. ***

IMHO, it's like "how do you represent bold text if you're sending
as text/plain?". You don't.

	(!) HTML and inline PGP are incompatible. You need to
	    use PGP/MIME if you want to sign or encrypt an HTML
	    message.

	   [Send as plain text] [Don't use PGP] [Use PGP/MIME]

or something.

There's also the issue of attachments. I think if you try to combine
attachments with inline pgp you should get something like:

	(!) Attachments cannot be signed if you are using
	    inline PGP. You use should use PGP/MIME instead
	    if you need to send attachments

	   [Cancel] [Attach without Signing] [Use PGP/MIME Instead]

and likewise for s/sign/encrypt/.
    

ok

*** bug 219700 has been marked as a duplicate of this bug. ***

*** bug 222232 has been marked as a duplicate of this bug. ***

*** bug 222273 has been marked as a duplicate of this bug. ***

*** bug 215742 has been marked as a duplicate of this bug. ***

*** bug 216747 has been marked as a duplicate of this bug. ***

looks like Outlook signs both text parts (I don't think it signs them
individually though, which is broken..hah).

Anyways, there's no possibly way to verify the text/html part because
the "---- BEGIN PGP SIGNED MESSAGE -----" string isn't on a line by
itself like it's supposed to be... instead Outlook does this:

<FONT blah blah blah>----- BEGIN PGP SIGNED MESSAGE -----</FONT>

There might have been a <PRE> in there too, I forget. The point is
there is a ton of HTML crap around it so there's no way to verify it.

same goes for encrypted stuff.

this is why inline pgp is inherantly broken at a fundamental level :-)

*** bug 213933 has been marked as a duplicate of this bug. ***

*** bug 224164 has been marked as a duplicate of this bug. ***

*** bug 224114 has been marked as a duplicate of this bug. ***

*** bug 224397 has been marked as a duplicate of this bug. ***

*** bug 226031 has been marked as a duplicate of this bug. ***

*** bug 227403 has been marked as a duplicate of this bug. ***

*** bug 227605 has been marked as a duplicate of this bug. ***

*** bug 228453 has been marked as a duplicate of this bug. ***

*** bug 230596 has been marked as a duplicate of this bug. ***

*** This bug has been marked as a duplicate of 217540 ***

Silly me

I'd like to see this bug fixed.  I'm not promising a fix any time
soon, but I am studying the source code to get a feel for how things
work.  My motivation, in case you are curious, is that some mailers
separate messages from attachments, which go to some attachment
folder, making archiving of PGP/Mime messages problematic.

From the user experience, I propose to add an "inline PGP" checkbox to
the Security menu (and then in the account preferences as well). 
Implementation could be as simple as adding a pgp_inline boolean to
the necessary data structures, carrying it around in the least clunky
way as a function parameter, and branching where appropriate.  This is
all very abstract, but I didn't want to fill in all the details here.
 (An alternative would be to create a whole inline context, and I
wouldn't mind doing this, but I'd like to try the former idea first.)
 I don't think it would be too bad to send inline without receiving
capability; it wouldn't be any worse than now.  And receiving could be
added later, if at all.

As for the HTML mail problems, I have two ideas for solutions.
(1)  Make HTML and inline PGP mutually exclusive by setting plain text
mode when inline PGP is checked, etc.  This would require only a small
number of changes.
(2)  Turn the text/html part of the multipart/alternative into
text/plain, for it would no longer be text/html.  Just encrypt/sign
them both.  Chances are that mailers wouldn't be able to handle it,
but it's an easy solution, and decryption/verification could be done
manually.

Both are lamentable.  In my opinion, however, #2 is kinder to users
who want to do something stupid on purpose and so would be my first
choice.

I'd like to hear other opinions on this.  If I have naively glossed
over some fundamental problems, please let me know.  Mail client
programming is not exactly my specialty.

*** bug 233383 has been marked as a duplicate of this bug. ***

*** bug 237470 has been marked as a duplicate of this bug. ***

I also would like to be able to send emails with in-line pgp
signing/encryption.  Signing especially is useful if the message will
be archived in a text format (i.e. a mailing list).

Well about text/plain & text/html issue, it is simple:
sign text/plain part inline and sign text/html part in mime format.

This is only logical. As already said, inline signed html is absurd,
so it cann't be signed inline. Plain text must be signed inline
(because we are asked to do so). And html can be signed in mime format
as there are already two mime parts, so the third mime part will no
tinterfere much with the message.

This should be quite easy to implement.

Coming up with a clever way to combine html and inline pgp isn't
going to do any good if other clients can't read it. The way inline
pgp is defined is incompatible with MIME. You cannot mix the two.
(My earlier comment about inline pgp and attachments was wrong.
You cannot attach things to an inline-pgp-signed message
[unless you want to uuencode them as part of the signed body].)

*** bug 249679 has been marked as a duplicate of this bug. ***

adding security keyword for better finding

I don't think this is worth implementing... it's also been several years since the last request for this feature.

(In reply to comment #29)
> it's also been several years since the last request for this feature.

Woo! The swift adoption of email standards marches on! Maybe in another 6 years it will be safe to assume that all SMTP servers support "EHLO"...

One can hope :)

What is the reason for marking this one obsolete?