VFP Email
VFP Email
(OP)
I have been using the code from FAQ184-3840: How to send email using SMTP and no third party OCX? 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.
.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.
Talk To Other Members
RE: VFP Email
Just to be clear, you need to pass seven parameters - no more - just like in the example in the FAQ.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
RE: VFP Email
RE: VFP Email
The first time I crossed that error message I also understood the inverse. As you specify parameters in the call that sounds like you have too few parameters in the call. That can actually never be the case, as VFP has no concept of mandatory parameters in user-defined functions, you can always pass in fewer parameters than a function accepts.
The message should be: Too many parameters passed in.
The message actually addresses the function/procedure/method definition. The code could take in more parameters if LPARAMETERS would be extended. But it's the rarest case the calls are correct and the function defines too few parameters. So the perspective of that error message is wrong.
It could happen, that you change a function to take fewer parameters and then need to change all calls of that function to adapt to the consolidated parameterization. And therefore that's even rarely done, it's an incompatible change.
It's also no good idea to add dummy parameters to any (L)PARAMETERS so you get no errors when a call has too many parameters. That is an error and should be detected and so you don't program defensive against it. It's just an unfortunate case of VFPs dynamic nature that does not already throw an error at compilation about too many parameters in the call.
Bye, Olaf.
Olaf Doschke Software Engineering
https://www.doschke.name
RE: VFP Email
Bye, Olaf.
Olaf Doschke Software Engineering
https://www.doschke.name
RE: VFP Email
That's right. I had to think twice to convince myself that too many parameters were being passed rather than too few. You have to realise that the message is triggered by the incorrect number of parameters in the LPARAMETERS statement, even though the actual error occurs in the call (in this case).
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
RE: VFP Email
RE: VFP Email
Bye, Olaf.
Olaf Doschke Software Engineering
https://www.doschke.name
RE: VFP Email
RE: VFP Email
I think since the last time someone actually used that a lot happened. For example, authentication toward mail servers via SSL secured connections. And that's not covered.
See, that's the better thing in automating a client, you don't need to care for the connection to the mail server, you don't even need to ask users for any credentials.
Bye, Olaf.
Olaf Doschke Software Engineering
https://www.doschke.name
RE: VFP Email
RE: VFP Email
Port 25 would be for unencrypted SMTP, 143 for IMAP and 993 and 995 for the secure variants of them, that require TLS/SSL.
If you insist on needing no third party component, no mail client you can use via MAPI and want to do everything on the low level of the Winsock control, you need to implement the necessary steps to establish a secure connection yourself. I would not know how to, and I am not eager to go that low level for independence, I would rather use anything else like CDO or MAPI.
Of you just want to send mail in any way, there are tons of ways you can do it.
Bye, Olaf.
Olaf Doschke Software Engineering
https://www.doschke.name
RE: VFP Email
Do you have an opinion of this CDO method from the Fox Wiki explained in this link
http://fox.wikis.com/wc.dll?Wiki~CdoEmail
RE: VFP Email
Bye, Olaf.
Olaf Doschke Software Engineering
https://www.doschke.name
RE: VFP Email
RE: VFP Email
Maybe in shortest, without desiging a form using the MAPI Session and Messsages OCXes:
CODE
oSession = CreateObject("msmapi.mapisession") oSession.SignOn() oMessage = CreateObject("msmapi.mapimessages") oMessage.SessionID = oSession.SessionID oMessage.Compose() oMessage.RecipAddress ="recipient@example.com" oMessage.MsgSubject = "Test Mail" oMessage.MsgNoteText ="Test Text" oMessage.Send(1) oSession.SignOff()Bye, Olaf.
Olaf Doschke Software Engineering
https://www.doschke.name
RE: VFP Email
RE: VFP Email
Or in short: Yes.
Bye, Olaf.
Olaf Doschke Software Engineering
https://www.doschke.name
RE: VFP Email
Thanks Olaf
RE: VFP Email
All I know of you is what you wrote here. If you know fox for so long, you could have answered your last question yourself. It made the impression you're a beginner not knowing anything about programming. Any code can be done in a batch once it's without any interaction, can't it?
Just an obvious hint: You don't need to create the two MAPI COM objects for each mail, the core part is from compose() to send(1) and only that would need to be in a loop.
And then if you want to distribute that look into redsit.txt in HOME() to learn what you can redistribute and see it mentions MSMAPI32.MSM for distributing the MAPI OCXes. It's not just the msmapi32.ocx.
There are further ways, Craig Boyd once wrote 10 ways to send mail, and as you see there is more than one FAQ on how to send mail. What you found only has Winsock dependency and you would also need to ensure you distribute that (see MSWINSCK.MSM in redist.txt), it's only more common to be existing. Well, it was more common at the time that code was written. The main point though is, it assumes you only need simple authentication to the mail server and only implements the least few SMTP commands to send a mail and is still so much more code. The most sample code about sending mail you find does not do all that, as it's tedious and subject to change. A MAPI complient mail client will a) make the mail server communication for you and b) already be configured about mailserver, port, authentication, etc. You don't need to ask your users any security relevant informations, their mail client knows.
To send mail this way also is within VFPs own samples, by the way:
CODE
Bye, Olaf.
Olaf Doschke Software Engineering
https://www.doschke.name
RE: VFP Email
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
RE: VFP Email
>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
RE: VFP Email
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: How to get the best response from the forum first.
RE: VFP Email
Please clarify "It"
Rgds,
Koen
RE: VFP Email
Bye, Olaf.
Olaf Doschke Software Engineering
https://www.doschke.name
RE: VFP Email
Jim
RE: VFP Email
Jim
RE: VFP Email
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
RE: VFP Email
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
RE: VFP Email
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
RE: VFP Email
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.
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 oMessage.Send(1) 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
RE: VFP Email
here is the link to the website of Francis, author of VFPWinsock : Link
Regards,
Koen
RE: VFP Email