[REBOL] Re: Email woes on IBM/AIX Risc 6000
From: gscottjones:mchsi at: 2-Aug-2002 6:53
From: "Ed Dana"
> G. Scott Jones wrote:
> >It is not obvious from what you wrote about. ...
> Nope, it's not obvious from what I wrote. But then, that's my whole
> problem, I'm not sure where I should start looking. :)
Sorry. I didn't mean to imply that your description was in any way
inadequate or lacking. I should have written something more like that I
agreed that it certainly wasn't obvious what was going on. My blunder;
> >If the email server requires "authentication" and your user name has an
> >let me know and I can dig up the patch. If you don't know if it is
> >authenticating, try a telnet session, something like:
> I don't believe that the server requires authentication. Working with
> our SA, we were able to send an email on that box using a unix command
> (I forget which, I'm not a unix dude), it worked fine.
I also should clarify at this point that I, too, am not a AIX/unix/*nix
dude, but I played one at an improv theater once. (<<---- Attempt-At-Humor
Alert ---->>) So like all good actors, then I'm probably over qualified.
Actually I don't think that this is an AIX issue, or I wouldn't be wasting
your time. Just that in being a close follower of the list, I've noticed
certain recurring patterns of problems. This one *appears* to be a
which can be further subcategorized into a
> >telnet smtprelay.avnet.com:25
> > EHLO your-client-url
> >and return and wait to see if amongst the return messages you see:
> >S: 250-AUTH=LOGIN
> I'll try it, but I'm not sure what you mean by "your-client-url"? Do you
> mean the url of the box I'm trying to email from? Please clarify...
I guess that was a bit nebulous. Sorry. As Anton pointed out in a separate
response, it may not matter what is typed in here because many email servers
will determine what it needs, namely your machine's URL, and therefore, your
Assuming that you are emailing from within the network (which I assume you
are since I cannot ping nor telnet to your server from the Internet), your
client url would likely look something like "dana.avnet.com" or maybe
. The email server will then get the IP
address that belongs to this url. My foggy-headed understanding of this is
that some email servers can be configured to only accept email from within
certain subnets as a further means of avoiding the unintended hosting of a
promiscuous email server (I just love that expression). Further
authentication is a redunduncy added in case the url/ip has been spoofed, or
authentication can be used to accept email from outside the subnet or
network (like if you are working from home), in which case the url/ip is
unimportant, but the user account name and password is crucial to avoid
being a promiscuous email server (there's that expression again).
Since you didn't mention having a user account name that includes an @ (like
[myname--mydomain--dom]) and that you use (or will be using) Exchange server,
then you may wish to try the hack I made April '01 for Nick Carson.
In this solution, I provide two scripts that add hacked versions of the smtp
scheme and the send function. Watch for line breaks. I renamed these to
avoid any conflict with REBOL's official version, but can be named to
overwrite the default code. As it stands, these scripts are designed to be
run from a REBOL console, but can be easily rewritten to run as a /View gui.
The authenticating username and password are requested from the console
prompt on first use, and stored internally for the rest of the session.
These values are not saved to permanent storage locally for security
reasons. Please note that if this script is to be provided for multiple
user use, it would be trivial to halt a script then hack and get the
username and password once entered (meaning, security risk). If this is the
situation, then the scripts should be changed to ask for the
username/password *each time* needed.
If these scripts do not work, then I would try the telnet route. From
Windows, open a dos box and type in:
telnet smtprelay.avnet.com 25
After the email server responds, type
then see what returns. This return infomation will be very valuable for
determining what to do next in making REBOL compatible. You may sign-off
the telnet session with "QUIT" and return.
(BTW, if you cannot see what you type, then in the telnet menu, click
preferences, and select "local echo".)
I hope I have further clarified what was evidently a less than clear
explanation. I'm interested in hearing what you find.