Forwarding

[frasertweedale]

Is your feature request related to a problem? Please describe.
Need to be able to forward messages. Should go to compose view with forwarded message as attachment.

Describe the solution you'd like
Messages should be forwarded as-is, i.e. the content on disk, not serialising the parsed data.

Describe alternatives you've considered
It's a baseline feature.

[frasertweedale]

Note: bouncing is a similar category but bit different from user POV and may need some changes to mailer API (i.e. to explicitly specify SMTP recipient(s) instead of deriving them from the mail).

[romanofski]

I think for bounce we need a separate card.

[frasertweedale]

Bounce: #315.

[romanofski]

I've played around with this a bit. It is actually a very simple patch, except perhaps the creation of the attachment from a MIMEMessage. At the moment purebred-email provides functions to create attachments from ByteStrings or a FilePath. Would it make sense to provide a function to create an attachment from a MIMEMessage too?

[frasertweedale]

@romanofski it's a common enough use case that it makes sense to have a shortcut to "lift" a MIMEMessage into an attachment with the correct Content-Type etc. I'll put something into purebred-email.

[frasertweedale]

@romanofski see purebred-mua/purebred-email@f98ea3e for construction.

I'm considering whether to change the structure of MIMEMessage to make encapsulation first class, and forcibly parse the inner message during parsing. There are advantages and disadvantages:

• advantage: from user POV, nested structure is first class and can access the part(s) of the encapsulated message via the usual folds.

• disadvantage: a unparsable encapsulated message results in whole message being unparseable.

What are your thoughts?

update see purebred-mua/purebred-email@60b45ae for what it looks like with dedicated constructor.

[romanofski]

Hm.. the disadvantage reads like a deal breaker. Would that mean that messages which are a little bit stuffed and up in purebred as not displayable? If that is the case I would vote for not doing it. Given the amount of bad emails, I think we do need a bit of leeway when it comes to errors in the format.

Having a look at your patch tho, it doesn't look as bad. Not sure if I got something wrong.

[frasertweedale]

@romanofski I like the usability too much now that i coded it up. I reckon I can split the difference and fall back to 'Part' if parsing the encapsulated message fails, or maybe another constructor that indicates "Failed to parse encapsulated message".

I'm also going to remove the 'forward' terminology, the RFC talks about "encapsulation", with forwarding being an application of such.

[frasertweedale]

Basically, we want to parse as much of the structure as we can, and indicate "dead branches" as such, instead of felling the whole tree :D

[romanofski]

Ah that's a great idea!!