I have used Pine/Alpine on Slackware for many years. Recently I tried
setting up S/MIME for encrypting email content on Alpine 2.22. It is
currently working fine when sending and receiving emails but there is
one thing I would like to change.

When I open an encrypted message in Alpine, it is decrypted fine but
after saving it, if I open the saved-messages folder with Pico, it
appears that any encrypted email is still encrypted. This leads me to
believe that encrypted email is decrypted each time it is opened rather
than only the first time. Is there a way of saving an encrypted email
after reading it in its decrypted form?

In my particular instance, it would be nice to have the email encrypted
in transit but once it arrives, I would like to save it in readable
form. I do not want to have worry about maintaining a particular key
over the long term just so I can go back and read past emails.

If I failed to see how to do that by configuration, my apologies.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 30 Dec 2020, NotReal wrote:

When I open an encrypted message in Alpine, it is decrypted fine but
after saving it, if I open the saved-messages folder with Pico, it
appears that any encrypted email is still encrypted. This leads me to believe that encrypted email is decrypted each time it is opened rather
than only the first time. Is there a way of saving an encrypted email
after reading it in its decrypted form?

In my particular instance, it would be nice to have the email encrypted
in transit but once it arrives, I would like to save it in readable
form. I do not want to have worry about maintaining a particular key
over the long term just so I can go back and read past emails.

Alpine saves every message as received from the server (or as it was when
it was delivered). Saving it unencrypted would mean to rewrite the headers
of the message which contain information on the structure of the message.
I would try forwarding the message (which could preserve the attachments,
etc.) and not exporting, which will only save what you see in the screen,
and not the attachments.

--
Eduardo
https://tinyurl.com/yc377wlh (web)
http://repo.or.cz/alpine.git (Git)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Eduardo Chappa wrote:

On Wed, 30 Dec 2020, NotReal wrote:

When I open an encrypted message in Alpine, it is decrypted fine
but after saving it, if I open the saved-messages folder with
Pico, it appears that any encrypted email is still encrypted.
This leads me to believe that encrypted email is decrypted each
time it is opened rather than only the first time. Is there a way
of saving an encrypted email after reading it in its decrypted
form?

In my particular instance, it would be nice to have the email
encrypted in transit but once it arrives, I would like to save it
in readable form. I do not want to have worry about maintaining a particular key over the long term just so I can go back and read
past emails.

Alpine saves every message as received from the server (or as it was
when it was delivered). Saving it unencrypted would mean to rewrite
the headers of the message which contain information on the structure
of the message. I would try forwarding the message (which could
preserve the attachments, etc.) and not exporting, which will only
save what you see in the screen, and not the attachments.

Thanks for replying.


Based on your suggestion, I tried forwarding the email to myself and
then saving it. I found that the content of the email was indeed saved
as clear text, but I also found that the original header information
was gone. I next tried displaying the header information before
forwarding so that it would be forwarded as an attachment and that did
preserve the original header information but it also preserved the
content of the email in encrypted form. It would appear that the
choice if you forward an encrypted email is to forward it decrypted
with no header information or with header information but still
encrypted. Is there another way of forwarding that saves the decrypted
content while preserving the header information that I am not
considering?



As an aside, it would be nice if there was another keystroke beside "s"
that would save the email in decrypted form with the header
information, i.e., saved in the form of a non encrypted email.

I understand that perhaps some parts of the header would only apply to
the encrypted form such as the DKIM information but perhaps it could be
saved with something like.

[ This message was originally encrypted so the header information
may not be accurate. ]

[ This message was cryptographically signed. ]



instead of

[ This message was encrypted. ]

[ This message was cryptographically signed. ]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 30/12/2020 06.25, NotReal wrote:

I have used Pine/Alpine on Slackware for many years. Recently I tried setting up S/MIME for encrypting email content on Alpine 2.22. It is currently working fine when sending and receiving emails but there is
one thing I would like to change.

When I open an encrypted message in Alpine, it is decrypted fine but
after saving it, if I open the saved-messages folder with Pico, it
appears that any encrypted email is still encrypted. This leads me to believe that encrypted email is decrypted each time it is opened rather
than only the first time. Is there a way of saving an encrypted email
after reading it in its decrypted form?

In my particular instance, it would be nice to have the email encrypted
in transit but once it arrives, I would like to save it in readable
form. I do not want to have worry about maintaining a particular key
over the long term just so I can go back and read past emails.

Export to file, then have a script convert it back to email appended to
mbox folder?

I have not thought out how to do that script, it is just a wild idea.



--
Cheers, Carlos.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 31 Dec 2020, Carlos E.R. wrote:

Export to file, then have a script convert it back to email appended to
mbox folder?

The problem with export is that it will miss ALL attachments in the
message, and it is just a copy of what you see in the screen, so this
might not work as intended.

The issue with forwarding is the limited amount of headers you get, but
those are the same headers you would see when you read an email, so there
is no middle ground here.

The problem, from a technical point of view, is that the original mesage
has a specific content-type that is specific, and it says the message is encrypted. That determines how the message is handled. One cannot say a
message is one way, and then handle it in a different way. What the
original poster would like to do is to save a copy and make a change in
the headers of message at the same time (which technically would not make
it a copy, but a new message)

The headers that appear in a forwarded are the same that appear in the
display when you open a header, so if new headers are wanted to appear in
the forwarded message, then new headers have to be added to the display of every message, and this also causes an inconvenience, bigger than the one
it is solving.

I do not see a good compromise here...

--
Eduardo
https://tinyurl.com/yc377wlh (web)
http://repo.or.cz/alpine.git (Git)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Eduardo Chappa wrote:

On Thu, 31 Dec 2020, Carlos E.R. wrote:

Export to file, then have a script convert it back to email
appended to mbox folder?

The problem with export is that it will miss ALL attachments in the
message, and it is just a copy of what you see in the screen, so this
might not work as intended.

The issue with forwarding is the limited amount of headers you get,
but those are the same headers you would see when you read an email,
so there is no middle ground here.

The problem, from a technical point of view, is that the original
mesage has a specific content-type that is specific, and it says the
message is encrypted. That determines how the message is handled. One
cannot say a message is one way, and then handle it in a different
way. What the original poster would like to do is to save a copy and
make a change in the headers of message at the same time (which
technically would not make it a copy, but a new message)

The headers that appear in a forwarded are the same that appear in
the display when you open a header, so if new headers are wanted to
appear in the forwarded message, then new headers have to be added to
the display of every message, and this also causes an inconvenience,
bigger than the one it is solving.

I do not see a good compromise here...

Thanks again for taking the time to reply and explaining things. I do
not normally need encrypted email but I knew there would soon be a need
to communicate with a relative that involved financial information so
thought it was worth investigating. At this point however, I think
will live with non encrypted email and if there is something that I
feel really needs to be encrypted, I will use the telephone instead.

It is really too bad that with so many good ways to encrypt files at
rest that email encrypted for transit has to remain encrypted at rest
and tied to volatile certificates stored separately from the email. I
am guessing that is one reason why email encryption has not become more
popular for general use.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Carlos E.R. wrote:

On 30/12/2020 06.25, NotReal wrote:

I have used Pine/Alpine on Slackware for many years. Recently I
tried setting up S/MIME for encrypting email content on Alpine
2.22. It is currently working fine when sending and receiving
emails but there is one thing I would like to change.

When I open an encrypted message in Alpine, it is decrypted fine but
after saving it, if I open the saved-messages folder with Pico, it
appears that any encrypted email is still encrypted. This leads me
to believe that encrypted email is decrypted each time it is opened
rather than only the first time. Is there a way of saving an
encrypted email after reading it in its decrypted form?

In my particular instance, it would be nice to have the email
encrypted in transit but once it arrives, I would like to save it
in readable form. I do not want to have worry about maintaining a particular key over the long term just so I can go back and read
past emails.

Export to file, then have a script convert it back to email appended
to mbox folder?

I have not thought out how to do that script, it is just a wild idea.

Based on your comment I spent a couple of hours playing with the “saved messages” folder. My thought was a cron loop that would periodically
search for any saved email that was encrypted, isolate it, decrypt it,
and then insert it back into saved messages.

I had to solve a number of issues, such as working with very large line numbers, but I was able to come up with a bash script that would
isolate an encrypted email in one file, with all the prior emails in a
second file, and all subsequent emails in third file. I also managed
to decrypt the isolated email with openssl but found the resulting
decrypted file no longer had the header information.

In addition there were added lines before the email text along with
additional lines and the encrypted signature information after the text.

Worst of all, I found there was nothing consistent in the formatting of
the extra lines that would allow easy removal. It was a problem even
when it involved only two accounts on the same mail server with the
same email client. At that point I decided no matter how much time I
spent on the solution, I could never be sure that it would work in all
cases. A couple of hours wasted, but such is life. It was worth a
shot. Perhaps someone with more expertise then I have will come up
with something, Thanks for the thought.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 02/01/2021 21.18, William Unruh wrote:

On 2021-01-02, NotReal <NotReal@NoSpam.com> wrote:

Eduardo Chappa wrote:

On Thu, 31 Dec 2020, Carlos E.R. wrote:

am guessing that is one reason why email encryption has not become more
popular for general use.

Unfortunately safety and convenience are not really compatible. You have
to carry around house keys to get into yout home, rather than just being
able to open the door (or removing all the doors so that you can just
walk in).

Arguably, you can setup your door with a password and a keypad, so you
not need to transport anything.

However, if you do the same thing to email, a brute force attack will
find the password. They just need to try every password one after
another, and they have the time.

Doing the same at a door would be suspicious and very tedious.


If you want to send password protected email, just send password
protected PDFs. It is simple and cross-platform. My bank uses that.


--
Cheers, Carlos.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2021-01-02, NotReal <NotReal@NoSpam.com> wrote:

Eduardo Chappa wrote:

On Thu, 31 Dec 2020, Carlos E.R. wrote:

Export to file, then have a script convert it back to email
appended to mbox folder?

The problem with export is that it will miss ALL attachments in the
message, and it is just a copy of what you see in the screen, so this
might not work as intended.

The issue with forwarding is the limited amount of headers you get,
but those are the same headers you would see when you read an email,
so there is no middle ground here.

The problem, from a technical point of view, is that the original
mesage has a specific content-type that is specific, and it says the
message is encrypted. That determines how the message is handled. One
cannot say a message is one way, and then handle it in a different
way. What the original poster would like to do is to save a copy and
make a change in the headers of message at the same time (which
technically would not make it a copy, but a new message)

The headers that appear in a forwarded are the same that appear in
the display when you open a header, so if new headers are wanted to
appear in the forwarded message, then new headers have to be added to
the display of every message, and this also causes an inconvenience,
bigger than the one it is solving.

I do not see a good compromise here...

Thanks again for taking the time to reply and explaining things. I do
not normally need encrypted email but I knew there would soon be a need
to communicate with a relative that involved financial information so
thought it was worth investigating. At this point however, I think
will live with non encrypted email and if there is something that I
feel really needs to be encrypted, I will use the telephone instead.

It is really too bad that with so many good ways to encrypt files at
rest that email encrypted for transit has to remain encrypted at rest
and tied to volatile certificates stored separately from the email. I

Volitile? Why volitile? It is your public/private key. Just make sure
that you save it. Keep it in a safe and private place.

Remember that the most likely way for an "enemy" to get the message is
not by reading it in transit, but by breaking into your computer. Thus
that email in clear text on your computer is then completely open to the attacker.

Secondly, if you really want that clear text, just make an auxilliary
file containing the translation. Then the original, with all its header information and with the encrypted information is always there. And the translation is always available in that translated file.

However, it is clear that the safety of your relative's infomation is
way down the list of importance below your convenience.

am guessing that is one reason why email encryption has not become more popular for general use.

Unfortunately safety and convenience are not really compatible. You have
to carry around house keys to get into yout home, rather than just being
able to open the door (or removing all the doors so that you can just
walk in).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)