CDONTS and SMTP server

  • Thread starter Thread starter Philip Morgan
  • Start date Start date
P

Philip Morgan

I have run into a new problem sending a CDONTS email from Access
because it appears our local SMTP servers (on the workstations) are
not connected to the Outlook Exchange servers which ultimately deliver
the mail.

We know our CDONTS code is functional because it works fine on the
server side ASP pages (hence the servers must be connected to the
Exchange servers because it delivers into Outlook).

However, I have been unable to figure out how to call/send the CDONTS
code at the server level from Access.

If I include "Server" in the CreateObject line, I get an error back
indicating the server can't send the object and points to the send
line (e.g. Set userMail = Server.CreateObject("CDONTS.NewMail")). If I
remove the server part, it reports it cannot create the object.

So I have been trying to call an ASP page as an Access Data Page, but
it won't recognize the .asp suffix (requires HTML?).

The code is not the issue... but here it is anyways (stripped down
test version)

Dim userMail
Set userMail = Server.CreateObject("CDONTS.NewMail")
userMail.To = "(e-mail address removed)"
userMail.From = "(e-mail address removed)"
userMail.Subject = "test"
userMail.Body = "test"
userMail.Send
Set userMail = Nothing

Question: How can you call an ASP page from within Access, or (b) get
the CDONTS code working at the local level?

Many thanks for any assistance that you could provide.

Phil Morgan
 
Philip

Perhaps it's just time for you to find another way to get this done. If you
can live with out sending attachments, consider creating a file in your SMTP
servers pickup directory. A method that I have used with great success for
several years is to drop a carefully formatted text file in the pickup
directory of an exchange server or IIS server. My motivation for sending
mail this way was not having to rely on the user having a MAPI aware mail
client for the application to be able to send mail. Here is some code:

Public Function SendMail(strRecipients As String, strFrom As String, _
strSubject As String, strBody As String) As Boolean
' Purpose Send an Email
' strRecipients should be formatted
"Name"<EmailAddress>;"Name"<EmailAddress>; ect
' strFrom Should have the same format if you want the recipients
to be able to reply
' Otherwise you can have it say anything.
' - Uses Special Exchange Server watched Folder to make it happen
' - This way both the Program and the Client are completely MAPI
Un-Aware.
' - Big Disadvantage to this method is all users MUST have access
to
' the watched Exchange folder.
' - Does NOT Support Attachments
Dim strEmailMsg As String, strPathname As String
Dim intFileNumber As Integer

On Error GoTo errSendEmail
' Get the Mail Drop Directory
strPathname = DLookup("MailDropPath", "tblLocal", "LocalID=1")
If Right(strPathname, 1) <> "\" Then
strPathname = strPathname & "\"
End If
' Create Email String
strEmailMsg = "From: " & strFrom & vbCrLf _
& "To: " & strRecipients & vbCrLf _
& "Subject: " & strSubject & vbCrLf & vbCrLf _
& strBody
' Send it!
intFileNumber = FreeFile
' Create a File in the Pickup Directory
Open strPathname & "DimSend" & Format(Time(), "hhmmssnn") & ".txt" For
Output As #intFileNumber
Print #intFileNumber, strEmailMsg
Close #intFileNumber
SendMail = False ' No Error
Exit Function
errSendEmail:
SendMail = True ' Error
End Function

Obviously if you need to send attachments this aint the way to go. I use
this code to send messages (typically to me) when something goes wrong with
one of my apps. Often times I know about a problem and have it fixed before
my customers help desk gets a call from the users. Good luck.

Ron W
 
Philip Morgan said:
I have run into a new problem sending a CDONTS email from Access
because it appears our local SMTP servers (on the workstations) are
not connected to the Outlook Exchange servers which ultimately deliver
the mail.

That sound logical. What happens when you configure your SMTP
services so that they can send mail?

(david)
 
Part of my previous post was to work out in my head (and on the
screen) what I suspect the problem is (1/2 of solving a problem is
clearly defining it..). My hopes were also that someone would spot any
errors in my assumptions (as I ma NOT a server/SMTP guru).

I agree with David's suggestion that configuring the desktop SMTP
services would probably solve the problem. However, that would require
a massive undertaking by our Desktop Services department - it ain't
gonna happen.

So still looking for a solution... but I don't think it's going to be
down this road.

Thanks for your help nonetheless.

Cheers!

Phil
 
Now that MS have released a replacement, CDONTS is just
another obsolete technology.

As it happens, I've use MAPI, WinSock, and File Drop, but
CDONTS has never been functional on the client workstations.

The major problem with using MAPI is the outlook
security problems. It's never been a problem for me,
because I've never wanted to do anything other than
dropping mail into the outbox.

The major problem using File Drop is getting support
from IT, and the major problem using WinSock is buying
the third party toolset.

(david)
 
(snip)
Though I've not used it, I've heard good things about BLAT which does not
need Outlook or any other MAPI client. It is a small stand-alone exe that
you can throw in your system folder.

It also comes as in a DLL version that can be called late-bound: no
references. Just load it from your application's own directory, using
LoadLibrary().

*BUT*, BLAT's error handing is terrible. Error 1 means, "Could not
connect to SMTP sever -or- recipient address rejected (but I won't
tell you why) -or- your brother's hat is on the wrong peg". Error 2
means, "Winsock error -or- specified file not found -or- can not
deliver emails on Wednesdays", ... You get the idea! Unless you want
to write code to parse the BLAT log file, all you get is error codes -
and many of the codes cover multiple errors, so you really don't know
what error occurred.

I decided not to use it, for that reason.

HTH,
TC
 
It also comes as in a DLL version that can be called late-bound: no
references. Just load it from your application's own directory, using
LoadLibrary().

*BUT*, BLAT's error handing is terrible. Error 1 means, "Could not
connect to SMTP sever -or- recipient address rejected (but I won't
tell you why) -or- your brother's hat is on the wrong peg". Error 2
means, "Winsock error -or- specified file not found -or- can not
deliver emails on Wednesdays", ... You get the idea! Unless you want
to write code to parse the BLAT log file, all you get is error codes -
and many of the codes cover multiple errors, so you really don't know
what error occurred.

Within a, hopefully, short period of time, there will be verification
that the mail server who allegedly sent the email actually is the
sender. Sounds like using keys in the DNS system is the process that
will be happening.

When this comes in place all mail not sent via your ISP or email
server which will add an authentication key to the email will be
suspected to be a spam and treated accordingly.

And I will be on that bandwagon as soon as it's available. <smile>

Thus blat may no longer be of much use after this is all in place.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
 
One option is to use a 3rd party SMTP component that can connect to your
mail server over the network. You can get one with no dependencies so that
the MS SMTP services are not needed nor is outlook or any other mail client.
Take a look at http://www.quiksoft.com/objects/smtp/

Bill
 
Bill said:
One option is to use a 3rd party SMTP component that can connect to your
mail server over the network. You can get one with no dependencies so that
the MS SMTP services are not needed nor is outlook or any other mail client.
Take a look at http://www.quiksoft.com/objects/smtp/

Thanks for the link. Added to the Access Email FAQ.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
 
Tony Toews said:
Within a, hopefully, short period of time, there will be verification
that the mail server who allegedly sent the email actually is the
sender. Sounds like using keys in the DNS system is the process that
will be happening.

When this comes in place all mail not sent via your ISP or email
server which will add an authentication key to the email will be
suspected to be a spam and treated accordingly.

And I will be on that bandwagon as soon as it's available. <smile>

Thus blat may no longer be of much use after this is all in place.

Tony


Hmm! Just saw your reply. Hope you see this one.

Are you saying that in your opinion, the new verification methods will
come in at the client end? That is, the *client* software (Outlook,
Eudora, BLAT, or whatever) will need to be modified?

My assumption was, that the new methods would come in at the
*originating mailserver* end. That is, the client software sends an
SMTP request to the appropriate ISP mailserver, in the existing
manner. The mailserver decides whether or not to accept that request,
in the existing manner (eg. using IP address checking). Then the
mailserver does some new tricks to authenticate itself to other serves
down the track.

If your view on this is correct, then, things like BLAT will need to
be modified. But if mine is correct, they will continue to work
unchanged.

This issue is important to me, because I'm in the process of adding
"mailmerge to email" functions to my main product. I don't want to use
MAPI or CDONTS, so I've decided to go the "email directly from VBA"
track.

Any comments?

Cheers,
TC
 
BLAT is a mail server. If mail servers need authentication,
then BLAT will need to be modified to handle authentication.

BLAT is a tiny client side mail server, and if authentication
is too heavy a burden, there won't be any advantage over just
running the Microsoft SMTP service on each client PC.

(david)
 
Hmm! Just saw your reply. Hope you see this one.

Are you saying that in your opinion, the new verification methods will
come in at the client end? That is, the *client* software (Outlook,
Eudora, BLAT, or whatever) will need to be modified?

My assumption was, that the new methods would come in at the
*originating mailserver* end. That is, the client software sends an
SMTP request to the appropriate ISP mailserver, in the existing
manner. The mailserver decides whether or not to accept that request,
in the existing manner (eg. using IP address checking). Then the
mailserver does some new tricks to authenticate itself to other serves
down the track.

To me though IP address checking will not be sufficient now or in the
future. You should be required to give the SMTP server a password.
Otherwise the viruses will then locate your ISP settings and start
sending viruses via the ISP SMTP server. Hopefully your email
software will have your password securely encrypted.

That said I feel that ISP email software should start having virus
deletion in place on incoming email along with limits on qty of emails
which can be sent. Ie 100 per hour ought to be sufficient for anyone
If your view on this is correct, then, things like BLAT will need to
be modified. But if mine is correct, they will continue to work
unchanged.

But then blat will likely be changed. It shouldn't take too much to
add the userid and encrypted password parameters.
This issue is important to me, because I'm in the process of adding
"mailmerge to email" functions to my main product. I don't want to use
MAPI or CDONTS, so I've decided to go the "email directly from VBA"
track.

I'd go directly from VBA in Access anyhow. Presumably going directly
to the WinSock via API calls? This way you have complete control and
store all the settings within your product.

FWIW I have some TCP/IP VB URLs at my website.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
 
Hi David

With respect, I'm not sure that is correct. As I understand it, an
email client such as Outlook or Eudora is not a mail server. It is a
program that sends SMTP commands *to* a mail server. Other programs
can be used for that purpose. BLAT is one such other program. Just
like Outlook & Eudora, BLAT uses the winsock API to send SMTP commands
*to* a designated mailserver.

Similarly, I can telnet to my ISP's mailserver, & manually enter SMTP
commands which cause an email to be sent. Telnet is not a mail server.
BLAT just does what telnet allows, but using a command-line interface
instead of interactive data entry.

Not trying to start an argument here :-) Just wondering what the
impact of these authentication changes will be, on some new features
that I'm about to add to my main product.

Sorry for the slow response, I only have google access at present,
which makes newsgroup posting slow & painful.

Cheers,
TC
 
Simple Mail Transport Protocol is a protocol for sending and
receiving mail.

A server is ......

A client is ......

If you look at the connections supported in MS Outlook, you can
see that it supports several different protocols - including, i
think, file drop for working with a network mail server.

We do use mail clients as mail servers: OLE automation,
OLE 'Server', OLE 'Client'. The security stuff makes it
difficult to use MS Outlook as a mail server.

We don't use mail servers as mail clients: a mail client is
a user interface for reading mail.

BLAT is a simple mail server: you use one protocol (win api)
to connect to it, and it uses another protocol (SMTP) to
communicate with the next mail server.

The MS SMTP service is another mail server: you drop well
formed mail packages into it's send folder, and it uses
SMTP to communicate with the next mail server.

A mail client or server that uses SMTP (called 'internet mail'
in MS Outlook) may need changes in the brave new world. Or
your ISP may configure their mail server to accept
unauthenticated SMTP mail from local IP addresses.

There are a couple of authentication/security initiatives
operating in parallel at present: authentication addresses
copy protection, virus problems, and spam problems. Secure
authentication operates 'end-to-end' and includes both
client and server authentication.

MS has made it difficult to use MS Outlook as a mail server
by requiring user interaction. But next, expect authentication
to be embedded into the operating system (Windows), and expect
to be able to configure MS mail servers to accept mail only
from clients and servers that are operating in Authenticated
mode.


(david)
 
Still not sure that I agree with you about mail clients & mail servers
:-)

As I see it, a mail client uses a client protocol like POP3 (RFC 1939)
to retrieve mail from a mail server, then render it for the end-user:

(1) user <--text--- client <--POP3--- server

In contrast, a mail server uses server protocols like SMTP (RFC 821)
to transfer mail across the network:

(2) ---SMTP--> server ---SMTP--> server ---SMTP--> server

A mail client can certainly >originate< mail, and for that purpose, it
must use SMTP, not POP3 (which is a retrieval-only protocol):

(3) user ---text--> client ---SMTP--> server

But the key difference is, the mail client does not >transfer< mail
from other clients or servers. It does not work like (2) above. It
only works like (3) above. The fact that it might be automatable (like
Outlook), is irrelevant to this definition, IMO.

BLAT has no ability to work like (2) above. It only works like (3)
abive. For that reason, you really can not call it a mail server, IMO.
Just like other email clients (Outlook, Eudora etc.), BLAT can
originate mail, but it can not transfer existing mail across the
network - the key role of a mail server.

Cheers,
TC
 
Back
Top