We switched from using SMTP to the AWS SDK for SES because when sending an e-mail the SDK returns the unique message ID of the e-mail. This allowed us to have a special process for handling bounces in our software by using an SNS HTTP endpoint. So the SDK makes sense for use cases where the SMTP protocol doesn't provide enough information.
RFC 822 defines a Messsge-id header that the client can set, and most MTAs can be configured to add one if not set by the client. IIRC, they're supposed to be globally unique, but like so many things in email, ymmv.
Edit: oh, yeah, there's also a queue id returned in the 250 response (in postfix, at least)
Yeah, just in the text of the OK response. So I guess it isn't really very structured. Seems like it would be a useful ESMTP capability to add though - queue identifier and MTA-assigned message-ID.
Interesting thanks. I can imagine that an email sending service wants to be in control of message-id's (would still be interesting to hear the actual rationale).
Perhaps SMTP could use an extension with a new (pipelined) command after DATA, so a client can retrieve the assigned message-id.
I wonder how common it is for message-id's to be overwritten. I must have run into this SES behaviour (along with other problems) when trying to use it as backup for outgoing mail for my mail server: My DKIM signatures include the message-id header, overwriting the header will invalidate them.
Thanks for noting this, this is a pretty solid reason — I thought most people tried to correlate other fields on the incoming email but this also makes sense
Pitching my own: https://github.com/mjl-/mox has a "mox localserve" subcommand that runs a mail server on localhost for testing, including a pedantic mode and special addresses that cause failure conditions you may want to test for. This is actually a full mail server (SMTP, IMAP and much more) and it comes with a webmail client. The "localserve" mode was just so easy to implement that I couldn't resist.
That's a really great point. I was wondering the same thing as the comment root but this is enough for it to make sense. At the end of the day, having a wrapper email/notification class with an SMTP and moving to a specific SES implementation seems like it'll always be a safe dev path.
> For billing purposes, emails that you send to the Amazon SES mailbox simulator are the same as any other email you send using Amazon SES. In other words, we bill you the same amount for messages that you send to the mailbox simulator as for those that you send to regular recipients.
Somewhat offtopic, but is there a simple email service in the sense of SMTP + IMAP/POP + simple email web interface to use AWS as a end-user email service?
While SES can handle both inbound and outbound mail, I think Workmail is the only way to get IMAP and actual hosting of email. I imagine you could set up https://mailinabox.email/ on the cheapest EC2 instance and use SES for outbound, though.
I find that basically every transnational email service supports SMTP so I normally code to that and call it a day…