K-9: new / extended option: show mail source

[Thomas--F]

Hi,
sometimes I get mails that look dubious. The best way to find out if they are spam oder phishing-mails is to check the mail-header and look into the mail-source for cloaked links.

Is it easy possible, to make a new option "show mail source" or extend the option "show mail header"?

[alanthehat]

Should this be available from folder view to avoid triggering #1067 & similar?

[metastork]

Not OP here, obviously, but this might be slightly useful as simply an option in the message view window, alongside the 'view attachment' button, for instance.

[Thomas--F]

That's just what I wanted...

[sofar]

Seconded. Headers can contain spoofed sender addresses, so often the difference between legit mail and phishing is the malicious link URL, and there's no way to inspect it right now.

[Valodim]

This should be relatively simple to implement, now that we actually have the source in the db. Just open an activity, load the message, write it to a string and display :)

[cketti]

Or we could be more clever about it and not try to display base64-encoded 10MB attachments in a TextView :)

[Djfe]

an additional suggestion:
add a checkbox or so, that only shows part of the source code that was filtered by the sanitization algorithm. (even attributes without the tag name, but separated into lines: everything there is something that's not sanitized, add a new line)

[cketti]

Since I work on an email app I use the "show source" functionality of my desktop email client quite a lot. However, I find most of the time it's not as useful as it could be. All email apps I've looked at display the raw message data. This is good enough for looking at the headers fields. But it's not great for looking at the message body, or rather body parts (since most messages are MIME multipart messages nowadays).

I think we can do better. My idea for a "show source" screen is the following:

• Show raw headers fields at the top; use bold for the header names (like the current "show headers" feature does). See #4504.
• Display a tree of MIME parts below the header; here only basic information per part should be displayed (content type, name [if available], size?), e.g.
  multipart/mixed ├ multipart/alternative │ ├ text/plain │ └ multipart/related │ ├ text/html │ └ image/jpeg └ application/pdf [attachment.pdf]
• Clicking one of the parts would open a new "show source" screen for just that part. If it's a multipart element, the sub tree of body parts is displayed below the header of the body part. If it's a leaf node, the encoded body is displayed below the header.
• I would also like to have a way to strip the transport encoding for text/* parts if present. If there's no transport encoding or it was stripped by request of the user, we should also use the charset argument to properly decode the text.
• Saving the raw message to storage (see issue #1498) is a feature that I think would be a good fit for such a "show source" screen. The action can be put into the toolbar's (overflow) menu.
• Users should be able to select parts of the header or the body text and copy it to the clipboard

These are quite a lot of features. Not all of this has to be implemented at once. In fact I strongly recommend to do it in steps as small as possible.

Some more things to consider:

• Interesting header values are likely encoded. We might want to add a way to view the decoded value of well-known headers.
• Encrypted parts need to be decrypted.
• We might not have a full copy of the message locally. So the full message has to be downloaded first. This might also fail, e.g. when there's no connectivity. In that case we need to decide whether we want to show the partial data we have (and a message letting the user know it's only partial data) or an error message.