Sending transactional emails from Pharo

What is the simplest way we have in Pharo to send emails?

We're going to send a bunch of "no-reply@mydomain" style mails
confirming transactions and similars. ~3000 mails.

Anybody already doing this?

Regards.

Esteban A. Maringolo

ps: This will be running in a DigitalOcean droplet, so I could install
an email server, but I don't think it is the simplest solution :)

On 29 May 2014, at 15:10, Esteban A. Maringolo <[hidden email]> wrote:

> What is the simplest way we have in Pharo to send emails?
>

For ESUG we are using Postmark:

        https://postmarkapp.com

There is a library for Pharo that makes it very easy to use.

        http://tulipemoutarde.be/2011/12/29/send-email-from-pharo-with-postmark.html

It works very very well.
No, it would be horror… all the IPs of these machines are registered
as potential spam sources.
So you would need to use then the outbound SMTP server of DigitalOcean,
if they have one.

Sending email is harder than you think these days…

        Marcus

I used postmark as well some time ago, and it worked like a charm. In the mean time I switched to using the builtin smtp client, because it’s a very low amount of mails and I could use the department’s smtp server :-)

On May 29, 2014, at 9:17 AM, Marcus Denker <[hidden email]> wrote:



---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry   -   http://pleiad.cl/~jfabry
PLEIAD lab  -  Computer Science Department (DCC)  -  University of Chile

Thank you guys, I'll give Postmark a try.

I already defined the DKIM/SPF records in the DNS Zone. It's the first
time I see such thing in a DNS table, I hope this works well...

Regards!
Esteban A. Maringolo


2014-05-29 11:06 GMT-03:00 Johan Fabry <[hidden email]>:

Looks very nice.

How do you send the mails?

Do you have a helper class you're willing to share? :)

Regards!

Esteban A. Maringolo


2014-05-29 11:40 GMT-03:00 Norbert Hartl <[hidden email]>:

Am 29.05.2014 um 16:55 schrieb Esteban A. Maringolo <[hidden email]>:

> Looks very nice.
>
> How do you send the mails?
>
> Do you have a helper class you're willing to share? :)
>
I have some classes but as always I just started an implementation and didn’t find much time to make something useful out of it. Anyway. I look into my code and send it to you. Takes half an hour or so (you’re lucky it is raining outside :) ).

Norbert

2014-05-29 12:07 GMT-03:00 Norbert Hartl <[hidden email]>:
I plan to add those features tonight (GMT-3), so there is no rush.
I'll try Postmark too.

I added enough mess to the DNS records as to have a hell of a time
trying to send a simple email :D

Thank you!

As promised... I tested it, and worked. Thank you again Norbert!

I chose Mandrill over Postmark by two main reasons (other than better
looking UI):
* It doesn't require me to authenticate the from address (which is
unexistant, because it is a no-reply address, and the domain doesn't
even have a MX server).
* It's pretty much free (though this is not a relevant factor )

Now about the strategy when sending emails from Pharo...

Assuming you flag the transactions as "mailSent" or similar.

How do you send the emails?

1.a. Right after the "transaction" (or other trigger/status) was performed?
1.b. Right after the transaction, but forking (#fork) the submission
and returning immediately (to avoid waits on the client side)
2.a With a worker image with a loop and running indefinitely (checking
mails in the database every n minutes)
2.b. Running a cron job that starts a Pharo image, does his jobs, and quits

3. Some real architecture involving some kind of live communication
(sockets, MQ, etc.) between the image where the event was triggered
and the worker image.

4. ?

I was thinking in doing 2.

Comments suggerences?

Best regards!

2014-05-30 6:41 GMT-03:00 Norbert Hartl <[hidden email]>:

>> * It's pretty much free (though this is not a relevant factor )
> Well, it is 12000 emails free per month.

We will send arount 3000 per month, and the $1.5 per 10000 of Postmark
wasn't expensive either.

>> Assuming you flag the transactions as "mailSent" or similar.
> Mariano is referring to a piece of code I’ve sent him. This one

> ((mailResponse first at: 'status') = 'sent')
> ifTrue: [  self persistence changeStateOf: participant to: #emailSent ]
> ifFalse: [ self persistence changeStateOf: participant to: #emailFailed ].
> self emptyOkResponse

I was taking about a general pattern, of having a flag in the object,
a log or both. I just need a flag (actually two).


> There are a lot of ways you can do that. From your description I assume you
> have quite some incoming requests that should return quickly. Furthermore
> you want to keep exact track of the sent email and react to unexpected
> cases, right?

Not really that much, but the email is not as important as the
transaction being submitted (through a REST url), so I try to separate
concerns as much as I can.

> In my case I don’t have these requirements. The request rate is pretty low
> and there is no effect to the user if a request to my handler takes longer.
> So I decided to use the synchronous API from Mandrill. So I get back the
> status immediately and can flag the action as OK or failed. I don’t need
> more because if a message is not delivered from time to time it is no
> problem. So I guess I’m in case #1

Here the volume isn't high, I'm simply worried about what a failure in
the sending of the mails could affect the "stability" of the whole
server (which is going to be a single image).

> If your requirements are different I’d probably wouldn’t take the effort to
> do #2. It gets complicated really quick. If we have another view on the
> Mandrill API webhooks come to the rescue [1]. In your request handler you
> send the message asynchronously. The status in the message is „queued“ then.
> If you have the webhooks registered you get called from mandrill whenever
> the status of a mail send changes. That is probably the best option because
> no need to poll anything.There is no support for that in the Mandrill API at
> the moment. But I’m interested in this as well and could collaborate on
> that.

Webhooks seems to be way to go if I want to defer the sending.

> I think #3 would be really heavy weight for the task. My advize is not to do
> these kind of things until you really know that you need it. Complexity
> kills!

I know... I won't do such thing unless there is another requirement
that justifies it.
However, I'm always tempted to use MQs an similars, it is the message
sending paradigm taken to a different level :D

Regards!

Esteban A. Maringolo

Am 30.05.2014 um 14:57 schrieb Esteban A. Maringolo <[hidden email]>:
I don’t think this is an issue. After my last fight with max external semaphores I have some use cases that use outgoing requests on incoming requests. Resource wise it is not a problem and if you put an exception handler around the mail sending it won’t affect the rest at all. Using a SharedQueue and detach the sending completely might be a good idea if you have doubts.

Norbert

But a poor one :P Sometimes I tend to look at these things to. But then I see instead of the message sending I know you have (again) put some format as least common denominator in order to have your request take action. Context and all the important bits are lost that way. So even for a queue I would like to use something more close to our message sending.

Norbert