Revert "Set missing filename to rfc822_email.eml..
3a1614bf140c
Actions

Description

Revert "Set missing filename to rfc822_email.eml..

This reverts commit 0d16049d41e052ea9b5d7a7878ece3d02a182161.

Since this fix only prints a static filename when an
enacapsulated message is detected but does neither parase the
mail nor fill it with the complete data it is better to
leave it out for a bugfix release as this only creates
more problems then it solves. The encapsulated message part
needs to be eihter completely cut out from our parser and
treated as a MAPI attachment or ignored if we do not support
it.

Details

Provenance

• aheinecke

Authored on Aug 21 2024, 1:56 PM

Parents

rO20f8e69972c0: Update NEWS.

Branches

Unknown

Tags

Unknown

Reverts

rO0d16049d41e0: Set missing filename to rfc822_email.eml for message/rfc822 attachments

Event Timeline

• aheinecke committed rO3a1614bf140c: Revert "Set missing filename to rfc822_email.eml.. (authored by • aheinecke).Aug 21 2024, 2:00 PM

• aheinecke added a reverted change: rO0d16049d41e0: Set missing filename to rfc822_email.eml for message/rfc822 attachments.Aug 21 2024, 2:25 PM

Having a filename even for a bad or empty attachment is a Good Thing™ for the support desk. I also see no regression risk here.

In my opinion it is better to say-> GpgOL does not handle encapsulated mails and don't show anything. Then to now create a new behaviour where something is shown but that something is broken. If we "close" the original "no attachments are shown" issue, do I as a user now have to create a new support issue with "there is a file named rfc822_email.eml shown but it is empty"? So there is another round of communication about this issue while the problem is not solved. This way we can just say that a fix for handling embedded mails in crypto mails did not make it into the 2.5.13 release. Then to create a new state where the feature is broken differently.
Users would then ask themself: If the mail is empty, is it because my mail is somewhat special, etc?

Of course I would prefer to have a proper fix for this. But right now we do not have one written out.

Most users are able to read and in particular to answer the question: Do you see the text "rfc822-email"? Try to ask them whether they see a white box somewhere. Nearly impossible w/o a screenshot and even then you get wrong answers. The whole issue is about helping our support people. YMMV

I was not expecting a controversy about the reversion as I already said in the weekly on monday that I think we should rather revert that then try to fix it for a 3.2.3 release.

My intention is especially not to create more confusion for the smart people who reported this, because at least when I see in a software that an issue of mine has been addressed, I would expect it that works under some circumstances and that my individual case must then be special and dig deeper into the analysis. Since I would not expect a Software publisher to show something unsupported without a hint that it is unsupported but with broken results. Imagine the person originally reporting this now sees this rfc822_email.eml, Then he will open the email in an editor and notice that only the headers are included in there, he will understand that this is broken and could not have worked and will ask himself "has no one ever tested this" as we do not indicate that the attachment is incomplete.

It has always been usual for us to hide features which are not fully implemented when we know it is not leading to the results a user expects.