node_mailer for google apps?

[Amit Kumar]

Has anyone been able to send emails with node_mailer to send emails via google apps?

[Marak Squires]

I don't think so, there is an outstanding issue with this. We are actually in the process of refactoring node_mailer this weekend, there will be a new version coming out shortly. In the mean-time I would recommend trying out some of the other mailer libraries. 

node_mailer started as a very short gist before there were any other email sending solutions. Since then, there have been several improvements to node, and a lot of work done for properly implementing the SMTP protocol in node. 

I'm sorry I couldn't be more helpful to immediately solve your issue. I hope to be pushing for a stable release candidate (v1.0.0 )for node_mailer sometime in the next 2-3 months. 

- Marak

On Sat, Apr 23, 2011 at 1:41 PM, Amit Kumar <i.strik...@gmail.com> wrote:

Has anyone been able to send emails with node_mailer to send emails via google apps?

--
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com.
To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.

[mscdex]

On Apr 23, 1:41 pm, Amit Kumar <i.strike.ag...@gmail.com> wrote:
> Has anyone been able to send emails with node_mailer to send emails via
> google apps?

You might want to also try emailjs: https://github.com/eleith/emailjs

[Amit Kumar]

Thank you everyone for the support i am using mode-mail, and it is working just fine. :)

Amit Kumar
http://www.cobboc.com

[Marcus Westin]

I was unable to get node_mailer working with google apps - also tried
a bunch others. I did get "mail" to work with google apps though!

npm install mail

On Apr 23, 1:41 pm, Amit Kumar <i.strike.ag...@gmail.com> wrote:

[dhruvbird]

Hello,
I've been a user of node-mailer and had only recently had to shift
to emailjs since node-mailer doesn't let me send email to multiple
recipients. I saw the code and it doesn't seem to loop through
recipients to the SMTP server. Am I missing something? I would love to
see that functionality in there.

Regards,
-Dhruv.

On Apr 23, 10:48 pm, Marak Squires <marak.squi...@gmail.com> wrote:
> I don't think so, there is an outstanding issue with this. We are actually
> in the process of refactoring node_mailer this weekend, there will be a new
> version coming out shortly. In the mean-time I would recommend trying out
> some of the other mailer libraries.
>
> node_mailer started as a very short gist before there were any other email
> sending solutions. Since then, there have been several improvements to node,
> and a lot of work done for properly implementing the SMTP protocol in node.
>
> I'm sorry I couldn't be more helpful to immediately solve your issue. I hope
> to be pushing for a stable release candidate (v1.0.0 )for node_mailer
> sometime in the next 2-3 months.
>
> - Marak
>

[Marak Squires]

You can do this now, but the API isn't exposed that nicely. It would require invoking email.send multiple times in a loop, which is kinda annoying. 

The new version is actively being worked on at the moment, I'll see if I can squeeze that additional functionality in.

- Marak

[Dean Mao]

We use emailjs, works fine.  We use it in our https://github.com/luxdelux/restarter project to tell us when processes have died.

[Marak Squires]

The API for restarter is really strange, why wouldn't you just use https://github.com/indexzero/forever ? 

[Dean Mao]

we had some use cases that just made it easier to write our own forever :-).  Some of our processes need to be killed with a specific signal (SIGUSR1, SIGTERM, etc) and we wanted a mechanism to reload the deployment configuration easily.  It was kind of fun to write our own tool for it.  

what is strange about the API?

[Marak Squires]

I just abhor having to manually edit config files. I'd rather have a programmatic API that can abstract this for me. 

[Dean Mao]

Well fortunately forever does exist, so you can use that instead.  For us, we wanted the config file based approach because we don't want people going on the server to setup a new service during deployment.  It's easier for us to just put the configuration into git and when the next production deployment comes around, the service just automatically starts.  

[Marak Squires]

That makes sense. Now that we've derailed the thread a little, I wonder if it would make sense to expose some of the internals of forever a little so you can do this. It seems like it wouldn't be too hard of a change. 

Either way, thanks for the info. :-)

[Dean Mao]

Yeah, maybe I'll hack up forever to do what we want too.  For the most part, it was just me wanting to write it myself, to learn.  I think restarter was my first "real" npm package that I put out there.

[Marak Squires]

Woah! That would be awesome! Let me know if you come up with anything. indexzero maintains the library, but I'm sure he'd accept a pull request!

[Dean Mao]

What signal does forever send to kill processes?  The reason we have signals configured is so that the node process can finish whatever job it's doing before exiting.  

We've also set it up to email us when processes die since it does happen every now and then and we'd like to know why/how.  I configured restarter to send us the last 200 lines from the log file when a process dies -- makes debugging easier.  The email config would probably have to be setup in a config file, b/c it would be annoying to do that programmatically every time the server starts up.  Of course, we don't reboot our server often, but if Linode does reboot it, it's good to know that everything will still run normally!

[Marak Squires]

I believe forever uses process.kill? So the default is SIGTERM? https://github.com/indexzero/forever/blob/master/lib/forever.js#L150

As for email alerts, we've got an open issue for this. I think we are going to implement a generic "hooks" system.

https://github.com/indexzero/forever/issues/10

[dhruvbird]

On Apr 24, 10:01 am, Marak Squires <marak.squi...@gmail.com> wrote:
> You can do this now, but the API isn't exposed that nicely. It would require
> invoking email.send multiple times in a loop, which is kinda annoying.

hmm... yes. However, wouldn't that result in multiple message IDs? I
don't know for sure, but would it have an repercussions on message
threading?

Regards,
-Dhruv.

[dhruvbird]

Hey, it's me again.

I switched back to node-mailer for a while and here is the feedback:

1. Installing iconv() is a pain - can you do without it - as a result,
I landed up installing 0.4.52 at many places

2. I get such random crashes when the timout between sending many
messages is 1s - 3s (didn't try for higher values). My guess is that
the socket close event isn't being fired and because of this the write
fails (on a closed socket). I've faced such a situation in one of my
projects and I have landed up wrapping every write() in a try/catch
block and re-trying the connection when it throws an exception.

/opt/node-v0.4.7/lib/node_modules/mailer/lib/node_mailer.js:123
self._stream.write([
^
TypeError: Cannot call method 'write' of null
at writeData (/opt/node-v0.4.7/lib/node_modules/mailer/lib/
node_mailer.js:123:26)
at /opt/node-v0.4.7/lib/node_modules/mailer/lib/node_mailer.js:
97:15
at EventEmitter.onEvent (/opt/node-v0.4.7/lib/node_modules/mailer/
lib/node_mailer.js:185:11)
at EventEmitter.emit (events.js:61:17)
at Carrier.<anonymous> (/opt/node-v0.4.7/lib/node_modules/mailer/
lib/node_mailer.js:174:26)
at Carrier.emit (events.js:64:17)
at /opt/node-v0.4.7/lib/node_modules/mailer/node_modules/carrier/
lib/carrier.js:40:16
at Array.forEach (native)
at Socket.<anonymous> (/opt/node-v0.4.7/lib/node_modules/mailer/
node_modules/carrier/lib/carrier.js:26:13)
at Socket.emit (events.js:64:17)

3. If the timeout is 300ms (I think you hold the connection for 1
sec), then the server seems to disconnect after a certain number of
messages.

I don't know how to fix this!! Too fast and the server screws me, too
low and the lib. takes revenge... :-(

Regards,
-Dhruv.


On Apr 23, 10:48 pm, Marak Squires <marak.squi...@gmail.com> wrote:

> I don't think so, there is an outstanding issue with this. We are actually
> in the process of refactoring node_mailer this weekend, there will be a new
> version coming out shortly. In the mean-time I would recommend trying out
> some of the other mailer libraries.
>
> node_mailer started as a very short gist before there were any other email
> sending solutions. Since then, there have been several improvements to node,
> and a lot of work done for properly implementing the SMTP protocol in node.
>
> I'm sorry I couldn't be more helpful to immediately solve your issue. I hope
> to be pushing for a stable release candidate (v1.0.0 )for node_mailer
> sometime in the next 2-3 months.
>
> - Marak
>

[Marak Squires]

There were a lot of issues with node_mailer and we fixed almost all of them. The library has been fully rebuilt in the past month and now uses nodemailer as a dep. It should work well now...

Try updating to v0.5.6, gmail should work. We've got a blog post coming out soon to explain the rebuild and the upstream commits we made along the way :-)

https://github.com/marak/node_mailer

[dhruvbird]

Great!! :-) I'm looking forward to getting it working - iconv on
Cygwin is giving me some grief, but I'll try to figure it out...

Regards,
-Dhruv.

[Marak Squires]

I don't like having the iconv dep, but I think it really helps the library out.

[dhruvbird]

I can understand. Is there any way you can do something similar to
what node-xmpp (or is it ltx) [one of the projects by astro] do. They
need stringprep, but if you don't have it, they will do without it
(hence can't put it in package.json deps) and print a warning on
startup. That way, people who know they won't need it don't need to
get it.

I wonder if there is a way of specifying an optional dependency in
package.json though.

Regards,
-Dhruv.

On May 22, 12:32 am, Marak Squires <marak.squi...@gmail.com> wrote:
> I don't like having the iconv dep, but I think it really helps the library
> out.
>