If you have a PC with Outlook able to send mail normally, you can go into the Account settings there and get all the information you need about server names etc. A user id and password is always required for incoming (usually POP3) mail, but usually not required for outgoing SMTP mail. However you can confirm this in the advanced tabs of the account settings.

First thing I'd do would be to go through all the account property sheets and make sure the settings you're using in the CDO2000 class are the same as what a working Outlook PC is using.

Next I'd check if anything unusual happened last week. Ask your network administrator if any changes were made to outgoing firewall rules, network security etc. Basically, ask them if anything they did over the last week or so could contribute to the issue you're seeing.

Also regarding firewalls, most PCs have them these days. If a PC firewall has been recently locked down, it may be that commonly-used apps such as Outlook are allowed to send mail, but your app may not be. You would need to configure the firewall to "allow" your app. Details on how to do this will vary depending on the firewall in use - again, many antivirus/Internet security suites contain their own.

>Thanks for your help.
>From the dos shell,is there a way i can ping the machine to find out what the smtp server name, userid, and password are?
>I don't know the syntax to get what I'm looking for.
>
>The attachment is fine, I shut the anti virus protection on the out going mail. We all access the same server here.
>The outlook mail and the internet mail are both working fine.
>
>It's sending mail in my program that's failing right here. It was working fine till last week.
>
> IF loMail.Send() > 0
> FOR i=1 TO loMail.GetErrorCount()
> ? i, loMail.Geterror(i)
> ENDFOR
> ELSE
> * ? "Email sent."
> lcmessage = MESSAGEBOX(PROPER(JUSTFNAME(ALLTRIM(lcattach))) + ' was sent.',0+64+0, APPNAME_LOC)
> ENDIF
>
>
>
>>>I am using Sergey's CDO 2000 email class.
>>>
>>>It's been working great.
>>>
>>>Friday, one of the user's had trouble sending out a proposal.
>>>I tested it on my machine and had the same problem.
>>>
>>>From within my Vfp application, I create a pdf package and email it.
>>>The email failed with the following error:
>>>
>>>1 ERROR: :1429 # send # 146
>>>The message could not be sent to the smtp server.
>>>The server response was not available.
>>>
>>>Do you know what the problem is?
>>>
>>>From what I've been told, the smtp server name, userid and password have not changed.
>>>Do I need to verify this?
>>>If so, how?
>>>
>>>Any help would be greatly appreciated.
>>>
>>>I'm using cdo2000.prg from 12/14/2009.
>>
>>Can your user successfully send e-mail using a regular e-mail client such as Outlook? If so, that means their ISP's outgoing (SMTP) mail server is OK and there is some issue either with that user's PC or with your program's e-mail sending technique. If not, then something has changed with the SMTP server.
>>
>>When you're testing, are you on the same network as the user who's having the problem, or at least using the same ISP? If you're not using the same ISP chances are your tests won't help diagnose the problem, because to reduce spam the vast majority of ISPs don't allow SMTP "relaying". For example:
>>
>>- Suppose your user's ISP is yyy.com. Almost always, yyy.com will require that any outgoing mail messages be sent to their SMTP server, usually something like mail.yyy.com or smtp.yyy.com.
>>
>>- Suppose you're using a different ISP, zzz.com. Likewise, your ISP will require that any e-mails you send go through their SMTP server e.g. mail.zzz.com or smtp.zzz.com.
>>
>>- If, for test purposes, you try to send a mail and you've specified the SMTP server to be mail.yyy.com, then there are at least 2 chances it will get rejected:
>>
>>- maybe immediately by zzz.com's SMTP server, which might refuse to relay it to yyy.com's SMTP server
>>- maybe by yyy.com's SMTP server, which may refuse to accept mail that has been relayed
>>
>>In either case, you could get a misleading test failure.
>>
>>Some more things worth checking:
>>
>>- How large are any attachments that are being sent? For maximum reliability total attachment size should not exceed 3MB or so. In some cases you can get away with 5MB, and in a few special cases you might get 10MB or even more, but those are only with some ISPs and when sending strictly within the ISP i.e. from address1@bigemailisp.com to address2@bigemailisp.com.
>>
>>- Most antivirus/Internet security suites these days include e-mail scanners, for both incoming and outgoing mail. If that's present, for test purposes try disabling at least the outgoing message scanning.