Another question about the 'send' function
[1/6] from: eskape::tdcadsl::dk at: 10-Aug-2004 18:55
My internetprovider wants me to use "asmpt" when sending email. (Instead of "smpt"). For security reasons. This means I have to provide "username" and "password" when establishing contact to the "outgoing mailserver". This is no problem in my mail client (e.g. Mozilla). But, how do I do this in the Rebol send-function? Thank you - Steffen (of Denmark)
[2/6] from: charles:mougel:spinodo at: 10-Aug-2004 19:01
Steffen Pedersen wrote:
>My internetprovider wants me to use "asmpt" when sending >email. (Instead of "smpt"). For security reasons. This
<<quoted lines omitted: 3>>>But, how do I do this in the Rebol send-function? >Thank you - Steffen (of Denmark)
Maybe this can help : http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=esmtp.r Charles.
[3/6] from: Gary:Jones:usap:gov at: 11-Aug-2004 13:17
Behalf Of Steffen Pedersen
> My internetprovider wants me to use "asmpt" > when sending email. (Instead of "smpt").
<<quoted lines omitted: 3>>> ... > But, how do I do this in the Rebol send-function?
Hi, Steffen, The ease with which this can be done may depend on which SMTP server your provider is using. The most common request has been for Microsoft's Exchange server which may be set to its extended SMTP mode requiring encoded authentication. The following patch should work for that server (watch for line wrap): system/schemes/smtp/handler/open-check: [none "220" ["EHLO" system/network/host] "250" "AUTH LOGIN" "334" [port/user] "334" [port/pass] "235"] system/schemes/smtp/user: copy enbase/base myusername 64 system/schemes/smtp/pass: copy enbase/base mypassword 64 ;...in which myusername and mypassword are set appropriately This method alters the current running copy of the protocol scheme that manages the SMTP connection. It tests with the extended HELO command, "EHLO", for the extended SMTP command set. Exchange frequently uses the "AUTH LOGIN" for encoded authentication. The script looks for this option and then offers the base 64 encoded version of the username and password. E-mail is then sent using the standard 'SEND command. However, there is no standardization of extended SMTP, and so many varieties exists. In theory, there is a work around for many or most; however, the list ran into one 3 months back that used a variety of SSL that did not have an "easy" work around. If the above script fragment does not work, there is a way for you to find out more about your SMTP server, if you are adventurous and you have the TELNET client software (most machines do). Let us know what you find. --Scott Jones
[4/6] from: eskape:tdcadsl:dk at: 11-Aug-2004 18:50
Thank you Scott (Jones) and Charles (Mougel), Scott's scheme does not quite work. Without change I get: ** User Error: Server error: tcp 550 Sender address is invalid ** Near: insert port reduce data ------ If I do not encode "myusername" I get: ** User Error: Server error: tcp 535 Authentication failed ** Near: smtp-port: open [scheme: 'smtp] ----- But (very, very strange) I get the same result if I encode myusername but do not encode "mypassword". ------ I will experiment some more and let you know. ------ But somehow it must be kind of a standard protocol. Because both the Mozilla mail client and Outlook Express do it with no problems at all. ------ Regards Steffen ++++++++++ Jones, Scott wrote:
[5/6] from: Gary:Jones:usap:gov at: 12-Aug-2004 12:21
Steffen Pedersen wrote:
[6/6] from: Gary:Jones:usap:gov at: 12-Aug-2004 12:37
(Sorry about the previous, nearly empty e-mail. I got distracted and must have hit a send key combination. Also apologies that Outlook mixed with the list mail server creates all the odd end of line characters.) Steffen Pedersen wrote:
> ... > Scott's scheme does not quite work. ...
Hi, Steffen, Instead of trying the TELNET option, turn trace/net on. At a fresh REBOL console session (no patch), try sending yourself a test message: trace/net on send [myself--myemail--com] "Test" As REBOL tries to send the message, it will spit out more information that may help to discover what is going wrong, and therefore, what may need patching. You can copy this information from the console and send it back to the list. I would obscure information (like replacing fake information for a real e-mail address, etc) that you would prefer to not get published. Depending on what is found, there may be a fix. The final option is to use a TELNET session, which is more involved. Let me/us know what you find. --Scott Jones
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted