feat: added a possibility to use sendmail as a transport

[arkotik]

No description provided.

[dword-design]

@arkotik This looks more like you want to have multiple transports, not that you want sendmail specifically, right? Maybe we should go into this direction instead. Then we also don't need a specialized sendmail test. What would be the use case to have multiple transports? You could just configure sendmail via the smtp config, right?

[arkotik]

@dword-design I am using Postfix in production and SMTP (Mailtrap) in the dev mode. So I added this feature to make the configuration clearer. If you don't care whether any transport other than SMTP works or not, I can remove the test for the sendmail transport. By the way, this test was passed successfully.
I am also aware that I can pass the sendmail options to the SMTP config and this will work, as there is no strict typing or validation of config parameters. But such usage looks weird to me.

smtp: {
    sendmail: true,
    newline: 'unix',
    path: '/usr/sbin/sendmail',
    secure: true,
},

Doesn't this look better?

transport: process.env.MAIL_TRANSPORT,
smtp: {
    host: process.env.SMTP_HOST,
    port: process.env.SMTP_PORT,
    auth: {
        user: process.env.SMTP_USER,
        pass: process.env.SMTP_PASS,
    },
},
sendmail: {
    sendmail: true,
    newline: 'unix',
    path: '/usr/sbin/sendmail',
    secure: true,
},

[dword-design]

@arkotik Ok yeah I basically use process.env.MAIL_CONFIG and JSON.parse(process.env.MAIL_CONFIG) to pass it to Nuxt. This way it's up to the env file if it's sendmail or not. I get the point that it is not fixed typing, but nodemailer also works like it and I'd like to stick to the nodemailer schema 🙂. So using a JSON, or preparing the env variables and then build a mail config object from them depending on the type would be the way to go I guess.