From: Gabriele Santilli
SJ> I vaguely recall that TLS is an encoding or
SJ> encrypting scheme. Does anyone else know?
...
GS> TLS is the Transport Layer Security protocol.
GS>
GS> http://www.ietf.org/rfc/rfc2246.txt
Thanks for confirming that, Gabriele. I also found:
ftp://ftp.isi.edu/in-notes/rfc2487.txt
that explains more of the overview of smtp server behavior.
I did not have much time to explore the exim server information
on-line, but the information in the second RFC makes me wonder
whether there may not be an alternative for your server. Again,
the server seems to "advertise" that it accepts plain
authentication. As I recall 3ish years ago, the extended smtp
(ESMTP) "standard" is not very standard at all, which was
reportedly why RT decided not to support it directly. Indeed,
over the last several years we've seen several variations on
the list. If you are interested in pursuing this with a non-
command REBOL, I would next communicate with your smtp server
through an interactive interface, most easily done through a
telnet utility.
SMTP servers will detect whether the client is on its net or not,
and can require different logins based on this information. Or
it can simply exclude connections from outside its network. The
2nd RFC implies that if the smtp server is "publically exposed",
then it should not offer services on port 25 (the "usual" smtp
port) *if secured authentication is mandatory*. A different port
(like 995, if I recall) is usually required. This method allows
secured and authenticated transmission of emails from a client, but
is *not* used as a relay mail transport.
Given that your email makes no reference to using any other port
than the default, namely 25, then I am assuming that either the
server is only accessible from within your network (subnet really)
or that it will allow an alternative login. Otherwise, if my
logic holds up, the server would be "noncompliant". As I hinted,
I wonder if the server may allow a plain authenticated login but
through a somewhat nonstandard sequence of commands. Hence the
need to do some testing before deciding that it can't be done
(easily) through "regular" REBOL.
Unfortunately, as I have made indirect reference to several times,
*describing* how to do this is not easy through an asynchronous
method like email. When I helped Nick Carson out a few years ago
he gave me a temporary account on his server, so I could play
with the methods.
Before starting telnet, find out your client name at a utility
of your choice or with REBOL:
probe system/network/host
>> probe system/network/host
"NSF000000"
At any rate, use a telnet utility to communicate with the server
for an interactive session. From the command line, it might
look something like:
telnet smtp.mydomain.com 25
or once in a telnet session it will more likely look like:
open smtp.mydomain.com 25
It the following the server lines are marked by "S>" and the
client lines are marked by "C>" (meaning, what you type in). Lines
will be wrapped on this email and will of course look different
with your server. Some telnet utilities do not echo your input;
type especially carefully in those cases, or get a telnet utility
that does echo.
S> 220 apricot.southpole.usap.gov Microsoft ESMTP MAIL Service,
Version: 5.0.2195.6 713 ready at Fri, 7 May 2004 08:08:56 +1200
C> HELO NSF000000
S> 250 apricot.southpole.usap.gov Hello [157.132.6.107]
C> HELP
S> 214-This server supports the following commands:
S> 214 HELO EHLO STARTTLS RCPT DATA RSET MAIL QUIT HELP AUTH TURN
ATRN ETRN BDAT VRFY
C> QUIT
S> 221 2.0.0 apricot.southpole.usap.gov Service closing
transmission channel
In this simple sequence we have established basic communications with
the smtp server. HELO is a standard log greeting typically used when
NO authentication is required. The HELP command speaks for itself, and
will tell us what general commands are allowed. Notice the EHLO command.
EHLO was added with the extended specification as a way of offering the
servers a way to allow logins with various levels of authentication.
You will notice that the patch I suggested substitutes this log greeting
for HELO.
If this first session does not go well, it may be helpful to cut and
paste the information for the list to see. Assuming the *does* go well,
next try the following at a telnet session:
S> 220 apricot.southpole.usap.gov Microsoft ESMTP MAIL Service,
Version: 5.0.2195.6 713 ready at Fri, 7 May 2004 08:08:56 +1200
C> HELO NSF000000
S> 250 apricot.southpole.usap.gov Hello [157.132.6.107]
C> AUTH PLAIN
...
(*BookMark 1*)
One of two things will likely happen. The first will tell me that
the server is quirky in its authentication method (not following the
standard directly). I can't tell you exactly what to look for but it
will likely either be a 334 code followed by either the text "Username:"
or the encoded text "VXNlcm5hbWU6" (which is "Username:" in base64).
It is possible that it may give a different code.
If you get something along these lines, then if the text prompt is
"Username:" then type your smtp service username and hit enter (return).
Next you should see "334 Password:", then type your password and enter.
If you see:
S> 235 2.7.0 Authentication successful.
Then you are in! You may type "QUIT" to exit. If it is not obvious
how to change my patch, let me know, and I hopefully can change the
"stimulus/response" pairs to get you logged.
If however you see "334 VXNlcm5hbWU6", then you will need to supply
a base 64 encoded username. At REBOL type:
enbase/base "myusername" 64
at a REBOL session. Take the result, excluding the double quotes,
and paste it into the telnet session and hit enter.
Next you will see "334 UGFzc3dvcmQ6", so you will need to supply
the base 64 encoded password just like for the username. If you see:
s> 235 2.7.0 Authentication successful.
Then you are in! You may type "QUIT" to exit. If it is not obvious
how to change my patch, let me know, and I hopefully can change the
"stimulus/response" pairs to get you logged.
However, more likely you will see something like this 503 error after
typing "AUTH PLAIN" for a "HELO" greeting:
S> 503 5.5.2 Send hello first.
Then that will tell me that the server is *not* totally quirky in its
authentication method. Next, either in the same session or a new
session, type:
C> EHLO NSF000000
To be explicitly clear, note the HELO is scrambled to EHLO. This *is*
supposed to designate that a form of authenticated login is to be used.
Following this, based on your earlier email, *you* will see this:
S> 250-<obscured> Hello <obscured> [<obscured>]
S> 250-SIZE 52428800
S> 250-PIPELINING
S> 250-AUTH PLAIN LOGIN
S> 250-STARTTLS
S> 250 HELP
Through the patch, we've already tried "AUTH LOGIN", which seems to
possibly require TLS (we aren't totally sure based on the information).
This time try "AUTH PLAIN". Again, one of two things may happen.
Return to "(*BookMark 1*)" in this email and try the same approach.
My hope and intuition suggests that you may be able to do a truly
"plain" authentication login at that juncture.
As far as other tips, keep an eye out for non-standard codes. The REBOL
scheme is absolutely dependent on finding these codes. The last code
in a sequence *should* have a space following before the text. The
only other quirk/tip is that some services require the full email
address for the username. You will likely already know about this
from configuring your other email clients.
I hope we may stumble across the right solution. It helps you and
others and improves REBOL's future for use. Please, no matter what
you find positive or negative, let us/me know so that we have a better
"leg up" for the next person!
Thanks!
--Scott Jones
Weather for South Pole Station
The date is 05-07-2004 at 9:00 AM
Temperature -63.3 C -82 F
Windchill -100.1 C -148.2 F
Wind 14.7 kts Grid 042
Barometer 670.3 mb (10993. ft)
UTC 05-06-2004 at 21:00 Z
--
To unsubscribe from this list, just send an email to
[EMAIL PROTECTED] with unsubscribe as the subject.
