[RESOLVED] Any simple way to send email without Outlook dependant methods?

I've tried searching everywhere, and I found out about MAPI and CDO, but they both depend on Microsoft Outlook, which practically nobody uses, me included. This originates an error when a session log in is attempted.
Thus, I tried searching some different ways and all I found was huge pieces of code (read title: I want to keep it simple) or extra dlls, which I also don't want, seeing as I don't want the user to get my application, than get this dll file, than this... Of course it's not much, just a file, but it's still a small pain.

My question is a simple one: is there any way to send a simple email without using ways that require MS Outlook, and that don't require the user to login? (I also saw one way that required a login, but this is very bad, because I could quite easily use their password and have it sent to me: I don't want to give the impression I want to do that)
My goal with this is just to have the user write a quick email inside the program that warns me about a bug that happened or something similar.

cdo does not require outlook to be installed

you can shellexecute mailto:
you can prefill most of the fields, then a new message will be created in the users default email client and presented to the user, who can add or change details then click send

there is no other simple method that does not require some dll or other dependency, cdo is very simple, but it does require cdo to be available, which it normally is as it is part of windows installations

there are many threads and examples, see this one
http://www.vbforums.com/showthread.php?t=596453
for all the normal alternatives and links to samples

Yes yes, I did say I didn't want nothing too complex, but I probably exaggerated. Using a control is ok with me (I forgot to say that). I checked vbSendMail.dll in the past, but prefered not to use it, but I'll take another look at it. If I still don't like it, I'll check the others so thanks for the link, westconn!

I have used vbsendmail, but found it to difficult for my users to configure. I then switched to cdosys32.dll and it worked good until Vista. After vista the cdosys32 required a lot of configuration like vbsendmail. So i purchased an OCX to send emails: http://www.emailarchitect.net/webapp/smtpcom/
My app has a form for ideas recommendations (also any errors) that sends emails to me thru my website using an online jmail component. I hired a coder to create this, but it only sends emails to me. Not sure if it could be configured to send emails to other people. This method would require you to have a website and supports the jmail component.
One thing to keep in mind, the less authenication your emails have the more likely to flagged as spam

Quote:

---

Originally Posted by Espyo

My goal with this is just to have the user write a quick email inside the program that warns me about a bug that happened or something similar.

---

Email is getting harder and harder to use for such purposes.

There are alternatives:

• Use an HTTPRequest object of some sort to post the info to an ASP, PHP, etc. web page on a site you maintain.
• Use an FTP client object of some sort to FTP the info in a file to an FTP server folder that users have write access to.
• Use a WebDAV object to post a file to a WebDAV folder users have write access to.

I prefer the WebDAV option, mostly because it gets through firewalls more cleanly than FTP and because there is no server-side development to do.

The user feedback and bug report messages end up in files (randomly generated names) in a WebDAV folder. Then you can have a program at your end that harvests these (gets a directory listing, downloads each file, then removes each file). The "harvester" can display these to you, report them to a printout, or put them into a database - whatever you want.

One provider I use offers a free 2GB account that includes 1 guest user. I give the guest user write access to one folder, and I keep the server URL, folder name, user ID, and password in an INI file on the customer's machine. This lets me make changes, including password changes, by updating the INI - which can be pulled down by the client program using WebDAV from another read-only folder: Each program run the client program can check the date of the INI file on the server and download the new one (if new).

I only use light encryption/obfuscation on those values since they aren't highly critical.

INI updating is a little trickier than that, since I store "current" values there with a "good until" date and a set of "next" values that are "good after" that date. Normally the values are the same, but I can post a new INI with new "next" values to transition past an old password to a new one, or to a new hosting provider, etc. If the user gets all hosed up (hasn't run the program for a long time) I can email them an updater they run to replace the stale INI file.


Full program updates can also be done like this using WebDAV. It is a much cleaner process than trying to use automated email and plain old HTTP downloads.

It's going to be a lot of work to implement such a thing, so I guess it's best not to. Not because I'm lazy, but because I want to keep my app simple. And even if it needed to be complicated, some of the methods don't work right.
Yet, I had no idea that mailto: could have more parameters; I didn't check westconn's post that well. I guess I'll go with that.
Now, the question isn't quite resolved, but should I go ahead and mark it as such anyway? I guess so, because I don't need anything else from you guys, and a resolved thread makes it so that it's ignored by those who want to help.

up to you on that
if you have specific questions on using mailto, you can start a new thread later, with appropriate subject

using SMTP/POP protocols may come handy, handling them without SSL is easy.

this may or may not help, but you can actually read email/create email with telnet. You just log into the mail port (25 i think).

Quote:

---

Originally Posted by Espyo

It's going to be a lot of work to implement such a thing, so I guess it's best not to. Not because I'm lazy, but because I want to keep my app simple.

---

If this was in response to my post, well yes it can get complicated. Most of the complexity though comes in managing the credentials for access to the WebDAV server.


In the end you'll have the same problems using email. One of the options I see I left out was to get an email account for this purpose from some provider - and hardcode the mail server, mailbox/account, and password. Or try to manage it via INI or config files as I described above, to allow changes over the long term.

I think the mailto: option is the weakest of all. It won't do a thing if you use it on a machine where the user only has Web-based email, since it relies on a local email client with a default email profile set up, just as MAPI approaches do.

The problem is always determining a server and set of credentials to use. This is why mailto:, MAPI, and CDO in default mode (which uses MAPI credentials by default) tend to fail. This can be handled by providing your own in the program. The second problem tends to involve firewalls. This is why I like solutions based on HTTP/HTTPS, since those ports are almost always open for outbound connections.

Yes, just as I thought, dilettante. It's not an easy thing to do, specially taking the fact that I was hardly thought anything about protocols at school, which makes me more of a dummy on the subject.
As for using mailto, like I said I'd use above, it's quite true it's the weakest. It merely opens Outlook/Internet browser with write email page; with some field filled. Nonetheless, I guess that that's better than nothing. Also, if the user doesn't want to open it (s)he can cancel it.
There's not much more than can be done, at the moment, so thank you all for your help. I'll mark it as resolved because, in a way, you guys did answer my questions. Also, I don't need any further info, and if I do, I'll ask again.