Re: [nmh-workers] Change {encrypted} to %(encrypted) in mh-format
Date:Thu, 16 May 2019 23:10:32 -0400 From:Ken Hornstein Message-ID: <20190517031033.54569150...@pb-smtp2.pobox.com> I view the "original MH" as more like the HDTV ads - we can do it (except they couldn't) so let's advertise... Not worth keeping. | Second ... encrypted messages are a little bit different than all other | messages is that they are an encapsulating type, where you have to decode | it to get the "true" mime type, Yes. | and that decoding may require some sort of user interaction, Doing almost anything with e-mail requires some sort of user interaction, that's what nmh is all about - the means of interacting. Parsing scan listings to decide what to do for something automated is entirely the wrong approach - anything doing that should be looking at the actual messages, not the extract made by scan. | so you may very well want handle them differently. Very possibly - I handle spam differently as well, but we have no scan listing indicator for that one (even when spamassassin has added a field to say the message is (probably) spam). | It's fair to point out that we don't know what a potential %(encrypted) | function escape should necessarily do just yet; I am just thinking ahead. Sure, but it is more than what it does, but what it affects. Sticking in an empty function, and then using it as if it was a "does this field exist" predicate (though not looking in the header for the info) might turn out to be counter productive. Better to design the function first (if we ever need one) and then use it appropriately later. | I'll let you and Valdis fight THAT one out :-) Pistols at dawn? Ah no, SPAM attacks! But no, no need to fight - that users can configure things to suit local desires is what MH is all about. If being able to spot HTML format mail (I assume so it can simply be removed...) is useful to Valdis, then that's fine. (I read his message after I sent my previous reply.) kre ps: in MH land, it would be really nice if we could use the terminology correctly, and remember that e-mail has exactly one header, which contains several fields (some mandatory, some optional) and use the correct terms when referring to each. -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Change {encrypted} to %(encrypted) in mh-format
>However I wonder at the rationale for including this info in the >scan format at all. We don't print 'M' if the message is MIME >encoded, and we don't print 'F' if there's a face header, and nor >do we print 'A' if there are attachments - what's so special about >encrypyted that warrants this special treatment? Well, here are my thoughts on that subject. First, historical. The original MH people thought it was a good idea. That doesn't mean we have to continue that, but I was reluctant to just yank something out without a replacement. Second ... encrypted messages are a little bit different than all other messages is that they are an encapsulating type, where you have to decode it to get the "true" mime type, and that decoding may require some sort of user interaction, so you may very well want handle them differently. It's fair to point out that we don't know what a potential %(encrypted) function escape should necessarily do just yet; I am just thinking ahead. >Note that 'E' in the format is different to the alternate annotations >that can occur in the same position (and trump the E if more than one >applies) in that the others tell what I have done to the message >(that I have replied, or forwarded it) - which is useful information >to have in the scan listing. Random extracts related to content type >is not. I'll let you and Valdis fight THAT one out :-) --Ken -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Change {encrypted} to %(encrypted) in mh-format
Date:Thu, 16 May 2019 20:56:28 -0400
From:Ken Hornstein
Message-ID: <20190517005629.c904f14f...@pb-smtp2.pobox.com>
| People with their own scan formats would see no change, except that they'd
| have to change at some point in the future when we supported encrypted
| email properly. Thoughts? I'd like to do this for 1.8.
No objections to the change (I am one with my own scan formats .. I
have several).
However I wonder at the rationale for including this info in the
scan format at all. We don't print 'M' if the message is MIME
encoded, and we don't print 'F' if there's a face header, and nor
do we print 'A' if there are attachments - what's so special about
encrypyted that warrants this special treatment?
To me it smells of the way that the TV stations advertise HD (or
now UHD or HD4000 or whatever they call it) - not because anything
is actually different in the (mostly gibberish) content, but because
they have spent a bunch of money and effort upgrading to support
better quality, and they want to make sure that everyone knows about
that.
What I'd do is simply remove the $?{encrypted} stuff from the scan
formats, and leave it at that for now.
If there's ever a useful function to be served by a %(encrypted)
function, it can be added later, when we know what that purpose is,
and what the function should do to best satisfy the requirement.
Note that 'E' in the format is different to the alternate annotations
that can occur in the same position (and trump the E if more than one
applies) in that the others tell what I have done to the message
(that I have replied, or forwarded it) - which is useful information
to have in the scan listing. Random extracts related to content type
is not.
kre
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Change {encrypted} to %(encrypted) in mh-format
>Probably need to be a bit more ambitious than that, and MIME-compliant. Well, here's my thinking. The generic concept of encrypted email is always going to require some special handling, since you have to unpack it to do things like search in it or get the inner MIME structure. And there are several MIME types that fall under the "encrypted" banner; it seems like PGP has coalesced around multipart/encrypted (I know there were others in the past), I get S/MIME email that uses application/pkcs7-mime. "Signed" email seems to mostly use multipart/signed but it seems like that can also be application/pkcs7-mime. So what I am saying is, "Instead of the current use of the Encrypted header, which does nothing, at least switch it to an abstract function which will also do nothing but will hopefully do something in the future". Does that make sense? --Ken -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Change {encrypted} to %(encrypted) in mh-format
On Thu, 16 May 2019 20:56:28 -0400, Ken Hornstein said:
> It occur to me that this might still be useful, but making this switch
> on a component is obviously wrong, and it should really be a function
> escape. So I propose we switch all of the default scan formats from
> using %{encrypted} to a yet-to-be-written function escape %(encrypted).
> Since we don't really support encrypted email yet, this would always
> return false for now, but this would be a much better solution for future
> support rather than relying on a nonexistent header.
Probably need to be a bit more ambitious than that, and MIME-compliant.
What I have in my own scan file:
%(void{content-type})\
%<(match text/plain) \
%?(match text/html)H\
%?(match multipart/signed)S\
%?(match multipart/encrypted)E\
%|%<{content-type}M%|?%>%> \
although now that the vast majority of stuff is multipart/alternative with
a text/plain and text/html, retiring the M may make sense. I'm amazed at
how often I still see an 'H' or a '?' though. :)
pgpONYhqhoXYG.pgp
Description: PGP signature
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
[nmh-workers] Change {encrypted} to %(encrypted) in mh-format
I suspect most people may not be aware, but all of the scan formats that
are shipped with nmh will output an 'E' in one column if the email is
encrypted (in theory).
What actually happens is ... well, obviously this doesn't work. I guess
there was prototype encrypted email system that was never shipped in nmh,
but relied on a "Encrypted" header (see docs/trusted.pdf for some info
about it), and what the scan format actually does is print the 'E' in
the scan format if it sees the Encrypted header, which nobody uses so
you never see it.
It occur to me that this might still be useful, but making this switch
on a component is obviously wrong, and it should really be a function
escape. So I propose we switch all of the default scan formats from
using %{encrypted} to a yet-to-be-written function escape %(encrypted).
Since we don't really support encrypted email yet, this would always
return false for now, but this would be a much better solution for future
support rather than relying on a nonexistent header.
People with their own scan formats would see no change, except that they'd
have to change at some point in the future when we supported encrypted
email properly. Thoughts? I'd like to do this for 1.8.
--Ken
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
