[erlang-questions] Erlang SMTP Client?
David Mercer
What is the state of the art for sending email from Erlang? I can google up a couple of results, but (1) I was surprised there is no such module in the standard distribution (that I could find); and (2) among the results, I wasn’t sure which is the current state of the art.
Please advise. Thank-you.
David Mercer
Eric Merritt
https://github.com/ericbmerritt/erfc_parsers
> _______________________________________________
> erlang-questions mailing list
> erlang-q...@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
Andrew Thompson
> There is an smtp client here that might be useful for you
>
> https://github.com/ericbmerritt/erfc_parsers
>
I'm the author and maintainer of (in my biased view) the most complete
SMTP library for erlang, gen_smtp:
https://github.com/Vagabond/gen_smtp
gen_smtp includes both a SMTP client, and a callback framework for
writing SMTP servers. It's part of several other erlang projects now,
including Zotonic and Chicago Boss.
The other alternative worth considering is Geoff's esmtp:
https://github.com/archaelus/esmtp
I'm not aware of any other SMTP clients that are reliable or mature
enough to be considered for serious usage. There's a random smtp fsm
kicking around the internet, but its not maintained and the licensing on
it is uncertain (or its under the GPL, its unclear).
Andrew
Marc Worrell
Richard Carlsson
> What is the state of the art for sending email from Erlang? I can google
> up a couple of results, but (1) I was surprised there is no such module
> in the standard distribution (that I could find); and (2) among the
> results, I wasn’t sure which is the current state of the art.
If you just want something simple and reliable, going through sendmail
can be a good idea. We've used this library at Klarna for years:
https://github.com/richcarl/sendmail
For local testing, e.g., on a laptop, I can recommend installing
nullmailer as sendmail replacement rather than postfix or exim4
(http://undesigned.org.za/2007/11/22/nullmailer-a-developers-best-friend) if
you're just interested in forwarding mail from the local machine to a
smarthost.
/Richard
David Mercer
> I'm the author and maintainer of (in my biased view) the most complete
> SMTP library for erlang, gen_smtp:
>
> https://github.com/Vagabond/gen_smtp
>
> gen_smtp includes both a SMTP client, and a callback framework for
> writing SMTP servers. It's part of several other erlang projects now,
> including Zotonic and Chicago Boss.
Thanks. That worked fine out of the box. I must admit, I am surprised
there is no SMTP client in the standard distribution. You would think that
would be a fairly common communication protocol...
Thanks, Andrew.
Cheers,
DBM
Eric Merritt
> On Mon, Oct 10, 2011 at 12:05:40PM -0500, Eric Merritt wrote:
>> There is an smtp client here that might be useful for you
>>
>> https://github.com/ericbmerritt/erfc_parsers
>>
> All I see in this repo is a CSV parser?
You are absolutely right. I am not sure where my head was. I have an
smtp parser to publish there as well. I guess in my mind I had already
published it. Sorry for the confusion.
Richard Carlsson
> On Monday, October 10, 2011, Andrew Thompson wrote:
>
>> I'm the author and maintainer of (in my biased view) the most complete
>> SMTP library for erlang, gen_smtp:
>>
>> https://github.com/Vagabond/gen_smtp
>>
>> gen_smtp includes both a SMTP client, and a callback framework for
>> writing SMTP servers. It's part of several other erlang projects now,
>> including Zotonic and Chicago Boss.
>
> Thanks. That worked fine out of the box. I must admit, I am surprised
> there is no SMTP client in the standard distribution. You would think that
> would be a fairly common communication protocol...
Often, what you want is more than just SMTP. If there are some network
issues (or your mail server is simply down) at the time your program
tries to send the mail, you usually want your program to still be able
to regard the mail as sent and carry on. This means that the mail needs
to be persistently stored on disk in a spool area and that the MTA
regularly tries to send any outgoing mail that's been spooled, so it
will eventually be on its way once the problem is resolved. That's why
we like to rely on sendmail instead. But it all depends on the needs of
your application.
/Richard
Ahmed Al-Saadi
> On Monday, October 10, 2011, Andrew Thompson wrote:
> ... I must admit, I am surprised
> there is no SMTP client in the standard distribution. You would think that
> would be a fairly common communication protocol...
You will be more surprised to find (almost) no Unicode support in the
standard distribution!
-signed(ahmed).
Robert Raschke
On 10/10/11 5:30 PM, David Mercer wrote:
You will be more surprised to find (almost) no Unicode support in the standard distribution!On Monday, October 10, 2011, Andrew Thompson wrote:...
... I must admit, I am surprised...
there is no SMTP client in the standard distribution. You would think that
would be a fairly common communication protocol...
-signed(ahmed).
???
Dealing with Unicode is highly application dependent.
I would say that the majority of code dealing with strings transports them from one place to another, and then binaries and the unicode module are excellent! And for reasonable string manipulation a list of code points (or UTF-8 binaries) are all you will need for a long time.
If you require a deeper understanding of Unicode code points, combining forms, and their visual representations (e.g., when implementing an editor), then you've got a ton more problems. And those are hard problems with more corner cases that you would ever wish for.
Apologies for veering off topic, and probably coming across a wee bit too harsh,
Robby
Ahmed Al-Saadi
Cheers!
Ahmed
David Mercer
> On 10/10/2011 11:30 PM, David Mercer wrote:
> > I must admit, I am
> surprised
> > there is no SMTP client in the standard distribution. You would
> think that
> > would be a fairly common communication protocol...
>
> Often, what you want is more than just SMTP. If there are some network
> issues (or your mail server is simply down) at the time your program
> tries to send the mail, you usually want your program to still be able
> to regard the mail as sent and carry on. This means that the mail needs
> to be persistently stored on disk in a spool area and that the MTA
> regularly tries to send any outgoing mail that's been spooled, so it
> will eventually be on its way once the problem is resolved. That's why
> we like to rely on sendmail instead. But it all depends on the needs of
> your application.
Having an SMTP module would enable you to write in Erlang what you need for
storing messages for later delivery, if that happened to be your
requirement.
What do people think of an EEP to add SMTP support? I'm thinking I might be
the only person who needs it, since Erlang is, like, 100 years old and it's
not in there yet. Is there a silent majority secretly hoping for SMTP in
the next release of Erlang, or am I standing alone on this hill?
Cheers,
DBM
Loïc Hoguin
> On Monday, October 10, 2011, Richard Carlsson wrote:
>
>> On 10/10/2011 11:30 PM, David Mercer wrote:
>>> I must admit, I am
>> surprised
>>> there is no SMTP client in the standard distribution. You would
>> think that
>>> would be a fairly common communication protocol...
>>
>> Often, what you want is more than just SMTP. If there are some network
>> issues (or your mail server is simply down) at the time your program
>> tries to send the mail, you usually want your program to still be able
>> to regard the mail as sent and carry on. This means that the mail needs
>> to be persistently stored on disk in a spool area and that the MTA
>> regularly tries to send any outgoing mail that's been spooled, so it
>> will eventually be on its way once the problem is resolved. That's why
>> we like to rely on sendmail instead. But it all depends on the needs of
>> your application.
>
> Having an SMTP module would enable you to write in Erlang what you need for
> storing messages for later delivery, if that happened to be your
> requirement.
>
> What do people think of an EEP to add SMTP support? I'm thinking I might be
> the only person who needs it, since Erlang is, like, 100 years old and it's
> not in there yet. Is there a silent majority secretly hoping for SMTP in
> the next release of Erlang, or am I standing alone on this hill?
There are SMTP modules. Why do you need them to be in the standard
distribution? You can just use them as a dependency.
--
Loïc Hoguin
Dev:Extend
David Mercer
> There are SMTP modules. Why do you need them to be in the standard
> distribution? You can just use them as a dependency.
Good question. I guess just to avoid having to ask this list which is the
state of the art, but that's very unsocial of me...
I'm not pushing for it. I've got a solution to my immediate needs (by
asking this list), I just thought it might help those who come after me.
Ah, how very altruistic of me, eh?
Cheers,
DBM
Loïc Hoguin
> On Tuesday, October 11, 2011, Loïc Hoguin wrote:
>
>> There are SMTP modules. Why do you need them to be in the standard
>> distribution? You can just use them as a dependency.
>
> Good question. I guess just to avoid having to ask this list which is the
> state of the art, but that's very unsocial of me...
>
> I'm not pushing for it. I've got a solution to my immediate needs (by
> asking this list), I just thought it might help those who come after me.
> Ah, how very altruistic of me, eh?
What we need, in my opinion, is not a big standard distribution that can
do everything including distributed coffee, but a big package repository
that would be well integrated into Erlang's tools so we could just have
Erlang pull them when needed. Rebar dependencies are doing half the work
there, all that's missing is a community maintained repository that's
supported officially by a big player (either Erlang/OTP or rebar).
--
Loïc Hoguin
Dev:Extend
David Mercer
the way) wrote:
> What we need, in my opinion, is not a big standard distribution that
> can
> do everything including distributed coffee, but a big package
> repository
> that would be well integrated into Erlang's tools so we could just have
> Erlang pull them when needed. Rebar dependencies are doing half the
> work
> there, all that's missing is a community maintained repository that's
> supported officially by a big player (either Erlang/OTP or rebar).
Rebar, I don't think, is in Erlang, and it doesn't work on all Erlang
platforms. If it can be rewritten in Erlang, it might work for this
purpose...
I don't disagree with you otherwise.
Cheers,
DBM
Jack Moffitt
> platforms. If it can be rewritten in Erlang, it might work for this
> purpose...
Um, rebar is most definitely in Erlang. However, you are correct that
it's windows support is a little weaker than the other systems.
Code can be browsed here:
http://github.com/basho/rebar
jack.
Michael Schreckenbauer
> On Tuesday, October 11, 2011, Loïc Hoguin (which is a really cool name, by
>
> the way) wrote:
> > What we need, in my opinion, is not a big standard distribution that
> > can
> > do everything including distributed coffee, but a big package
> > repository
> > that would be well integrated into Erlang's tools so we could just have
> > Erlang pull them when needed. Rebar dependencies are doing half the
> > work
> > there, all that's missing is a community maintained repository that's
> > supported officially by a big player (either Erlang/OTP or rebar).
>
> Rebar, I don't think, is in Erlang, and it doesn't work on all Erlang
> platforms. If it can be rewritten in Erlang, it might work for this
> purpose...
https://github.com/basho/rebar
looks rather erlang-ish to me :)
> I don't disagree with you otherwise.
>
> Cheers,
> DBM
Best,
Michael
David Mercer
> > Rebar, I don't think, is in Erlang, and it doesn't work on all Erlang
> > platforms. If it can be rewritten in Erlang, it might work for this
> > purpose...
>
> Um, rebar is most definitely in Erlang. However, you are correct that
> it's windows support is a little weaker than the other systems.
Mea culpa. I was just guessing, given its lack of Windows support. Why
wouldn't it work on Windows, then, if it's in Erlang. Erlang runs on
Windows...
DBM
Jack Moffitt
> wouldn't it work on Windows, then, if it's in Erlang. Erlang runs on
> Windows...
I believe it makes a few assumptions about the shell environment. I
believe there are people working to address this if list traffic on
the rebar list is any indication. I imagine some parts of it work just
fine, and I'm sure feedback would be appreciated to find the remaining
rough edges.
jack.
Tony Rogvall
What we need, in my opinion, is not a big standard distribution that can
do everything including distributed coffee, but a big package repository
that would be well integrated into Erlang's tools so we could just have
Erlang pull them when needed. Rebar dependencies are doing half the work
there, all that's missing is a community maintained repository that's
supported officially by a big player (either Erlang/OTP or rebar).
--
Loïc Hoguin
Dev:Extend
_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
Robert Raschke
On Tuesday, October 11, 2011, Jack Moffitt wrote:Mea culpa. I was just guessing, given its lack of Windows support. Why
> > Rebar, I don't think, is in Erlang, and it doesn't work on all Erlang
> > platforms. If it can be rewritten in Erlang, it might work for this
> > purpose...
>
> Um, rebar is most definitely in Erlang. However, you are correct that
> it's windows support is a little weaker than the other systems.
wouldn't it work on Windows, then, if it's in Erlang. Erlang runs on
Windows...
DBM
I've never experienced any issues with running rebar under Windows. The only hurdle is that it is usually invoked from a Makefile. And that's not really a hurdle, more like a bit of uneven ground. ;-)
Robby
David Mercer
Aw, y’all are making me work for my opinion. I’m going to have to pull out rebar again and see what my problems with it were. Make shouldn’t have been an issue, since I use make all the time. I’ll let you know what I find out…
Tim Watson
> Mea culpa. I was just guessing, given its lack of Windows support. WhyI believe it makes a few assumptions about the shell environment. I
> wouldn't it work on Windows, then, if it's in Erlang. Erlang runs on
> Windows...
believe there are people working to address this if list traffic on
the rebar list is any indication. I imagine some parts of it work just
fine, and I'm sure feedback would be appreciated to find the remaining
rough edges.
Tim Watson
+1On 11 okt 2011, at 20:30, Loïc Hoguin wrote:What we need, in my opinion, is not a big standard distribution that can
do everything including distributed coffee, but a big package repository
that would be well integrated into Erlang's tools so we could just have
Erlang pull them when needed. Rebar dependencies are doing half the work
there, all that's missing is a community maintained repository that's
supported officially by a big player (either Erlang/OTP or rebar)./Tony
