Is there any benefit in using client-sesv2 instead of client-ses? I don't have any plans to work on it myself, but if it is something that's really required, you could make a PR for it.

The SES v2 API supports e-mail messages up to 40MB in size. The v1 API only supports 10MB.
There's also support for Contact Lists, Suppression List Management and the Deliverability Dashboard.

I'll have a go at forking the project and adding it in with updated tests 👍

This issue is stale because it has been open for 30 days with no activity.

any update on this? thanks

any updates?

Still on my todo list, I'll pick it up this Thursday and submit the PR 👍

• Update the logical check here https://github.com/nodemailer/nodemailer/blob/master/lib/ses-transport/index.js#L262
• and make sure the data gets mutated into the v2 API format show in original comment
• Add new test(s) in here https://github.com/nodemailer/nodemailer/blob/master/test/ses-transport/ses-transport-test.js

This works for me:

import AWS from 'aws-sdk';
const MailComposer = require('nodemailer/lib/mail-composer');
import fs from 'fs';
const Mustache = require('mustache');

const ses = new AWS.SESV2({
  apiVersion: '2019-09-27',
  accessKeyId: process.env.AWS_ACCESS_KEY,
  secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY,
  region: process.env.AWS_REGION,
});

const isProduction = process.env.NODE_ENV === 'production';

const xxxTemplate = fs.readFileSync(`${__dirname}/xxx.template.html`, 'utf8').toString();

const generateRawMailData = (message) => {
  let mailOptions = {
    subject: message.subject,
    html: message.bodyHtml,
    attachments: message.attachments,
  };
  return new MailComposer(mailOptions).compile().build();
};

export default class NotificationsService {
  static sendEmail = async (to, cc, bcc, subject, params, attachments = [], from = 'info@xxx.io', templateId = 'xxx') => {
    if (!isProduction) {
      to = 'dev@xxx.io';
      cc = [];
      bcc = [];
    }
    let html = '';
    let template = xxxTemplate;
    if (params.plain) {
      html = params.body;
    } else {
      html = Mustache.render(template, { ...params });
    }

    const message = {
      subject,
      bodyHtml: html,
      attachments,
    };

    params = {
      Content: { Raw: { Data: await generateRawMailData(message) } },
      Destination: {
        ToAddresses: Array.isArray(to) ? to : [to],
        BccAddresses: Array.isArray(bcc) ? bcc : [bcc],
      },
      FromEmailAddress: from,
    };

    ses.sendEmail(params).promise();
  };
}

This issue is stale because it has been open for 30 days with no activity.

Hi, @adamprescott

Did you have time to dive in more in the code and make some changes?

This issue is stale because it has been open for 30 days with no activity.

Hi team 👋 . Very much waiting for this one. Any updates?

This issue is stale because it has been open for 30 days with no activity.

Looking forward to this one too

Just passing by, this would be handy 👍

This issue is stale because it has been open for 30 days with no activity.

Not stale

Any update on this? AWS has been moving away from SES v1. We also need to support large message size.

Any update on this?

SESV2 and SDK V3 are very different from the old SDK. It would require a lot of changes by the authors to catch up. I am able to use the new SDK with mimetext to send email with attachment via SESV2.

import {createMimeMessage} from 'mimetext';

This issue is stale because it has been open for 30 days with no activity.

Indeed, I'd still like to have a direct integration with SESv2. For now, the solution posted by @aymanmh is a fine alternative.

+1 - would love SES v2 support for AWS SDK v3 for 40mb file support.

@adamprescott Did you make any progress on the fork?

based on dyaacov comment above (old sdk), this works flawlessly for sdk v3:

import { SESv2Client, SendEmailCommand } from '@aws-sdk/client-sesv2';
import MailComposer = require('nodemailer/lib/mail-composer');

const sesv2Client = new SESv2Client({ region: process.env.AWS_REGION });
/* fill the mail options as usual , my email object looks like this
    {
        "from": {"name":"Sender", "address": "example_sender@example.com"},
        "text_body": "some text",
        "subject": "Email Subject",
        "to": [{"name":" A,B", "address":"example_sender@example.com"}],
        "cc": [{"address":"example_1@example.com"},{"address":"example_1@example.com"}],
    }
*/
const mailOptions = {
        from: email.from,
        subject: email['subject'] ? email.subject : '',
        html: email['html_body'] ? email.html_body : '',
        text: email['text_body'] ? email.text_body : '',
        to: email['to'] ? email.to : '',
        cc: email['cc'] ? email.cc : '',
        bcc: email['bcc'] ? email.bcc : '',
        attachments: hasAttachments ? email.attachments : [],
      };

const rawMailData = await new MailComposer(mailOptions).compile().build();

const input = {
          Content: {
            Raw: { Data: rawMailData },
          },
        };
const cmd = new SendEmailCommand(input);

const resp = await sesv2Client.send(cmd);

This worked well for us except for Bcc's. For some reason they got ignored by aws and were not sent. This was fixed by also defining the Destination attribute in addition to Content (though I decided to also set the FromEmailAddress and ReplyToAddresses attributes as well just in case after realizing this).

This issue is stale because it has been open for 30 days with no activity.

This issue was closed because it has been inactive for 14 days since being marked as stale.

Up

What do you think about exposing MailComposer as part of the package API?

import MailComposer = require('nodemailer/lib/mail-composer'); feels hacky, and there is no guarantee that MailComposer code won't change/move.

Based on @dyaacov comment, I adapted the code and it's working for me in a NestJS project. Sharing the code in case anyone needs it.

import { Injectable } from '@nestjs/common';
import * as AWS from 'aws-sdk';
import MailComposer from 'nodemailer/lib/mail-composer';
import { AttachmentObject } from 'nodemailer';
import logger from 'src/common/logger/logger.service';

@Injectable()
export class SESService {
  ses = new AWS.SESV2({ apiVersion: '2019-09-27' });

  async sendBatchEmails(
    files: { filename: string; buffer: Buffer }[],
    from: string,
    subject: string,
    text: string,
    emails: string[],
  ) {
    const attachments: AttachmentObject[] = files.map(
      ({ filename, buffer }) => ({
        filename,
        encoding: 'base64',
        content: buffer,
      }),
    );

    const mailOptions = {
      Content: {
        Raw: {
          Data: await this.generateRawMailData(subject, text, attachments),
        },
      },
      Destination: {
        ToAddresses: emails,
      },
      FromEmailAddress: from,
    };

    return new Promise<void>((resolve, reject) => {
      this.ses.sendEmail(mailOptions, (error, data) => {
        if (error) {
          logger.error(error);
          reject(error);
        } else {
          logger.info(`Email sent: ${data}`);
          resolve();
        }
      });
    });
  }

  generateRawMailData = (
    subject: string,
    text: string,
    attachments: AttachmentObject[],
  ) => {
    const mailOptions = {
      subject,
      html: text,
      attachments,
    };
    return new MailComposer(mailOptions).compile().build();
  };
}

According to https://docs.aws.amazon.com/ses/latest/dg/quotas.html the 40 MB limit is also available when using SMTP and Nodemailer supports SMTP.

Are there any disadvantages to use SMTP until Nodemailer supports SESv2 natively?

According to https://docs.aws.amazon.com/ses/latest/dg/quotas.html the 40 MB limit is also available when using SMTP and Nodemailer supports SMTP.

Are there any disadvantages to use SMTP until Nodemailer supports SESv2 natively?

For us the issue was authentication, with SMTP you have to create SMTP Credentials which for us was a no-go. We're using it in a NestJS context and I use the following workaround to use the v2 api.

import { SendEmailCommand, SESv2Client } from '@aws-sdk/client-sesv2';

    MailerModule.forRootAsync({
      useFactory: (
        configService: ConfigService
      ) => {
        class SendRawEmailCommand extends SendEmailCommand {
          constructor(params) {
            const input = {
              Content: {
                Raw: {
                  Data: params.RawMessage.Data,
                },
              },
              FromEmailAddress: params.Source,
              Destination: {
                ToAddresses: params.Destinations,
              },
            };
            super(input);
          }
        }

        return {
          transport: {
            SES: {
              ses: new SESv2Client({
                region: configService.get('AWS_REGION'),
                credentials: fromContainerMetadata(),
              }),
              aws: {
                SendRawEmailCommand,
              },
            },
          },
        };
      },
      inject: [ConfigService],
    })

According to AWS SES blog: https://aws.amazon.com/blogs/messaging-and-targeting/using-one-click-unsubscribe-with-amazon-ses/. In order to use one-click unsubscribe with SES to compliant with bulk email sending rules, need to utilize ses v2 api. Might be another reason for nodemailer to support SESv2.

based on dyaacov comment above (old sdk), this works flawlessly for sdk v3:

import { SESv2Client, SendEmailCommand } from '@aws-sdk/client-sesv2';
import MailComposer from 'nodemailer/lib/mail-composer/index.js';

const sesv2Client = new SESv2Client({ region: process.env.AWS_REGION });
/* fill the mail options as usual , my email object looks like this
    {
        "from": {"name":"Sender", "address": "example_sender@example.com"},
        "text_body": "some text",
        "subject": "Email Subject",
        "to": [{"name":" A,B", "address":"example_sender@example.com"}],
        "cc": [{"address":"example_1@example.com"},{"address":"example_1@example.com"}],
    }
*/
const mailOptions = {
        from: email.from,
        subject: email['subject'] ? email.subject : '',
        html: email['html_body'] ? email.html_body : '',
        text: email['text_body'] ? email.text_body : '',
        to: email['to'] ? email.to : '',
        cc: email['cc'] ? email.cc : '',
        bcc: email['bcc'] ? email.bcc : '',
        attachments: hasAttachments ? email.attachments : [],
      };

const rawMailData = await new MailComposer(mailOptions).compile().build();

const input = {
          Content: {
            Raw: { Data: rawMailData },
          },
        };
const cmd = new SendEmailCommand(input);

const resp = await sesv2Client.send(cmd);

Only issue with defining custom class SendRawEmailCommand extends SendEmailCommand is that params.Source in FromEmailAddress only returns email address and no email name (John <john@example.com> is converted to john@example.com).

In the recipient inbox it is shown without a nice sender name.

MailComposer from my testing does not return name, only email address.

In the constructor, there is only

{
  RawMessage: {
    Data: <Buffer ...>
  },
  Source: 'info@example.com',
  Destinations: ['recipient@example.com']
}

AWS SDK for JavaScript v2 will enter maintenance mode on September 8, 2024 and reach end-of-support on September 8, 2025. For more information, check blog post at https://a.co/cUPnyil

According to https://docs.aws.amazon.com/ses/latest/dg/quotas.html the 40 MB limit is also available when using SMTP and Nodemailer supports SMTP.

Are there any disadvantages to use SMTP until Nodemailer supports SESv2 natively?

For us the issue was authentication, with SMTP you have to create SMTP Credentials which for us was a no-go.

To clarify, in order to use SMTP with SES, you can only authenticate as an IAM user. This is stated on Obtaining Amazon SES SMTP credentials:

Crucially, this means you won't be able to send emails as an IAM role via SES SMTP.

Please watch out for a behavioral difference between the SESv2 SendEmail API and the SESv1 SendRawEmail APIs when it comes to determining the From header. We got burned by this, so I'm documenting it here. All workarounds posted in this thread which pass FromEmailAddress to SendEmail (all of them, at the time of this writing) are affected.

Details

In SESv1, SendRawEmail determines the From header of the final email using the From header in RawMessage.Data (the RFC5322 email) or the Source parameter. If both are specified, it prefers the From header from RawMessage.Data. This is generally the expected/correct behavior, because the Source parameter is understood to correspond to the SMTP source (MAIL FROM).

In SESv2 however, SendEmail does the opposite—it prefers the value of the FromEmailAddress parameter over the From header in Content.Raw.Data (the RFC5322 email). This is counterintuitive, and may result in a regression of the From header if you use any of the workarounds specified here which pass the FromEmailAddress parameter and your FromEmailAddress value differs from the From header in the RFC5322 email.

This may be what @ihmpavel was saying in #1430 (comment), but I'm not entirely sure...

Solutions...?

If you always expect to have a From header in the RFC5322 email composed by nodemailer, then it is safe to drop the FromEmailAddress parameter, like so:

 class SendRawEmailCommand extends SendEmailCommand {
   constructor(params) {
     const input = {
       Content: {
         Raw: {
           Data: params.RawMessage.Data,
         },
       },
-      FromEmailAddress: params.Source,
       Destination: {
         ToAddresses: params.Destinations,
       },
     };
     super(input);
   }
 }
 
 const transport = nodemailer.createTransport({
   SES: {
     aws: { SendRawEmailCommand },
     ses: new SESv2Client({ region: 'us-west-2' }),
   },
 });

Stepping back, when an official SESv2 nodemailer transport is developed, this gotcha needs to be taken into consideration. Simply adapting the current logic from SESv1

where the envelope.from becomes FromEmailAddress would trigger this problem in SESv2.

I am using solution I found by myself few weeks ago, but I'll check @mxxk as well

transporter.sendMail({
  ses: {
    Source: `NAME <john@example.com>`, // <- check this line
  },
  to: '...'
  from: '...',
  subject: '...',
...

class SendRawEmailCommand extends SendEmailCommand {
  constructor(params: {
    RawMessage: { Data: Uint8Array }
    Source: string
    Destinations: string[]
  }) {
    super({
      Content: {
        Raw: {
          Data: params.RawMessage.Data,
        },
      },
      FromEmailAddress: params.Source, // maybe not required based on https://github.com/nodemailer/nodemailer/issues/1430#issuecomment-2224339555
      Destination: {
        ToAddresses: params.Destinations,
      },
    })
  }
}

export const createEmailTransporter = () =>
  nodemailer.createTransport({
    sendingRate: 20,
    SES: {
      ses: sesClient,
      aws: {
        SendRawEmailCommand,
      },
    },
  })


const transporter = createEmailTransporter()
await transporter.sendMail({
  ses: {
    Source: `NAME <john@example.com>`, // <- check this line
  },
  to: '...'
  from: '...',
  subject: '...',
...

@ihmpavel in your example, I noticed you're providing two from-like addresses:

await transporter.sendMail({
  ses: {
    Source: `NAME <john@example.com&`, // <- check this line
  },
  to: '...'
  from: '...',
  subject: '...',
...

This works, assuming NAME <john@example.com> is the intended value for the final From header.

I find the example a little counterintuitive, because ses.Source completely overrides from, which may not be obvious from the sendMail call, especially if the two are different.

It's up to you of course, but It might be clearer if you stop passing Source and FromEmailAddress as follows:

@@ -10,7 +10,6 @@ class SendRawEmailCommand extends SendEmailCommand {
           Data: params.RawMessage.Data,
         },
       },
-      FromEmailAddress: params.Source, // maybe not required based on https://github.com/nodemailer/nodemailer/issues/1430#issuecomment-2224339555
       Destination: {
         ToAddresses: params.Destinations,
       },
@@ -32,9 +31,6 @@ export const createEmailTransporter = () =>
 
 const transporter = createEmailTransporter()
 await transporter.sendMail({
-  ses: {
-    Source: `NAME <john@example.com>`, // <- check this line
-  },
   to: '...'
   from: '...',
   subject: '...',

Any updates? Thank you