Re: Inline PGP Within HTML

2020-05-02 Thread Derek Martin
On Mon, Apr 27, 2020 at 01:46:26PM -0400, Scott Kostyshak wrote:
> > Yeah, I've been trying to explain this to some folks around here
> > recently, but not having much success.  You have my sympathy.
> 
> Agreed. It is frustrating. But Derek, please don't give up!

I gave up a LOOONG time ago. Like others, it's my experience that my
efforts were utterly a waste of time.  Even if you can figure out to
whom you could complain.  Often enough such messages are from
automated systems with "unmonitored accounts."  And when there IS a
text alternative, it often enough just says something like, "This
e-mail must be viewed with an HTML-capable mail client."  They clearly
know it's an issue and don't care.

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



signature.asc
Description: PGP signature


Re: Inline PGP Within HTML

2020-04-30 Thread Ben McGinnes
On Thu, Apr 30, 2020 at 10:53:32AM -0400, Mark H. Wood wrote:
> 
> A couple more ideas:
> 
> 'maildrop' comes with some nice tools for working with mail in
> scripts.  (It's also a rather good filtering / routing / piping /
> you-name-it MDA.)

Maildrop is awesome and so much better than procmail.

> Python has some nice standard library classes that are really good
> at working with mailboxes (all kinds) and individual messages.

Yes, it does.

It can also be used very well with the Python bindings for the GnuPG
Project's GPGME API.  For example, here's a key import practiced on
Kevin's key (just because, since you can see that result.unchanged is
true and thus already had it).

Python 3.8.2 (default, Apr 10 2020, 16:52:52)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.13.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import requests
In [2]: import gpg
In [3]: url = 
"https://u15940057.ct.sendgrid.net/ls/click?upn=TfVBFLs581SSFDYC71Gnki6ytoyFTNVdUM4dqUBeCPia35bNXiwzFmYClpz3QP21G39Y0NzH9gkmXiwhrGiBpg-3D-3DvPzl_3cJdHWS4A4qHYuI0cbfv110yZgaEGqoy3qsIRLwUxNzRrGopS9bx7-2Bfg7illxJcEW23Jj94-2FxX9QbXBps6sq9ps60TwKp-2BLbC0uPpPIFVdLsL2cY91jwsNnZh-2BTF6GnxtR8PfINUamDg02yqfOsAnA1Tp5UIHFwDtL6Kd5gx1LIigAcwJIMJ3Z-2BO3t4Ixr5-2FTeSHMvBdhGCPK0JJ0KnIsUHfmM9VirJ54dvtwlJuBrQ-3D
In [4]: r = requests.get(url)
In [5]: result = gpg.Context().key_import(r.content)
In [6]: len(result.imports)
Out[6]: 1
In [7]: print(result)
ImportResult(considered=1, imported=0, imported_rsa=0, 
imports=[ImportStatus(fpr='8975A9B33AA37910385C5308ADEF768480316BDA', result=0, 
status=0)], new_revocations=0, new_signatures=0, new_sub_keys=0, 
new_user_ids=0, no_user_id=0, not_imported=0, secret_imported=0, secret_read=0, 
secret_unchanged=0, skipped_new_keys=0, skipped_v3_keys=0, unchanged=1)
In [8]:

It's also documented well enough that getting it to behave with with
all sorts of obscure custom stuff should be fairly straight forward.


https://u15940057.ct.sendgrid.net/ls/click?upn=TfVBFLs581SSFDYC71Gnkki6qSNYtAoDX72HhaQ1QGBpddfa6Vm1iYIIBKo-2Fou413nRux54jyBPutHuXImlrUCE7OuLoVf4j9OIDFXUgRqo-3DBOt8_3cJdHWS4A4qHYuI0cbfv110yZgaEGqoy3qsIRLwUxNzRrGopS9bx7-2Bfg7illxJcEZKVverhnQMd44ujj7uP5upQKh04GQiU8GohDJPSiZcVvo3nD4iDdOeqp4ZZeu3jR3-2Fn6UR3gxY2ilzxW6kG8800Ru-2BklYNaqx4gcU09POClr7bkB3bLyqeFn5pTkKfyCLSZwBV4IhLweWNSH0b-2Fh6iKVI7rMzSBD7LQ3IQu7wXg-3D

Obligatory disclaimer: I wrote the HOWTO and worked on the bindings
extensively.


Regards,
Ben

P.S.  The HOWTO is hosted on AWS S3, so you can make it HTTPS if you
  want to trigger and then bypass the SSL wildcard certificate
  mismatch error message.


signature.asc
Description: PGP signature


Re: Inline PGP Within HTML

2020-04-30 Thread Ben McGinnes
On Tue, Apr 28, 2020 at 12:18:14AM -0500, David Engel wrote:
> 
> We are a small company ahd IT is only one of his many jobss along
> with facilities, planning, project management and others.  He got IT
> because nobody else was willing to do it.  The explanation I got for
> not embracing an integrated, PGP solution was that he'd tried it
> before and that it broke wheneve MS issued an update to Outlook.

How many years ago did he try it?

GPG4Win has made vast improvements over the last several years.  As
long as the Windows versions in use are relatively current (i.e
post-runtime overhaul), then it should solve much of this.

If they're prepared for a bigger change that will solve it and still
let them use a GUI editor, then Thunderbird and Enigmail are right
there.  Hell, it was the default email for Sun Microsystems for years
and you need huge amounts of email to screw with it too basly (which I
have, which is why returned to Mutt/Neomutt and Emacs, though I
actually had that with TB too).

> I've shown an integrated solution to the two department heads
> repsonsible for most of the users.  One of them is my boss.  The
> problem is there is a lot of inertia behind the current, inefficient
> way they do things.  Everyone knows it's a pain but they all no how
> to do it and are reluctant to change.

Well, I guess that's a vehement *no* to the Thunderbird option.  

> To me, it's mind boggling how much productivity is lost.  The text
> for each encrypted email must be copied and pasted through the
> stand-alone PGP to encrypt of decrypt.  File attachements must be
> encrypted separately before sending and saved and decrypted
> separately upon receipt.  It's crazy.

Yeah, that's preety crazy and so unnecessary.  I mean it's not like
we're using PGP 2.x on old mid-'90s era systems.

Depending on what the full scope of what the ultimate end result is,
it might be possible to be streamlined and automated more, without
adversely affecting any other senders or recipients who know how
PGP/MIME works and that it's a Good Thing™ (like you).


Regards,
Ben


signature.asc
Description: PGP signature


Re: Inline PGP Within HTML

2020-04-30 Thread Mark H. Wood
On Thu, Apr 30, 2020 at 05:38:24AM +0100, Dave Woodfall wrote:
> On 2020-04-28 00:20,
> David Engel  put forth the proposition:
> > On Mon, Apr 27, 2020 at 06:28:55PM -0500, Sven Semmler wrote:
> > > On Sat, Apr 25, 2020 at 09:46:48PM -0500, David Engel wrote:
> > > > I've since written a filter to preprocess the HTML and remove the
> > > > extra formatting before passing it to w3m.  The traditional PGP coming
> > > > out of w3m is now properly formatted.  Alas, Mutt doesn't recognize it
> > > > and automatically decrypt it.
> > >
> > > I wonder if you could just forward that sanitized block to yourself as
> > > plain-text ... then mutt should deal with it just fine?
> > >
> > > It would add 2-3 keystrokes and be miles away from elegant ... but if it
> > > works until you find a better solution...
> >
> > I tried that and Mutt forwards the original email in tact.  Unless
> > there's another forward command that sends the decoded text (I didn't
> > find ont), I don't think it will work.
> 
> I've never tried to work with encrypted messages via a script, but I
> hope this is helpful or gives you some ideas.
> 
> The only thing I can think of is keep trying shell scripting a
> solution that would -dump the content from stdin to text, divide the
> parts, and then maybe either pipe to less to view it (not so useful
> for replying) or email/forward it back to yourself using either the
> mutt command line, or mail/mailx + sendmail or whichever MTA you have
> handy, hopefully keeping the headers intact or add the envelope from.
> 
> Perhaps decode the encrypted part with gpg from the script, before
> forwarding it to yourself.

A couple more ideas:

'maildrop' comes with some nice tools for working with mail in
scripts.  (It's also a rather good filtering / routing / piping /
you-name-it MDA.)

Python has some nice standard library classes that are really good at
working with mailboxes (all kinds) and individual messages.

-- 
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu


signature.asc
Description: PGP signature


Re: Inline PGP Within HTML

2020-04-30 Thread Kevin J. McCarthy

On Tue, Apr 28, 2020 at 12:20:16AM -0500, David Engel wrote:

On Mon, Apr 27, 2020 at 06:28:55PM -0500, Sven Semmler wrote:
I wonder if you could just forward that sanitized block to yourself 
as plain-text ... then mutt should deal with it just fine?


I tried that and Mutt forwards the original email in tact.  Unless 
there's another forward command that sends the decoded text (I didn't 
find ont), I don't think it will work.


Try unsetting $mime_forward, and make sure $forward_decode is set (the 
default).


As an aside, starting in 1.12.0, Mutt will offer to include attachments 
(via the quadoption $forward_attachments) for inline forwarding.


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature


Re: Inline PGP Within HTML

2020-04-29 Thread Dave Woodfall
On 2020-04-28 00:20,
David Engel  put forth the proposition:
> On Mon, Apr 27, 2020 at 06:28:55PM -0500, Sven Semmler wrote:
> > On Sat, Apr 25, 2020 at 09:46:48PM -0500, David Engel wrote:
> > > I've since written a filter to preprocess the HTML and remove the
> > > extra formatting before passing it to w3m.  The traditional PGP coming
> > > out of w3m is now properly formatted.  Alas, Mutt doesn't recognize it
> > > and automatically decrypt it.
> >
> > I wonder if you could just forward that sanitized block to yourself as
> > plain-text ... then mutt should deal with it just fine?
> >
> > It would add 2-3 keystrokes and be miles away from elegant ... but if it
> > works until you find a better solution...
>
> I tried that and Mutt forwards the original email in tact.  Unless
> there's another forward command that sends the decoded text (I didn't
> find ont), I don't think it will work.

I've never tried to work with encrypted messages via a script, but I
hope this is helpful or gives you some ideas.

The only thing I can think of is keep trying shell scripting a
solution that would -dump the content from stdin to text, divide the
parts, and then maybe either pipe to less to view it (not so useful
for replying) or email/forward it back to yourself using either the
mutt command line, or mail/mailx + sendmail or whichever MTA you have
handy, hopefully keeping the headers intact or add the envelope from.

Perhaps decode the encrypted part with gpg from the script, before
forwarding it to yourself.

If forwarding/emailing it to yourself doesn't work, you could print
the contents into a new file (for maildir) or append to an mbox file
(easier).  This is how I keep a custom record of sent messages from a
shell script.  It appends each message to an mbox file:

SMS="$HOME/sms/sms" # mbox file
subject=${TEXT:0:69} # this is just a substring of the message text
date=$(date +'%a %b %d %H:%M:%S %Y') # the format seems important
chars=$(printf %s "$TEXT" | wc -m)
balen=$(printf %s "$bal" | wc -m)

echo "From $FROM $date" >> $SMS
echo "Date: $date"  >> $SMS
echo "To: $NAME <$TO>"  >> $SMS
echo "From: $FROM"  >> $SMS
echo "Subject: $subject">> $SMS
echo "Status: RO"   >> $SMS
echo "Content-Length: $((chars+balen))" >> $SMS
echo "" >> $SMS
echo "$TEXT">> $SMS
echo "" >> $SMS
echo "$bal" >> $SMS

Each message must begin with a `From' line (without a colon).

These are the minimum headers that seem to work for me in mutt for
mbox format, but YMMV.

Calling mutt -f ~/sms/sms will read the messages, which will appear
as unread.

There should be a way to do this automatically from procmail once you
have a workable solution tested.

I hope some of this is useful anyway.

Dave


Re: Inline PGP Within HTML

2020-04-29 Thread Scott Kostyshak
On Tue, Apr 28, 2020 at 12:18:14AM -0500, David Engel wrote:

> On Mon, Apr 27, 2020 at 01:46:26PM -0400, Scott Kostyshak wrote:
> > On Mon, Apr 27, 2020 at 12:32:05PM -0500, Derek Martin wrote:
> > > On Sat, Apr 25, 2020 at 09:46:48PM -0500, David Engel wrote:
> > > > I've given up politely asking people to remember to send email as
> > > > either both text/html and text/plain or just text/plain when sending
> > > > to me.  It's a losing battle. :(
> >
> > You've given up *politely* asking? Meaning you are now asking
> > impolitely? :)
> 
> I do have to keep working with these people. :)
> 
> > > Yeah, I've been trying to explain this to some folks around here
> > > recently, but not having much success.  You have my sympathy.
> >
> > Agreed. It is frustrating. But Derek, please don't give up! Even in the
> > worst case scenario, we can slow the acceleration. I especially take the
> > time to choose the battles where the email is from an automated system.
> > I contact the support and send something like the following:
> >
> >   Could you please modify your automatic emails to also send a
> >   plain-text version in addition to the HTML email? This is easy to do
> >   and most professional emails provide a plain text version (this is
> >   called multi-part MIME).
> >
> >   If this doesn't make sense to you, please forward this request to your
> >   tech team.
> >
> >   Thanks for your time!
> 
> I have essentially done this but the problem keeps reoccurring.  I
> think part of the problem might be Outlook itself.  I vaguely recall
> seeing something about Outlook only sending both text/plain and
> text/html when those are the only two parts.  If another attachment is
> included, I seem to recall that one of the text parts got dropped.  I
> could be wrong, though.
> 
> I'm considering trying the polite approach again but this including
> the pointer to the integrated solution I tested.  Maybe I can start
> the change from the bottom up.

Makes sense. Good luck!

Scott


Re: Inline PGP Within HTML

2020-04-29 Thread Scott Kostyshak
On Mon, Apr 27, 2020 at 01:46:57PM -0600, Akkana Peck wrote:
> 
> > > On Sat, Apr 25, 2020 at 09:46:48PM -0500, David Engel wrote:
> > > > I've given up politely asking people to remember to send email as
> > > > either both text/html and text/plain or just text/plain when sending
> > > > to me.  It's a losing battle. :(
> 
> Since I don't have to deal with PGP, increasingly I wish people
> would just send HTML and dispense with the text/plain. Lynx or
> similar programs work fine inside mutt for HTML mail (if there isn't
> too much fancy formatting),

I guess we disagree :)

> but if there's a text/plain part, more
> and more often it's blank, garbled or just unreadable because it
> lacks any line breaks.

True, this is worse than not sending a plain part. Actually, in this
case at least you might realize that you should check for the HTML
message. Even worse is if the plain has some info but not all, in which
case you might not even realize there's a problem.

> Scott Kostyshak writes:
> >   If this doesn't make sense to you, please forward this request to your
> >   tech team.
> 
> I wish! But the "tech team" almost never has any idea what MIME
> multipart/alternative is, and any attempt to convince them that
> they're sending out garbled email just results in "It looks fine
> to me and nobody else has complained."
> 
> In fact, out of many complaints about such problems, I don't think
> I've *ever* gotten an answer like "Oh, thanks for letting me know,
> I guess I never checked the plaintext part." It's been "looks fine
> to me" every. single. time. And most of the time, no matter how many
> times we go back and forth I can never manage to convince them even
> that a text part exists, let alone that it's worth fixing.

I have had similar troubles. Most of the time I don't get a response.
But once in a while I come across a kind tech support person who is open
to the idea and that makes up for the 10 non-responses so I keep trying.

Scott


Re: Inline PGP Within HTML

2020-04-27 Thread David Engel
On Mon, Apr 27, 2020 at 06:28:55PM -0500, Sven Semmler wrote:
> On Sat, Apr 25, 2020 at 09:46:48PM -0500, David Engel wrote:
> > I've since written a filter to preprocess the HTML and remove the
> > extra formatting before passing it to w3m.  The traditional PGP coming
> > out of w3m is now properly formatted.  Alas, Mutt doesn't recognize it
> > and automatically decrypt it.
> 
> I wonder if you could just forward that sanitized block to yourself as
> plain-text ... then mutt should deal with it just fine?
> 
> It would add 2-3 keystrokes and be miles away from elegant ... but if it
> works until you find a better solution...

I tried that and Mutt forwards the original email in tact.  Unless
there's another forward command that sends the decoded text (I didn't
find ont), I don't think it will work.

David
-- 
David Engel
da...@istwok.net


Re: Inline PGP Within HTML

2020-04-27 Thread David Engel
On Mon, Apr 27, 2020 at 12:32:05PM -0500, Derek Martin wrote:
> On Sat, Apr 25, 2020 at 09:46:48PM -0500, David Engel wrote:
> > Hi,
> > 
> > My company uses PGP/GPG when sending sensitive material through email.
> > Unfortunately (for them and me), most people use Outlook and our IT
> > guy refuses to install any Outlook plugin for them to properly handle
> > encypted emails.  
> 
> I know this doesn't really help you, but your real problem is you need
> to fire your IT guy.  As a former one myself, the role of IT should be
> to help users solve their legitimate business-need cases of technology
> issues, and yours has failed.  He needs to be taught that is job is to
> aid, not hinder, the business achieving its goals.

We are a small company ahd IT is only one of his many jobss along with
facilities, planning, project management and others.  He got IT
because nobody else was willing to do it.  The explanation I got for
not embracing an integrated, PGP solution was that he'd tried it
before and that it broke wheneve MS issued an update to Outlook.

> Barring that, you need to seek out those with enough political power
> to force your IT guy to do what you need, and convince them to do so.
> Everyone has a boss...  And if you lack access to those people, it's
> just a matter of finding someone you do have access to who does, who
> will sympathize, or at least empathize, and make your case for you.

I've shown an integrated solution to the two department heads
repsonsible for most of the users.  One of them is my boss.  The
problem is there is a lot of inertia behind the current, inefficient
way they do things.  Everyone knows it's a pain but they all no how to
do it and are reluctant to change.  To me, it's mind boggling how much
productivity is lost.  The text for each encrypted email must be
copied and pasted through the stand-alone PGP to encrypt of decrypt.
File attachements must be encrypted separately before sending and
saved and decrypted separately upon receipt.  It's crazy.

On Mon, Apr 27, 2020 at 01:46:26PM -0400, Scott Kostyshak wrote:
> On Mon, Apr 27, 2020 at 12:32:05PM -0500, Derek Martin wrote:
> > On Sat, Apr 25, 2020 at 09:46:48PM -0500, David Engel wrote:
> > > I've given up politely asking people to remember to send email as
> > > either both text/html and text/plain or just text/plain when sending
> > > to me.  It's a losing battle. :(
> 
> You've given up *politely* asking? Meaning you are now asking
> impolitely? :)

I do have to keep working with these people. :)

> > Yeah, I've been trying to explain this to some folks around here
> > recently, but not having much success.  You have my sympathy.
> 
> Agreed. It is frustrating. But Derek, please don't give up! Even in the
> worst case scenario, we can slow the acceleration. I especially take the
> time to choose the battles where the email is from an automated system.
> I contact the support and send something like the following:
> 
>   Could you please modify your automatic emails to also send a
>   plain-text version in addition to the HTML email? This is easy to do
>   and most professional emails provide a plain text version (this is
>   called multi-part MIME).
>  
>   If this doesn't make sense to you, please forward this request to your
>   tech team.
> 
>   Thanks for your time!

I have essentially done this but the problem keeps reoccurring.  I
think part of the problem might be Outlook itself.  I vaguely recall
seeing something about Outlook only sending both text/plain and
text/html when those are the only two parts.  If another attachment is
included, I seem to recall that one of the text parts got dropped.  I
could be wrong, though.

I'm considering trying the polite approach again but this including
the pointer to the integrated solution I tested.  Maybe I can start
the change from the bottom up.

David
-- 
David Engel
da...@istwok.net


Re: Inline PGP Within HTML

2020-04-27 Thread Akkana Peck
> > On Sat, Apr 25, 2020 at 09:46:48PM -0500, David Engel wrote:
> > > I've given up politely asking people to remember to send email as
> > > either both text/html and text/plain or just text/plain when sending
> > > to me.  It's a losing battle. :(

Since I don't have to deal with PGP, increasingly I wish people
would just send HTML and dispense with the text/plain. Lynx or
similar programs work fine inside mutt for HTML mail (if there isn't
too much fancy formatting), but if there's a text/plain part, more
and more often it's blank, garbled or just unreadable because it
lacks any line breaks.

Scott Kostyshak writes:
>   If this doesn't make sense to you, please forward this request to your
>   tech team.

I wish! But the "tech team" almost never has any idea what MIME
multipart/alternative is, and any attempt to convince them that
they're sending out garbled email just results in "It looks fine
to me and nobody else has complained."

In fact, out of many complaints about such problems, I don't think
I've *ever* gotten an answer like "Oh, thanks for letting me know,
I guess I never checked the plaintext part." It's been "looks fine
to me" every. single. time. And most of the time, no matter how many
times we go back and forth I can never manage to convince them even
that a text part exists, let alone that it's worth fixing.

...Akkana


Re: Inline PGP Within HTML

2020-04-27 Thread Scott Kostyshak
On Mon, Apr 27, 2020 at 12:32:05PM -0500, Derek Martin wrote:
> On Sat, Apr 25, 2020 at 09:46:48PM -0500, David Engel wrote:
> > I've given up politely asking people to remember to send email as
> > either both text/html and text/plain or just text/plain when sending
> > to me.  It's a losing battle. :(

You've given up *politely* asking? Meaning you are now asking
impolitely? :)

> Yeah, I've been trying to explain this to some folks around here
> recently, but not having much success.  You have my sympathy.

Agreed. It is frustrating. But Derek, please don't give up! Even in the
worst case scenario, we can slow the acceleration. I especially take the
time to choose the battles where the email is from an automated system.
I contact the support and send something like the following:

  Could you please modify your automatic emails to also send a
  plain-text version in addition to the HTML email? This is easy to do
  and most professional emails provide a plain text version (this is
  called multi-part MIME).
 
  If this doesn't make sense to you, please forward this request to your
  tech team.

  Thanks for your time!

Best,

Scott


Re: Inline PGP Within HTML

2020-04-27 Thread Derek Martin
On Sat, Apr 25, 2020 at 09:46:48PM -0500, David Engel wrote:
> Hi,
> 
> My company uses PGP/GPG when sending sensitive material through email.
> Unfortunately (for them and me), most people use Outlook and our IT
> guy refuses to install any Outlook plugin for them to properly handle
> encypted emails.  

I know this doesn't really help you, but your real problem is you need
to fire your IT guy.  As a former one myself, the role of IT should be
to help users solve their legitimate business-need cases of technology
issues, and yours has failed.  He needs to be taught that is job is to
aid, not hinder, the business achieving its goals.

Barring that, you need to seek out those with enough political power
to force your IT guy to do what you need, and convince them to do so.
Everyone has a boss...  And if you lack access to those people, it's
just a matter of finding someone you do have access to who does, who
will sympathize, or at least empathize, and make your case for you.

> I've given up politely asking people to remember to send email as
> either both text/html and text/plain or just text/plain when sending
> to me.  It's a losing battle. :(

Yeah, I've been trying to explain this to some folks around here
recently, but not having much success.  You have my sympathy.

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



signature.asc
Description: PGP signature


Re: Inline PGP Within HTML

2020-04-27 Thread David Engel
On Sun, Apr 26, 2020 at 11:31:36AM -0700, Kevin J. McCarthy wrote:
> On Sun, Apr 26, 2020 at 01:15:26PM -0500, David Engel wrote:
> > Thanks for the tip.  Mutt still doesn't recognize the PGP block,
> > however. :( That's not surprising.  It probably doesn't check the
> > processed output because no sane person would wrap a PGP block in
> > HTML!
> 
> Yes, sorry that's right.  Mutt doesn't check autoview output - it's rendered
> and that's it.  Perhaps the pipe you wrote could filter and generate a new
> message (in a temporary mailbox) of content-type text/plain.

How about a utiltiy that takes the text/html part, formats it as text
and then replaces it with a multipart/atlternative containg both the
original text/html and the new text/plain.  Even better if Mutt could
do that itself.

In the for what it's worth department.  I rechecked using Gpg4Win with
Outlook.  It's the solution for Windows/Outlook users that I
previoulsy pushed.  It handled the HTML-encapsulated PGP block just
fine.

David
-- 
David Engel
da...@istwok.net


Re: Inline PGP Within HTML

2020-04-26 Thread Kevin J. McCarthy

On Sun, Apr 26, 2020 at 01:15:26PM -0500, David Engel wrote:

Thanks for the tip.  Mutt still doesn't recognize the PGP block,
however. :( That's not surprising.  It probably doesn't check the
processed output because no sane person would wrap a PGP block in
HTML!


Yes, sorry that's right.  Mutt doesn't check autoview output - it's 
rendered and that's it.  Perhaps the pipe you wrote could filter and 
generate a new message (in a temporary mailbox) of content-type 
text/plain.


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature


Re: Inline PGP Within HTML

2020-04-26 Thread David Engel
On Sun, Apr 26, 2020 at 11:59:43AM +0200, Jens John wrote:
> On Sat, Apr 25, 2020 at 09:46:48PM -0500, David Engel wrote:
> > IT guy refuses to install any Outlook plugin for them to properly
> > handle encypted emails.
> 
> Outlook has pretty comprehensive, native support for encrypting and
> signing with S/MIME. Perhaps your IT guy would be more open to just
> using a well-documented Outlook feature? As mutt has support for S/MIME
> too, this might be much more workable than insisting on PGP.

I've suggested that before.  A few of us even had to use S/MIME for a
while when a customer required us to.  Basically, it boils down to
inertia.  PGP already works (for their definition of works) so why
change.

David
-- 
David Engel
da...@istwok.net


Re: Inline PGP Within HTML

2020-04-26 Thread David Engel
On Sun, Apr 26, 2020 at 09:13:59AM +0100, Dave Woodfall wrote:
> On 2020-04-26 08:04,
> Dave Woodfall  put forth the proposition:
> > On 2020-04-25 21:46,
> > David Engel  put forth the proposition:
> > > Hi,
> > >
> >
> > Elinks[1] has an option to `compress-empty-lines'.  Other than that
> > perhaps piping the -dumped text through cat -s or --squeeze-blank
> > might work - e.g. `w3m -dump | cat -d ...'
> >
> > [1] http://elinks.or.cz/index.html
> 
> Oops, I meant: `w3m -dump | cat -s ...'

Thanks for the tip.  Mutt still doesn't recognize the PGP block,
however. :( That's not surprising.  It probably doesn't check the
processed output because no sane person would wrap a PGP block in
HTML!

David
-- 
David Engel
da...@istwok.net


Re: Inline PGP Within HTML

2020-04-26 Thread Jens John
On Sat, Apr 25, 2020 at 09:46:48PM -0500, David Engel wrote:
> IT guy refuses to install any Outlook plugin for them to properly
> handle encypted emails.

Outlook has pretty comprehensive, native support for encrypting and
signing with S/MIME. Perhaps your IT guy would be more open to just
using a well-documented Outlook feature? As mutt has support for S/MIME
too, this might be much more workable than insisting on PGP.


Re: Inline PGP Within HTML

2020-04-26 Thread Dave Woodfall
On 2020-04-26 08:04,
Dave Woodfall  put forth the proposition:
> On 2020-04-25 21:46,
> David Engel  put forth the proposition:
> > Hi,
> >
>
> Elinks[1] has an option to `compress-empty-lines'.  Other than that
> perhaps piping the -dumped text through cat -s or --squeeze-blank
> might work - e.g. `w3m -dump | cat -d ...'
>
> [1] http://elinks.or.cz/index.html

Oops, I meant: `w3m -dump | cat -s ...'



Re: Inline PGP Within HTML

2020-04-26 Thread Dave Woodfall
On 2020-04-25 21:46,
David Engel  put forth the proposition:
> Hi,
>
> My company uses PGP/GPG when sending sensitive material through email.
> Unfortunately (for them and me), most people use Outlook and our IT
> guy refuses to install any Outlook plugin for them to properly handle
> encypted emails.  Consequently, I receive such sensitive material as
> traditional, PGP which the Outlook users have copied and pasted the
> output from PGP into the email.  They have to copy and paste the other
> direction through PGP when they receive encrypted email.
>
> When the traditional PGP is sent to me as text/plain, Mutt handles it
> just fine automatically and I silently laugh at the hoops the Outlook
> users have to jump through to send and receive encrypted email.
> However, after a recent Outlook upgrade/reinstall, I now frequently
> receive the traditional PGP as text/html.  Mutt doesn't recognize the
> traditioinal PGP after after the entire html part gets sent through
> w3m as directed by my .mailcap.  I've given up politely asking people
> to remember to send email as either both text/html and text/plain or
> just text/plain when sending to me.  It's a losing battle. :(
>
> Anyway, I'd hoped the unrecognition of the traditional PGP in HTML was
> due to the formatting done by w3m.  Outlook adorns the pssted in text
> with additional  and  tags that cause w3m to double-space the
> output making it look like the following.  Links2 does the same thing.

Elinks[1] has an option to `compress-empty-lines'.  Other than that
perhaps piping the -dumped text through cat -s or --squeeze-blank
might work - e.g. `w3m -dump | cat -d ...'

[1] http://elinks.or.cz/index.html