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 <jfabry@dcc.uchile.cl>:

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 <marcus.denker@inria.fr> wrote:

...

On 29 May 2014, at 15:10, Esteban A. Maringolo <emaringolo@gmail.com> 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.

...

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 :)

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

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

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

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 <norbert@hartl.name>:

Am 29.05.2014 um 15:10 schrieb Esteban A. Maringolo <emaringolo@gmail.com>:

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?

Yes. I’m using Mandrill

http://mandrill.com/

It is the service for autmated mail from mail chimp.

Norbert

2014-05-29 12:07 GMT-03:00 Norbert Hartl <norbert@hartl.name>:

Am 29.05.2014 um 16:55 schrieb Esteban A. Maringolo <emaringolo@gmail.com>:

...

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 :) ).

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!

Am 30.05.2014 um 05:19 schrieb Esteban A. Maringolo <emaringolo@gmail.com>:

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

I’m glad to hear that.

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 )

Well, it is 12000 emails free per month.

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

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

Mariano is referring to a piece of code I’ve sent him. This one post | mailResponse | participant := self participantWithId: request uri pathSegments second. participant hasEmail ifTrue: [ mailResponse := (MandrillMessage new addRecipient: (MandrillRecipient new email: participant email); html: self emailBody; subject: self subjectLine; fromEmail: ProjectConfiguration fromEmail; fromName: ProjectConfiguration fromName ) send. ]. ((mailResponse first at: 'status') = 'sent') ifTrue: [ self persistence changeStateOf: participant to: #emailSent ] ifFalse: [ self persistence changeStateOf: participant to: #emailFailed ]. self emptyOkResponse

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?

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? 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 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. 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! Norbert P.S.: The code is on smalltalkhub now [2] [1] http://help.mandrill.com/entries/21738186-Introduction-to-Webhooks [2] http://smalltalkhub.com/#!/~NorbertHartl/Mandrill

Am 30.05.2014 um 14:57 schrieb Esteban A. Maringolo <emaringolo@gmail.com>:

2014-05-30 6:41 GMT-03:00 Norbert Hartl <norbert@hartl.name>:

...

...

* 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).

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

...

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

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