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
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted