Local Personal SMTP Server

[stanlyn]

Hi,

I'm looking for a small and local (on same machine) SMTP service or app that always runs outside of VFP on the same machine so that when I send an outgoing email from my VFP app, this service or app intercepts and contacts the actual smtp server for delivery. My app remains completely responsive at all times even when there are network, smtp or other external issues. I'm using it to send error emails with screenshots back to us.

Currently I send it to the smtp server directly from VFP and because now I'm including screenshots in the emails, the app is tied up for way too long, like 30-40 seconds for a 3.5mb screenshot file. I want the app to only prepare the email and hand it off to this ??? (that is outside my app) and continue doing what the app does with zero user delays...

I briefly look at the "VFP Parallel" processing articles a while back and wondering if that is overkill for this task?

I also looked at SmtpQ product from ChilKat which does exactly what I want, except it is only available in 64b...

Something simple is preferred?

Any ideas?
Stanley

 

[stanlyn]

Hi Olaf,

>> I'd always use the more versatile gdiplusX.
I'll check that out...

>> How did you measure the tie up of your application?
Not sure what you mean here

>> How do you send mails so far,
Originally, I used blat directly to SMTP server, and now I've changed it to ChilKat directly to SMTP server

>> do you automate Outlook or another mail client via MAPI?
This may well be the best solution, by configuring the smtp component of the local mail client. Then sent the mail to localhost.

>> If I try to attach a 160MB attachment to a mail item, Outlook errors with size too large, even before sending. So such limitations are not only about mail servers.
That is why I said "thats another issue altogether...

I've sent in a request to see if ChilKat is building a 32 bit version of SmtpQ product which works seamlessly with their smtp control and would require no external installs or configurations. I'd store the smtp server info in my app and thats it... Currently they are only showing a 64bit version.

Thanks,
Stanley

 

[strongm]

>uses a link back to microsoft

That isn't a link (URL), I'm afraid; it's a local namespace indicated by a URI. And, to be honest, you really don't need to worry about it, as the CDO library provides nice aliases for all
the URIs.

>So, any idea on how to run the local smtp app on all playforms since XP?

That sounds somewhat patronising. I wouldn't have mentioned it if I didn't know how to make it work (and it isn't an app) Here's the main MSDN documentation. And here's just one of many threads in the VB6 forum on using it in VB (which should be close enough for translation for use in FoxPro); the code is in my post, about 2/3 of the way down: thread222-1143694

>nowhere in the "Feature Listing" do I see anything about SMTP... The only place I see SMTP is by selecting a site inside IIS.

Why would you expect there to be one? There's no feature listing for ADO, either, or ODBC, as these are provided as libraries, not applications.

 

[stanlyn]

Hi strongm,

I still have the same issue when executing this CDO code... VFP hangs until .send() finishes executing. I'm using a 3mb file to test with, so I can see if its immediate...

TRY
  LOCAL lcSchema, loConfig, loMsg, loError, lcErr
  lcErr = ""
  lcSchema = "[URL unfurl="true"]http://schemas.microsoft.com/cdo/configuration/"[/URL]
  loConfig = CREATEOBJECT("CDO.Configuration")
  WITH loConfig.FIELDS
    .ITEM(lcSchema + "smtpserver") = "smtp.server.net"
    .ITEM(lcSchema + "smtpserverport") = 25		&&465 && ó 587
    .ITEM(lcSchema + "sendusing") = 2
    .ITEM(lcSchema + "smtpauthenticate") = .T.
    .ITEM(lcSchema + "smtpUseSSL") = .F.
    .ITEM(lcSchema + "sendusername") = "me@site1.com"
    .ITEM(lcSchema + "sendpassword") = "bogus"
    .UPDATE
  ENDWITH
  loMsg = CREATEOBJECT ("CDO.Message")
  WITH loMsg
    .Configuration = loConfig
    .FROM = "stanley@mysite.com"
    .TO = "test@drem.com"
    .Subject = "Testing CDO"
    .TextBody = "This is some text for the text body..."
	.AddAttachment('D:\CPOS\Server\temp\test.png')

    .Send()
  ENDWITH
CATCH TO loError
  lcErr = [Error: ] + STR(loError.ERRORNO) + CHR(13) + ;
    [Linea: ] + STR(loError.LINENO) + CHR(13) + ;
    [Mensaje: ] + loError.MESSAGE
FINALLY
  RELEASE loConfig, loMsg
  STORE .NULL. TO loConfig, loMsg
  IF EMPTY(lcErr)
    MESSAGEBOX("Email was successfully sent...", 64, "Congrats")
  ELSE
    MESSAGEBOX(lcErr, 16 , "Error")
  ENDIF
ENDTRY

Any other idea?

Thanks,
Stanley

 

[Olaf Doschke]

If you send directly to SMTP of course your app ties up. It would already help to put this into a separate EXE, as I suggested right away.

If you automate a mail client you also don't send to localhost, you send a mail and it's the job of the mail client to send it to its configured mailserver, including repeated tries, if there currently is no connection. That is your benefit of going that route, you don't need to program these things and leave it to the mail client. Anyway, the network is used up and if the tie up would rather be about the network load of the mails this also won't help. But my experiments with large attachments show me Outlook comes back from send right away, before the send process finishes. Outlooks small popup windows fading in in the lower right corner appear afterwards - more important ? oMail.Send() puts .T. on the _screen rightaway.

That means your app continues working quite instantly, though I doubt that's very useful in case of an error. My general error handling displays the error to the user and finishes the app then, so it needs to be restarted. You can't continue on any broken conditions, I don't do anyway.

The downside of automating a mail client is, that the communication is revealed very obvious to users, as mails are kept in the sent items.

Anyway, FTP is the better protocol for files, mail attachments always are mime encoded in base64 encoding, needing 4 bytes to transfer 3 bytes (base64 also is known as 3-in-4-bytes encoding putting the 3x8bits of three bytes in 4x6bits of a reduced charset of readable characters allowed in mail protocols. In FTP you can do binary transfer. and you may simply tranfer a txt file accompanied by a separate jpg file instead of a mail.

Bye, Olaf.

 

[strongm]

>it's the job of the mail client to send it to its configured mailserver, including repeated tries, if there currently is no connection. That is your benefit of going that route

Quite so. If we are doing SMTP ourselves, then we would need to manage the whole process (whether synchronously or asynchronously).

>30-40 seconds for a 3.5mb screenshot file

That's ... high. Testing here against (local) SMTP gateway shows about 2secs for a 3.5mb file. Whilst I appreciate that there'll be some additional overhead for transfer to a remote SMTP server, it shouldn't be this high; testing against a busy ISP's SMTP mail gateway provided figures of around 7 seconds.

 

[Olaf Doschke]

Well, strongly depends on the bandwidth your ISP gives to you, especially as upload bandwidth. Many have an asynchronous connection with far less upload than download rate.

Besides that, there are several levels of doing SMTP directly, using CDO.Message you don't profit from the mail client logic, but at least it covers doing all the SMTP protocol messages for you. You could even go lower level and program the SMTP protocol, but I'd not recommend that, unless it'll be fun for you to read several RFCs and do some low level programming.

Nothing is wrong or right in what you use, you'll usually have reasons for the one or other. It's untrue though, that CDO is part of the OS. If you don't have certain software installed in Vista or higher, you don't have CDO.Message available.

Whenever you do the mail sending as a separate invisible background process, you only take the resource of bandwidth usage, but you won't have to care much, if the upload bandwidth is far less than the LAN bandwidth anyway.

You know the list of possibilities to send mails at the fox wiki or at craig boyds blog? I have pointed to these resources in many occasions.

Bye, Olaf.

 

[strongm]

>If you don't have certain software installed in Vista or higher, you don't have CDO.Message available.

Yes, you do. CDO for Windows 2000 has been available as a system component since XP SP1, and was retrospectively added to XP through a Windows Update. Do not confuse it with CDO for Exchange 2000 or CDONTS or CDO 1.2.1

 

[Olaf Doschke]

I often enough see people ask and see others answer this only comes with Outlook or Exchange or was discontinued. Yes, may well be about higher CDONTS, but those questions also were about the CDO.Message COM object, and there shouldn't be two. Just google it, I just found it depends on access to registry and other policies, so there are barriers.

Anyway, there are vast possibilities to send mail and you need to understand that some are done synchronous or asynchronous, "managed" or "unmanaged" (not in the CLR vs non CLR sense of the term, but in how mails and SMTP settings are handled by mail clients).

Bye, Olaf.

 

[strongm]

> see others answer this only comes with Outlook or Exchange or was discontinued

They are incorrect and/or talking about different libraries. This is mostly Microsoft's fault, as they tend to call them all the same thing. For example, CDO 1.2.1 is a COM wrapper for Extended MAPI, and does not target SMTP at all. It was originally called Active Messaging, until MS re-branded (And is indeed pretty much obsolete, although you can still download it from MS if you want ...)

>I just found it depends on access to registry and other policies, so there are barrier

I've been using the Microsoft CDO for Windows 2000 Library successfully for almost 15 years on pretty much all Microsoft operating systems ranging from XP all the way through to Window 10, from Windows Server 2000 to Windows Server 2013, and never encountered any 'barriers' to using the library such as you describe. Nor ever a requirement to install anything to get access to the library.

>some are done synchronous or asynchronous, "managed" or "unmanaged"
Yes

 

[GriffMG]

Stanlyn

I was answering the question about getting the virtual SMTP server working in Windows.

The Virtual offering is poor, as if MS just can't be bothered any more. You even have to
manage it through an old management console.

You have to install it as an optional feature in Windows, probably under IIS somewhere.

MailEnable on the other hand is very popular, free (in some circumstances), and does the job very
well indeed.

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are not good for you. ​

 

[Olaf Doschke]

Well, to give an example: I just read KB910360 and you might simply say this is about situations you could also have with other COM Servers like Word.Application you also see from time to time. Anyway, these are errors your application will come across and your users will ask you to resolve, even though it's about a bad Windows or Office installation or a dependency not in your control.

Blat is really simply and not depending on much more than the C runtime, in contrast.

I fear I am not heard here anyway. I wonder why you'd want to install some virtual mail server or samtpQ if all you need is to first log error info into a dbf and store jpgs on the file system, somewehre you can always rely on and then have a secondary EXE simply iterating this data and marking records as done after successfully sending them, if via mail or FTP.

The professional way to do this would be looking for a bug tracking system and see how to set it up on your own homepage or servers and what API it supports to put in bug reports manually by customers or automatic by your software and that's beyond sending mails or ftping pictures anyway, it'll allow tracking of activities about the bugs and reporting back to customers. They also might give feedback on top of system errors only.

Bye, Olaf.

By the way: What wouldn't work becasue Chilkat SMTPQ is 64bit? It's not a library you include into your software. It's a Windows Service watching over a directory. You can put files into a directory, can't you?

 

[strongm]

> you might simply say this is about situations you could also have with other COM Servers

That's exactly what I'd say. Both the registration check and the registry permissions are typical troubleshooting steps for any broken COM library, and not a specific problem with CDO.

And the 3 other issues (bad/wrong SMTP server, SMTP server not allowing mail relaying , or bad/wrong email address) would affect any SMTP solution; again, not specifically the CDO library

>these are errors your application will come across

Not encountered this issue with the CDO library in 15 years, and hundreds of machines. Nor can I find example of anyone else actually acknowledging that either of those issues had affected them, . Your mileage may differ.

Blat is great - but as likely to be susceptible to all of the same problems as the CDO library (e.g Blat reads and writes from HKEY_LOCAL_MACHINE\SOFTWARE\Public Domain\Blat so could suffer a registry permissions problem) except for bad registration.

>I wonder why you'd want to install some virtual mail server
I agree. This wouldn't be the approach I'd take

>or FTP
Not sure I'd use FTP, though. It's unsecure, and many businesses will not allow it through their firewalls these days. Plus you need an FTP server such as FileZilla (and probably a decent FTP client)

>What wouldn't work becasue Chilkat SMTPQ is 64bit?
THe OP did point out that it needed to be able to run on XP (and let's be honest practically no-one is or was running XP 64bit, so we can safely assume this is a 32bit environment)

 

[stanlyn]

What I'm trying to achieve here is an emailer solution that can email large attachments from within VFP and return control to the user immediately with no wait... Both 32bit and 64bit machines must be supported starting with XP and all other OSs going forward. It must be able to deliver the email while dealing with downed internet, broken network, bad addresses, banned port 25, relays, and pretty much everything an email client must do to get the mail through.

If I was only trying to get error info back to the office, I can think of many different mechanisms to accomplish that. It just so happens that I'm working on the email system that for years has been blat based and it too suffers for VFP tieup when sending large emails. I also stated that my extra time spent on this solution is needed on some other projects that requires it be in email format that will be handling large files.

My dev machine is 64bit and last night I got to play a little with ChilKat's SMTPQ in fox. It currently is available only in 64bit and they are finishing up a mixed 32/64 SMTPQ version. I'm having a few issues with it sending the mail to the smtp server, but I'm testing and figuring it out. It does however solve the VFP tieup issue as it is truly immediate. I never noticed a lag of any kind and the email is in the queue folder.

Now, how can we use CDO as I really like the idea that it is included on all OSes since XP to current. (kinda like notepad.exe) I'm sure its very stable as well, given the iterations its been through. Many of the CDO documents that you posted links to are being redirected to a Microsoft catchall page, so I still haven't seen any methods or ways to implement other than what I found on Craig's and Fox???? pages which is where I pasted the above code from. And how can CDO return immediate control back to a VFP user? Or am I still going to need something like the smtpq product?

Another interesting about the ChilKat's email and smpt product offerings is that I can easily build the routines to get into about any smtp, pop, or imap server with tls, ssl, and even http proxies. And seamless.

What really sets it apart from everything I've tried so far is what SmtpQ brings to the table and that is what I'm asking everone's opinion in how to solve this in an email solution.

And yes Olaf, you ARE being heard... And I highly value everyone's experience here!

Thanks for ALL the input,
Stanley

 

[stanlyn]

Hi strongm,

What exactly is the CDO library used for other than composing the email's header and body?

In solving the VFP tieup issue, how would CDO differ from blat or whatever else?

As far as speed, most of our customers use a business class dsl service with down=6mb and up=512kb. That would explain the 30-40 seconds for a 3-4mb file. And that is simple too painful.

I also really don't want to build an external .exe as that would be worse than using some virtual smtp server, correct?? Olaf, how would you pass the email to the 2nd exe? What would your program flow look like?

Also note that the smtpQ product is NOT a smtp server. He is a link to: SMTPQ

Thanks again,
Stanley

 

[Olaf Doschke]

>I also really don't want to build an external .exe as that would be worse than using some virtual smtp server, correct?? Olaf, how would you pass the email to the 2nd exe? What would your program flow look like?

Read back, what I already wrote.

No, why would a secondary EXE be bad? Is an SMPT server no further EXE? The only advantage it has is caring for the mail as a mail client also does, but it's even more complex than a secondary mailsender EXE. You can use the code you already have, so it's not a big effort, it's more complex to integrate the setup of a secondary full blown server service into your apps setup than it is to put another EXE aside of yours, is it?

In regard of how the other EXE would get the email, simply read back, I gave several ideas. You don't need to pass anything directly to it, your current code already knows what to send, doesn't it?

The upload rater is what limits the upload time of your mails or files, that's something you can't change. Putting the upload into another EXE or server or tool like SMTPQ (I know it's no SMTP server, but it acts automatically) you gain the respionsiveness of your app, because all the sending is done in a secondary process in background. It won't take away much from the bandwidth for all other data access, as 512kbit is merely 0.5% of a 100MBit LAN and even only 0.05% of a GBit LAN, so you don't have to fear anything, the time delay between error and receiving a mail will be several minutes anyway, as a mail travels.

In regard of safety: Mail is the worst thing you can do, it rather compares to sending post cards than enveloped letters unless you encrypt mails. Mail servers supporting SSL connection will actually receive mails transfer encrypted - true. But there are more connections and transfers involved than client to mail server, at least two more, from mail server to mail server (there can be several transfers involved here) and finally downloading the mail from your side.

On the other hand, if you as a freelancer or business own a website you have FTP access (that also includes SFTP or FTPS most of the time) and can put files there more directly. @strongm: You're right, that companies might block FTPs port 25, but talking about FTP you take the protocol too literal. Finally if that is a concern, then don't talk about mail at all. Indeed a screenshot may contain business secrets, even from your own application only, if not from other windows appearing on it.

Bye, Olaf.

 

[strongm]

>And how can CDO return immediate control back to a VFP user?

Sadly the CDO for Windows 2000 library doesn't expose this functionality, although .NET's System.Net.Mail provides synchronous and asynchronous version calls. So it will indeed suffer the problem you mention - unless you can launch it on another thread. Unfortunately, as far as I am aware, VFP is not very good at multi-threading. Which leads to Olaf's suggestion of running the SMTP component in a seperate EXE.

 

[Olaf Doschke]

>e.g Blat reads and writes from HKEY_LOCAL_MACHINE\SOFTWARE\Public Domain\Blat
It's optional, you can use blat without registry, you can specify all configuration as parameters or as configuration files (and specify these as a parameter).

It's a matter of taste and what code works for you and what you already have to put in a mailsender.exe

Bye, Olaf.

 

[stanlyn]

Olaf,

Ok, thinking out loud...

To do this with an secondary exe, I would...

1. create a prg that contains all the smtp stuff,
2. compile it into a smtp.exe executable,
3. when sending the email from the main app, issue "run /n smtp.exe with par1, par2, par3, par4......." with the parameter list that contains server, authentication stuff, body and other related things.

That should do what I'm looking for... Am I thinking right, am I missing something with this? If its that simple, then great and many thanks!

Thanks,
Stanley

 

[Olaf Doschke]

Why? Your normal EXE does not need to know any stuff about SMPT server, port etc. That is all put into your secondary EXE. You only need to know where the screenshots are, that your main exe still needs to make, because of course it's still the EXE that triggers the screenshot by having an error event. The knowledge about the SMPT server etc can all be put into the secondary EXE and if you like you can make that configurable.

You can also use parameters, but it's your world. You create whatever you want or need. The only thing the other EXE needs to know is where to find the attachment files to send, because that is the only thing coming from the main exe. The main exe doesn't need to know or to tell your mailing exe where to send the pictures.

Simply think about encapsulation rules, why would you put the info about what SMPT server to use etc outside of the EXE that does the sending? That is only needed, if you want to program a general SMTP sender. And you surely don't want to go as far as creating an SMTP server being able to process SMTP protocol and connections to it, you only do a mailsender.EXE. or a bugfilesender.EXE

Bye, Olaf.

 

[Olaf Doschke]

One more detail:

Your current code surely does make the screenshot, save it to disc somewhere (eg in TEMP) and the mail code picks that upwhen it adds the attachment by specifying the picture filename.
This is where you split up your code, your exe still creates the picture file, your mailsender EXE will simply use ADIR on a knwo directory of just the files you want to send. Or you use a DBF, or you use XML, or a SQL Server table or whatever you like. But don't start an EXE per mail you want to send. Make it a batch process, erasing the files its done with or the data it iterated or moving it to a "processed" folder.

Bye, Olaf.