cfmail - receiving the success status code from the mail server

[JF Robichaud]

Little background - I'm trying to use Amazon SES as my mail server for an application, so far I got an account and I can send emails fine from my development machine. However, for production usage they require you to handle bounces and complaints to clean your list and I suppose to protect their servers' reputation.

When there's a bounce or complaint they issue a notification either by email or using their SNS notification queue giving details, you're suppose to consume these notifications and update your list of emails accordingly to maintain a good reputation as a sender.  The notification is in JSON and has the info of the original email within - the most important part being the messageId which is tied to an individual message so you can match it internally to what you sent.

When you send an email using their API you receive the messageId which can be stored and acted upon if there's a notification triggered for it.

I can use their API, but would much rather use their SMTP which would make integration with our existing code that uses cfmail a lot quicker.

The issue I'm having is that Amazon includes the messageId as part of a success response when using SMTP (http://docs.aws.amazon.com/ses/latest/DeveloperGuide/smtp-response-codes.html)

Successful delivery

250 Ok <Message ID>

<Message ID> is a string of characters that Amazon SES uses to uniquely identify a message.

Even with mail spooling disabled I have never found a way to handle a successful response using cfmail like you could do with cfhttp (Status 200-OK). 

I figured that before I go and start writing some cfmail wrapper I would double check to make sure that my assumption is correct and that it in fact not currently possible to handle a success response from cfmail.

Thoughts? Does anyone have experience using Amazon SES with Lucee?

[Denard Springle]

On Monday, February 1, 2016 at 3:27:07 PM UTC-5, JF Robichaud wrote:

I figured that before I go and start writing some cfmail wrapper I would double check to make sure that my assumption is correct and that it in fact not currently possible to handle a success response from cfmail.

There is no (documented) way of getting a response from <cfmail> - the process is asynchronous and once <cfmail> fires it's out of the requesting threads hands. I suppose with logging turned on [verbosely] it should be possible to check for the success and message id in the mail log. 

That being said... SNS is stupid easy to implement and would, frankly, be the way I would handle bounces and complaints. I use SES for mail, but I've only used it in dev or for super low volume mail from production sites (for example, error handling emails in production sites go through SES), but if faced with needing more volume and required to handle bounces and complaints, I would most likely utilize the SNS API to handle them. You wouldn't even need to 'wrap' <cfmail> to do it - the SNS push will alert your app that an id was bounced or received the complaint, and you could then manage the list. That seems like the KISS way to do it, anyway :)

-- Denny

[JF Robichaud]

Thanks that's what I figured as well from my testing.  I thought there might have been a way with spooling disabled so I wanted to confirm before diving into code changes.

I'm definitely going with SNS to handle the bounces and complaints, but due to the nature of the content (newsletters/markerting) I want to be able to match the complaints vs a "send event/content" so I will need to store the messageId assigned when sending so I can match them once I receive the notification from SNS.  If I use the SMTP interface that's returned in the success response.

I tried with Java as a test and using the following I was able to retrieve it.

System.out.println(((SMTPTransport) transport).getLastServerResponse()); //returns 250 Ok 00000152a423db9e-a90905bc-63e0-4dea-b746-9501605b61b2-000000

Looks like I'll just have to wrap the SES API so the app can send email, which shouldn't be that hard and a fun little project :)

Bit of googling and it doesn't look like I'm the first to try it out, Saman from cflove has what looks like a full working version available at http://cflove.org/2013/02/using-amazon-ses-api-sendrawemail-with-coldfusion.cfm

--
JF

[Igal @ Lucee.org]

we were talking a while back about adding callback functions, or event handlers, like onComplete and onError to Tasks (cfmail runs as a Task so that would apply to it).

but that of course will only help you if the SMTP server you're connecting to will reject the email.

if you want to handle bounces that take place after the SMTP session ends then you should get a mailbox that can handle sub-addressing (see https://en.wikipedia.org/wiki/Email_address#Sub-addressing ).  then when you send the email, give each message an ID for reference, and specify the "failTo" attribute in cfmail.  so your cfmail will look like:

<cfmail to="#recipient#" from="#sender#" subject="Test #getTickCount()#" failTo="bounces+#emailId#@yourdomain.com">

a bounced email will go to the bou...@yourdomain.com mailbox with the and you will be able to extract the email is from the username portion of the bounce.

Igal Sapir
Lucee Core Developer
Lucee.org

--
Love Lucee? Become a supporter and be part of the Lucee project today! - http://lucee.org/supporters/become-a-supporter.html
---
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/b91f2539-e121-4088-9811-43412100c4ed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[JF Robichaud]

Callbacks would definitely be quite useful for tasks. With cfmail particularly, if spooling is enabled it's quite hard to know what happens once its off to the queue.  Back when we were on ACF, I remember monitoring the Undeliverable directory for new items - that was possible since the *.cfmail files were in clear text, but wouldn't really be possible with the *.tsk files.

Off the top of my head, one case were an onError would have been quite useful is a few years ago an external SMTP relay started rejecting emails for having "spam like characteristics" (status 550) due to a miss-configuration on their end.  It took us a while to catch it (that's when we started monitoring the Undeliverable directory).

We thought about setting up a failto mailbox for bounces, but since we're moving to Amazon SES they have the option to manage these through their SNS service which gives notification via mail, API or HTTP endpoints.  It's easier and doesn't require monitoring a separate mailbox - it also allows you to manage complaints.  To do this they assign each message a messageId that you don't control which is included in their notifications, this way you can trace it back to any given email sent by your app... quite useful and easy to process in bulk.

The issue is that if you don't want to use their API, but would rather use their SMTP endpoint that messageId is sent in the SMTP success response (e.g. 250 Ok 00000152a7acd208-468f1548-27fd-4f51-92a8-39ab8d52e13e-000000) which is not accessible when using cfmail, an onComplete would be helpful here I think.

On Wednesday, 3 February 2016 12:55:13 UTC-5, Igal wrote:

we were talking a while back about adding callback functions, or event handlers, like onComplete and onError to Tasks (cfmail runs as a Task so that would apply to it).

but that of course will only help you if the SMTP server you're connecting to will reject the email.

if you want to handle bounces that take place after the SMTP session ends then you should get a mailbox that can handle sub-addressing (see https://en.wikipedia.org/wiki/Email_address#Sub-addressing ).  then when you send the email, give each message an ID for reference, and specify the "failTo" attribute in cfmail.  so your cfmail will look like:

<cfmail to="#recipient#" from="#sender#" subject="Test #getTickCount()#" failTo="bounces+...@yourdomain.com">