Hi,
On 2022-03-26 18:41:39 +0100, Magnus Hagander wrote:
> That said, it's not as simple as a upper/lowercase. get_content_type()
> returns 'text/plain' in lowercase for both parts so it takes care of
> that.
>
> The problem is that:
> 1. It's not an attachment. That is:
> Content-Disposition: inline; filename="0001-doc_wip-diff.txt"
> explicitly says it's not an attachment.
It's not actually that unreasonable for a doc patch ;)
> 2. We only show the first plaintext part of messages
>
> This is the actual problem. Our archives don't know how to merge
> multiple plaintext parts when they are set to be viewed inline and not
> as attachments.
>
> That said, I notice that it's shown as an attachment in gmail as well,
> even though it's not an attachment. I have no idea why :)
The archive code appears to actually try to handle the case of multiple inline
plain text attachements, from what I can see:
https://git.postgresql.org/gitweb/?p=pgarchives.git;a=blob;f=loader/lib/parser.py;hb=HEAD#l381
381 # If we have already found one text/plain part, make all
382 # further text/plain parts attachments
383 if self.attachments_found_first_plaintext:
So there's something more than just the content-disposition: inline; going on
I think?
> MIME parsing in general is black magic, but in this case it seems pretty
> clear that showing it as an attachment is plain wrong. Not showing it at
> all, however, is also wrong, but I'm not sure how much complexity it's worth
> to handle this case, given it's the first time I've heard of the problem.
I'm not sure we'd really notice. I dimly recall encountering something like
this before and somebody else complaining about it.
Greetings,
Andres Freund