Our SMTP server (Microsoft Exchange) does not allow for open access.
We disabled that option years ago when hackers began to use the server
to annonymously send spam emails.  Thus we do not intend to open up this
option again.

My personal ISP (RoadRunner) also requires authentication.

I have tried adding code to open a POP3Client() connection immediately
prior to connecting via SMTPClient() and I still get the following error:

=================================================
Info: Socket created successfully
.
.
.
Info: Sending: RCPT TO: asinet@de.alaska-software.com
Info: Server response: 550 Relaying is prohibited
Error: Unexpected response from server 5
Message transmission failed
Info: Sending: QUIT
=================================================


NOTE:  Most SMTP servers in today's world do require some
              authentication.  In some cases that is met by requiring
              that the sender be logged into the local 'domain'.  Since
              that is not a universally available option, the ability to
              authenticate via the SMTPClient() object is very critical.


Will this feature be available soon in an update to ASINET?  If not,
does Alaska have an "open" SMTP server that I can use to send
email?


Please help guys.  It hurts to be this close to a solution, and yet so
very far away...!!!

John McDermon
Rural Hall, NC

>Our SMTP server (Microsoft Exchange) does not allow for open access.
>We disabled that option years ago when hackers began to use the server
>to annonymously send spam emails.  Thus we do not intend to open up this
>option again.

One option you might use is to create a local mail server that only
accepts connections from the local domain or even the same machine.
This can be used to allow anonymous connections (e.g. Xbase++
programs) to deliver mail.

This server then forwards all mail to a regular mail server (e.g.
Exchange), having an authenticated login (account) with that server.
You could set that account to allow delivery beyond the domain.

I use 2 Mailtraq servers - both of which think they are the primary
mail server for the domain "idep.org.uk", both deny mail relaying, and
both collect from a multitude of pop3 accounts (they both deliver to
the same smtp account).

If you think that's a hairy set-up, only ONE of them handles the
mailing lists...

Anyway, at one stage I had the problem that one of them would deny
relaying (I couldn't find the toggle), so had to forward mail to the
other - so this situation can work.

Regards,

"Phil Ide" <phil@idep.org.uk> wrote in message
news:3d471d2b.52388961@nntp.idep.org.uk...

> One option you might use is to create a local mail server that only
> accepts connections from the local domain or even the same machine.
> This can be used to allow anonymous connections (e.g. Xbase++
> programs) to deliver mail.
>
> This server then forwards all mail to a regular mail server (e.g.
> Exchange), having an authenticated login (account) with that server.
> You could set that account to allow delivery beyond the domain.

This is all well and good - IF all you want to do is create a program that
will work in a specific in-house environment.  But what about creating a
program that will work from any PC anywhere?  As long as the user has access
to a valid SMTP server and a valid user account, the software should work,
IMHO.

Yes, I can create a kludge of a workaround within a specific local network
environment.  Hey, Rube Goldberg was my hero!   But just because I can, does
not mean I wish to create convoluted solutions.  Nor solutions that only
work in a very narrowly defined environment.

It seems a shame that Alaska does not see fit to add this very slight
enhancement to what appears to be a very good ASINET library.  How hard
could it be?  They've already got logic to log into a POP3 server.  Other
library vendors are already doing it, and selling the solution for a wide
variety of compilers, including xBase++.  It isn't the added cost that puts
me off.  I just hate to see Alaska going down the same road so heavily
traveled by Clipper - which required use of multiple 3rd party libraries to
create a fully functional development tool.   ASINET is so close - yet so
far away!

My Grandpappy always told me, "If you're going to do something, do it
RIGHT!"  That's all I'm inquiring about here.  Alaska - swallow a bit of
pride, admit the oversight, and do this RIGHT!  I'll be happy to test it for
you.

John McDermon
Rural Hall, NC

Alaska seem to have the same problem with FTP, where the allow
standard FTP sessions, but DON'T allow Passive FTP through a firewall.

>
>"Phil Ide" <phil@idep.org.uk> wrote in message
>news:3d471d2b.52388961@nntp.idep.org.uk...
>
>> One option you might use is to create a local mail server that only
>> accepts connections from the local domain or even the same machine.
>> This can be used to allow anonymous connections (e.g. Xbase++
>> programs) to deliver mail.
>>
>> This server then forwards all mail to a regular mail server (e.g.
>> Exchange), having an authenticated login (account) with that server.
>> You could set that account to allow delivery beyond the domain.
>
>This is all well and good - IF all you want to do is create a program that
>will work in a specific in-house environment.  But what about creating a
>program that will work from any PC anywhere?  As long as the user has access
>to a valid SMTP server and a valid user account, the software should work,
>IMHO.
>
>Yes, I can create a kludge of a workaround within a specific local network
>environment.  Hey, Rube Goldberg was my hero!   But just because I can, does
>not mean I wish to create convoluted solutions.  Nor solutions that only
>work in a very narrowly defined environment.
>
>It seems a shame that Alaska does not see fit to add this very slight
>enhancement to what appears to be a very good ASINET library.  How hard
>could it be?  They've already got logic to log into a POP3 server.  Other
>library vendors are already doing it, and selling the solution for a wide
>variety of compilers, including xBase++.  It isn't the added cost that puts
>me off.  I just hate to see Alaska going down the same road so heavily
>traveled by Clipper - which required use of multiple 3rd party libraries to
>create a fully functional development tool.   ASINET is so close - yet so
>far away!
>
>My Grandpappy always told me, "If you're going to do something, do it
>RIGHT!"  That's all I'm inquiring about here.  Alaska - swallow a bit of
>pride, admit the oversight, and do this RIGHT!  I'll be happy to test it for
>you.
>
>John McDermon
>Rural Hall, NC
>
>

Cheers from Geoff Cohen

Any technology that is distinguishable from Magic
 is insufficiently advanced