SendableMsg.create should have more specific methods for s/mime etc

[tomholub]

Would be good to eventually have a specialized method like createSmimeEncrypted etc that would not have all the noise.

Originally posted by @tomholub in #3123 (comment)

[tomholub]

Here these uses:

Maybe once you add the more specific methods, you could make SendableMsg.create a private method only used internally.

[vnikolaou]

Hi @tomholub ,

I am taking a look again inside the sendableSimpleTextMsg() method that we refactored. Take a look in the openpgp part:

if (x509certs.length) { // s/mime
...
...
      const body = { "encrypted/buf": Buf.fromUint8(encryptedMessage.data) };
      return await SendableMsg.create(this.acctEmail, { ...this.headers(newMsg), body, type: 'smimeEncrypted', atts: [], isDraft: this.isDraft });
    }
    // openpgp
    const atts: Att[] = this.isDraft ? [] : await this.view.attsModule.attach.collectEncryptAtts(pubs);
    const { data: encryptedBody, type } = await this.encryptDataArmor(Buf.fromUtfStr(newMsg.plaintext), undefined, pubs, signingPrv);
    const mimeType = type === 'smime' ? 'smimeEncrypted' : undefined;
    return await SendableMsg.create(this.acctEmail, { ...this.headers(newMsg), body: { "encrypted/buf": Buf.fromUint8(encryptedBody) }, type: mimeType, atts, isDraft: this.isDraft });

We may still pass type='smimeEncrypted' + encrypted/buf in body (as in smime case). Regardless of how this later can be processed.. is it normal to pass smime type for openpgp??
I am asking because this part also has a SendableMsg.create and looks weird.

[vnikolaou]

Also the current cases for the SendableMsg's type are:

• smimeEncrypted
• pgpMimeEncrypted
• pgpMimeSigned
• undefined

The SendableMsg.toMime() seems to be supporting directly the smimeEncrypted and pgpMimeSigned types.
For the other 2 (pgpMimeEncrypted, undefined) executes the same code (undefined case) . I assume the the pgpMimeEncypted related code doesn't use the toMime() method hence no bug probably, but it is weird.

I'll create a draft PR with the methods. There are 6-7 methods where 2-3 parameters may be present or not. Naming these methods is more difficult :) I would say because for some of them there is no clear context to give a good name.

[tomholub]

We may still pass type='smimeEncrypted' + encrypted/buf in body (as in smime case). Regardless of how this later can be processed.. is it normal to pass smime type for openpgp??
I am asking because this part also has a SendableMsg.create and looks weird.

I think this is an oversight from our refactoring, and should be removed. There is no smimeEncrypted type in openpgp messages.

[vnikolaou]

Do you believe that this oversighted part should have type = undefined or pgpMimeEncrypted ? At least SendableMsg.toMime() seems to be handling them both as the same thing.

[tomholub]

just undefined - to leave the behavior unchanged

[vnikolaou]

@tomholub , pls. check again. The names are renamed and i think the abstraction over methods is much better. Actually for the latter I just created a basic signature:

async (
     acctEmail: string,  
     headers: SendableMsgHeaders, 
     body: SendableMsgBody, 
     attachments: Att[], 
    options: SendableMsgOptions
): Promise<SendableMsg>;

.. and based on (new) method name the inner implementation may change a bit per case. Also for a couple of methods the options (new custom type combining the original type and isDraft parameters) parameter may be optional.

[vnikolaou]

Note:.. when we are ready i'll remove the numerous inline comments ..