Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

[REBOL] Re: SMTP Authentication

From: Gary:Jones:usap:gov at: 7-May-2004 9:10

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