VFP Email

[quailco]

I have been using the code from faq184-3840 as a example with just a few chgs tailoring it to my data. I get 2 errors as shown in the screenshots below. Anyone have any suggestions on how to proceed

.

The 2nd SS shows DATA error in case it isnt clear. It is not obvious to me what that means but my guess is that the parameter iding the email didnt get passed properly.

 

[Koen Piller]

Hi,
I understand you have some problems with sending Email using pure VFP codings. Have you tried already to make use of "VFPWinsock"? An application made by Francis from the French VFP users group.
Enclosed a zipfile with this .prg plus some sample's

Regards,

Koen

 

[Olaf Doschke]

It doesn't work with my mail server requiring STARTTLS authentication. That's not covered by this code.

>ERROR [250-PIPELINING250-8BITMIME250-STARTTLS250 AUTH LOGIN PLAIN] -> ERR09

Looking for anything more to setup up in the VFP_Winsock_Send_Mail class about authentication the way it's necessary for secure connections, I don't find anything. Today mail servers requiring secure login are the norm and Atout Fox will need to add this feature to make it usable again.

If you want to depend on the least MAPI is already a very fine solution, works for this case. CDO is too, but Thunderbird doesn't seem to set up CDO.Configuration. That's not impossible, but you need to go into the details about how that's done.

Besides that, this VFPwwinsock code is the least dependent on anything, but for the price of going very low level. The version history shows that from version 1.05 onwards it's not even using the Winsock.OCX anymore, it uses the WS2_32.DLL. So not only no external components, no OCX. This is an OS DLL. The Winsock.OCX is from MS, too, but not standard anymore. Still, it would only be complete, if it supports advanced authentication, Koen, therefore I wouldn't recommend VFPwinsock.

MAPI will be as safe as your mail client allows, and Thunderbird allows connections to be made via SSL/TLS or STARTTLS. So in this way, MAPI automatically updates with the capabilities of mail clients. As long as you have one and as long as MAPI remains a Windows OS standard for addressing mail clients. I don't even know a mail client that isn't supporting MAPI unless you'd roll your own mail client for example with that code. And to be clear: Using MAPI means you only communicate with a mail client in a standard way MS has foreseen for that, the mail client then puts your sent mail into it's sent items as one benefit and cares for the mail server, not only about connection but retries, etc.

I'm all eyes and ears, how you'd solve that, Koen, it would be okay to have that. No matter if as an external add-on establishing an SSL tunnel first, or as an extension of VFPwinsock. For several reasons:

1. Atout Fox is an active community and so that code is maintained. Unlike Craig Boyd, whos series of sending mail in different ways isn't even complete in his blog.
2. It allows sending HTML Mail, which simple MAPI does not. Some clients can be used in the tricky way to leave the text body empty and add an HTML attachment, which is then made the HTML mail body, but Thunderbird does not do that.
3. The ExtendedMAPI.FLL that exists from Craig Boyd has comments stating it's only working when the user is in the admin group of a system. So while it also allows HTML emails, that's an obvious minus.
4. It could be the basis of usage on servers, where installation of mail clients is not the norm and unless you're running on the server that also runs Exchange, CDO also isn't an option.

There is another alternative you also find googling: Using blat with VFP. That also has all the features and all it adds to the distribution process is that single DLL. It makes use of the same C runtime the OS uses, still, just one version covers all OSes from 2000 up to Win10. So using and distributing that doesn't need any advanced merge module installation step or registering.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Mike Gagnon]

Olaf
The only two products I know that deals with STARTTLS in Rick Strahl's product and Chilkat (

https://www.example-code.com/foxpro/socket.asp)

If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[Koen Piller]

Olaf,

It doesn't work

Please clarify "It"

Rgds,

Koen

 

[Olaf Doschke]

I did, just read on.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[quailco]

Olaf, Just so I get it right rather than searching and maybe not getting the right code; where is the VFPwwinsock code referred to as the best MAPI solution?
Jim

 

[quailco]

Koen, if you discover it does work or needs only something minor, do let me know and thanks for helping.
Jim

 

[Olaf Doschke]

VFPWinsock isn't a MAPI solution. Winsock does circumvent using any mail client and goes directly to a mail server. But it can't handle mail servers requiring SSL connections.

MAPI works, has a merge module you can distribute (if you're interested in distributing your software at all and don't just program for yourself). It only can't send HTML mails (or that depends on the mail client, but your Thunderbird is an example of NOT supporting the workaround).

ExtendedMAPI can do HTML mails, but isn't recommendable. At least not the FLL.

More details are in what I already wrote. If you don't understand something, perhaps point out what exactly puzzles you.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Olaf Doschke]

Also, quailco,

if you ask for my recommendation: I'd use the MAPI code (using msmapi.mapisession and msmapi.mapimessages or see sendmail.scx). That's why I brought it up. And for a solution needing no mail client installed use blat.dll or (perhaps easier to program) the blat.exe.

A pure VFP solution shouldn't be your major concern, just something redistributable and usable for all OSes. Any solution not needing a mail client will require you to ask for email server details and credentials. That's something many users working in a company just get set up and don't even know, so a MAPI solution has the advantage of not needing that. Any computer without an Internet connection wouldn't work for you anyway and show me a workstation or personal computer desktop without a mail client.

If your software is underlying privacy regulations using MAPI is also fortunate, as it moves part of the responsibility into the mail client, your application doesn't need to know and handle any secrets securely. Plus that client documents what you sent, so users have their control about that in the usual environment, their mail software. Any software circumventing that does not only need to secure sensitive information and keep it safe but also does not comply with legal aspects of business communications that requires the transparency of keeping track of both received and sent communication, for example. I also don't know what applies to you here.

If you only need this to send an email about the success of a daily scheduled task, as I once did, then this is internal use and does not fall under such legislations. And then you may even set up your own local mail server only for internal use and set it to simple authentication and configure it yourself for your software. For sake of simplicity, I'm a big fan of MAPI and otherwise, the simplicity Outlooks automation COM server offers, if you program for a company using that.

Mail clients can defend themselves from being automated by MAPI on one side (that's positive) and can be configured to allow usage. From the top of my head Outlook has options in its trust center to allow your software to automate it. So anything is done in consent. and you, for example, also don't need anything notorious.

There are always not just the technical aspects. You didn't tell anything about your needs and what you prefer or need.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[quailco]

Let me restate that.
Just so I get it right rather than searching and maybe not getting the right code; where is the MAPI code referred to as the best MAPI solution

 

[Olaf Doschke]

I gave one MAPI solution. You can learn more from the FAQ I referenced already: faq184-1769

Have you read that? Have you understood the captions saying what each code snipped does? The snippets are not alternatives you pick from that all do the same thing, they are for different aspects.

So there is no best. Different aspects need different code. I also just gave you the basics for sending a mail, see above.

where is the VFPwwinsock code referred to as the best MAPI solution?

You're still not getting that VFPWinsock is not at all using MAPI, it's using Winsock, which to mapi is the difference of starting at atoms instead of a meal you just need to warm up. Which should also explain why any winsock example has so much more code.

I don't know how I can make that any clearer.

The line [tt]oMessage.Send(1)[/tt] does trigger everything VFPWinsock does, making a connection and sending the mail. And it does more: Putting it in the outbox of the mail client, so it cares for all the parts you therefore don't need to think about at all, including not only the socket handling and connecting via SSL but also in case internet is down or the mail server is down repeating that, just like mail clients as Thunderburd do when a mail is in the outbox, until it's sent and put into sent items. And you don't need to care for all that.

Bye, Olaf.


Olaf Doschke Software Engineering

https://www.doschke.name

 

[Koen Piller]

Hi Qualico,

here is the link to the website of Francis, author of VFPWinsock : Link
Regards,
Koen

 

[quailco]

Thanks Koen