Interest in updated RexxMail?
John Small
of using Marcus de Geus' RexxMail to send emails from another REXX
program. As I looked into it I found the latest release,
rexxmail_20061224_155329.zip,
a) fails to run under Object Rexx; and
b) does not support the type of SMTP authentication used by my (and
I'm sure many other) SMTP servers (AUTH LOGIN).
With the help of Marcus de Geus, I have corrected the error that
stopped Rexxmail under Object Rexx and added support for AUTH LOGIN.
1) Is there any interest in a public release of this code?
2) Are there additional SMTP authentication mechanisms you would to
see RexxMail support? (I'm not making any promises but I will look
into the feasibility of adding other authentication mechanisms.)
--
John Small
Lutz
>With the help of Marcus de Geus, I have corrected the error that stopped
>Rexxmail under Object Rexx and added support for AUTH LOGIN.
Great, and thanks very much for doing so.
Did you leave some comments with the changed code?
>1) Is there any interest in a public release of this code?
Yes, certainly. Perhaps you can put it on Hobbes?
Regards,
Lutz Pescht periplaneta de
----.------ @ -----------.--
A.D. Fundum
> and added support for AUTH LOGIN.
Sounds like a quality improvement to me.
> 1) Is there any interest in a public release of this code?
Why not? You're basicly saying the old version doesn't work at all
with ORexx.
---
mentoruccio
I agree.
This could also give the user the ability to e-mail objects directly
from the WPS, adding a context menu option: am I wrong in thinking
this?
Mentore
John Small
<mentore...@libero.it> wrote:
> On 26 Lug, 12:25, "A.D. Fundum" <what.e...@neverm.ind> wrote:
> > ˙> I have corrected the error that stopped Rexxmail under Object Rexx
> > ˙> and added support for AUTH LOGIN.
> >
> > Sounds like a quality improvement to me.
> >
> > ˙> 1) Is there any interest in a public release of this code?
> >
> > Why not? You're basicly saying the old version doesn't work at all
> > with ORexx.
>
> I agree.
Once Marcus and I are happy with the current changes, we will make a
public release.
> This could also give the user the ability to e-mail objects directly
> from the WPS, adding a context menu option: am I wrong in thinking
> this?
I don't know. Rexxmail is a large program with a myriad of options. I
am not even close to an expret on the capabilities of Rexxmail.
I was looking for a way to email from a REXX program and Rexxmail
seemed to provide a solution. But there was a syntax error in an
abosure section of code. Since Object REXX checks the entire file for
such errors before execution, Rexxmail would not run for me. Once I
fixed the syntax error Rexxmail installed successfully and ran. But my
SMTP server did not support the authentication methods supported by
Rexxmail. So I looked into adding support for the authentication used
by my SMTP server.
So the SMTP authentication portion is the only part of Rexxmail with
which I have a respectable level of familiarity. So I am not in a
position to have a useful opinion on whether it is possible or
parctical for Rexxmail to become a WPS menu item for sending emails.
If you are able to make this (WPS menu item for sending email using
Rexxmail) work with Rexxmail, I'd be very interested in hearing how
you did it.
--
John Small
A.D. Fundum
One of the reasons why ORexx is a better Rexx interpreter. IIRC syntax
checking before execution is defined in the Rexx ANSI standard.
Regarding this, the other one isn't compliant.
> is possible or parctical for Rexxmail to become a WPS
> menu item for sending emails.
I think the only thing that comes close would be, in general, a
Rexxmail drop target. But that's just "PARSE ARG file", basicly. For
WPS programming (RMB -> E-mail this object to ...), you'll probably
have to look at C/C++ and another product. Or use the existing
"Copy..."-facility with a virtual disk, which is watched by "a"
e-mailer. PMREXX is broken nowadays, so writing PM/WPS apps with
(just) Rexx is hard (or impossible).
Here's an easy/ugly solution, but as such it has nothing to do with
Rexxmail or WPS-integration. There are more solutions like Rexxmail,
but I won't mention those now. Create a program object on your desktop
for this Demo.CMD, which I included below . There's a field for
"Parameters". Enter there: [Receiver] %1
Including the [ and ]. Save the object Next, drop e.g. a folder or a
file on the new object. You should get a PM entry box, with a prompt.
You may type "ty...@pirelli.com" there, and press ENTER (or select
"Open").
What you get is about as-good-as-it-gets with Rexx. Some PM
dialog-with-prompt to enter a receiving email address, a WPS-way to
become a drop target, and VIO window prompt if a WPS interface wasn't
used. No RxMessageBox to show the result, because PMREXX is broken
("SAY Address()" no longer returns "PMREXX" in that environment).
---
/* DEMO.CMD */
PARSE ARG to file
IF file<>'' THEN DO
SAY 'To:' to
SAY 'Attach file:' file
SAY
CALL CharOut '','Press <ENTER> to exit... '
PULL .
EXIT
END
IF to='' THEN DO
CALL CharOut '','To? '
PULL to
SAY
END
CALL CharOut '','File? '
PULL file
'@CLS'
SAY 'To:' to
SAY 'Attach file:' file
SAY
CALL CharOut '','Press <ENTER> to exit... '
PULL .
EXIT
Rich Walsh
> > is possible or parctical for Rexxmail to become a WPS
> > menu item for sending emails.
>
> I think the only thing that comes close would be, in general, a
> Rexxmail drop target. But that's just "PARSE ARG file", basicly. For
> WPS programming (RMB -> E-mail this object to ...), you'll probably
> have to look at C/C++ and another product.
Why wouldn't you just associate your program object for the script
with type "Plain Text"? Then it would be on the "Open as" menu for
most files.
--
== == almost usable email address: Rich AT E-vertise.Com == ==
A.D. Fundum
>>> menu item for sending emails.
>> I think the only thing that comes close would be, in general,
>> a Rexxmail drop target. But that's just "PARSE ARG file",
>> basicly. For WPS programming (RMB -> E-mail this object
>> to ...), you'll probably have to look at C/C++ and another
>> product.
> Why wouldn't you just associate your program object for the
> script with type "Plain Text"? Then it would be on the "Open
> as" menu for most files.
Indeed yet another smart way to do it, albeit it still doesn't like
Windows' "Copy to ... e-mailreceiver" (AFAIK). If one wants that, that
is. But that still won't add it in apps, i.e. no "Save file to ...
e-mailreceiver".
My droptarget was focussed on using just Rexx. It can be done with a
SysCreateObject(). FWIW, yet another disadvantage of my approach is
that it'll launch a copy per dropped file. One may drag more than 1
file to it, but you'ld get 1 e-mail per file if you didn't solve that
issue.
Perhaps the best integrated thing that can be written is an EMAIL.IFS
(or a RAMDISK.IFS)? I.e. copy/save/shadow a file/object to drive M:,
and (re-) scan drive M: for e-mails to ship. If the object is a
folder, perhaps also include 'subdirectories'. Virtual example:
There are many ways to copy my CONFIG.SYS to drive M:. If a file
exists on drive M:, its IFS waits - let's say - one second and
launches the e-mailer (or another app scans drive M: every X second
for new files, and lauches an(y) e-mailer). The e-mailer pops up. I
also want to send you my DEBUG.LOG. I first save that to drive M: too.
I may have to refresh the list of files to be attached in the
e-mailer.
Advantages are that it'll work with about any file and with anything
capable of saving/copying files. WPS, apps, CMD.EXE, Rexx. It isn't
clear, you'ld have to know that drive M: is a special destination,
which isn't called 'E-mail to...'. Your 'Open as ...' is more clear
that this, because the '...' could read 'e-mailer'.
Just thinking loud here... A solution involving a M: also cannot be
written in Rexx (not counting extremely complicated fun with
CharOut()).
---
Lars Erdmann
> >>> is possible or parctical for Rexxmail to become a WPS
> >>> menu item for sending emails.
>
> >> I think the only thing that comes close would be, in general,
> >> a Rexxmail drop target. But that's just "PARSE ARG file",
> >> basicly. For WPS programming (RMB -> E-mail this object
> >> to ...), you'll probably have to look at C/C++ and another
> >> product.
>
> > Why wouldn't you just associate your program object for the
> > script with type "Plain Text"? Then it would be on the "Open
> > as" menu for most files.
>
> Indeed yet another smart way to do it, albeit it still doesn't like
> Windows' "Copy to ... e-mailreceiver" (AFAIK). If one wants that, that
> is. But that still won't add it in apps, i.e. no "Save file to ...
> e-mailreceiver".
How about "Print to e-mailreceiver" ? That could be added. But it's effort.
You would need to write a "pseudo" printer driver that instead of printing
will eventually send the email to a selected receiver.
> My droptarget was focussed on using just Rexx. It can be done with a
> SysCreateObject(). FWIW, yet another disadvantage of my approach is
> that it'll launch a copy per dropped file. One may drag more than 1
> file to it, but you'ld get 1 e-mail per file if you didn't solve that
> issue.
>
> Perhaps the best integrated thing that can be written is an EMAIL.IFS
> (or a RAMDISK.IFS)? I.e. copy/save/shadow a file/object to drive M:,
> and (re-) scan drive M: for e-mails to ship. If the object is a
> folder, perhaps also include 'subdirectories'. Virtual example:
>
> There are many ways to copy my CONFIG.SYS to drive M:. If a file
> exists on drive M:, its IFS waits - let's say - one second and
> launches the e-mailer (or another app scans drive M: every X second
> for new files, and lauches an(y) e-mailer). The e-mailer pops up. I
> also want to send you my DEBUG.LOG. I first save that to drive M: too.
> I may have to refresh the list of files to be attached in the
> e-mailer.
Why would you select such a complicated solution ? An IFS is overkill for this job.
Why don't you just have a special directory that is scanned for new files by some
script and if there is a new file, it will pop up a dialog/window and ask for a receiver to send it to ?
You could then let the script cycle forever.
In fact that is about what sendmail does. What it does is manage an email queue.
Its configuration is cryptic and painful but within its config file (sendmail.cf) you can specify an email application to do the actual job of email transmission.
The nice thing is: it is a standard unix application, therefore you will find loads of information about
its use on the internet.
And it comes with OS/2 (look into \TCPIP\BIN).
Lars
A.D. Fundum
> effort. You would need to write a "pseudo" printer driver that
instead
> of printing will eventually send the email to a selected receiver.
Also an interesting thought.
> Why would you select such a complicated solution ? An IFS is
> overkill for this job.
Because it will create/(ab)use a drive. I haven't really tried it. But
if I select "RMB -> Copy...", a drive can be used on _any_ of the
destination tabs. Is versatility the right word here?
Nevertheless I do like your printer concept even more, because that's
an output device and there's no need to being able to access it from
_any_ location. The only disadvantage may be that an unmaintained, old
app has no "Print", only "Save". And perhaps the pint is an image
instead of raw data?The IFS has more possibilities than a printer,
albeit we likely won't use all of those goodies. Size management,
virus scanning, ... My printer doesn't refuse a document because I
don't have enough paper...
> just have a special directory that is scanned for new files
See above. In a list of drives, it's easier to select a drive (main
level) than some "hidden" directory (in a to be expanded tree).
Allright, not everybody likes SUBST... ;-)
> You could then let the script cycle forever.
My thought was that an IFS doesn't require a polling script/daemon,
and it instead can be triggered by some finishing file operation.
Maybe a (FS_EXIT- or) FS_CLOSE-operation: close the new file, and next
automatically launch the actual mailbot? Just because that's the real,
underlying trigger.
But that's why I slightly prefer the printer, which also has a natural
trigger instead of a resource-waisting daemon being useless for 99.99%
of the time. And the printer can have a name, which is more clear than
a "M:" without a displayed label. Albeit LPT2: also isn't clear. And
as long as the virtual printer accepts raw files, and doesn't print an
image, and accepts all files (also the ones that aren't WPS-printable.
I want my mother to receive the original *.JPG-file with some
EXIF-data. Not the BMP that's in the presentation space, nor an error
message about the file not having a WPS_PRINTABLE-flag.
> In fact that is about what sendmail does. What it does
> is manage an email queue.
> The nice thing is: it is a standard unix application
> And it comes with OS/2 (look into \TCPIP\BIN).
I'm not really looking for this integrated solution, but I'll look at
it anyway. Now I know what sendmail is supposed to be.
---
Lutz
news program.
What I do to send a file directly as an email to a (preselected) receiver
is to prepare a program object with the following entries:
TAB Icon
Title
Send as email to tar...@mail.de
TAB Program
Path and file name
P:\EMAIL\MR2ICE\MR2I.EXE
Parameters
/Q:"%*" tar...@mail.de "%**N"
Working directory
P:\EMAIL\MR2ICE
TAB Association
Here I associate this program object with all the file types I need.
Let's assume JPG is one of them, all JPG (JPEG) files will now have the
entry "Send as email to tar...@mail.de" (as set above as Title) in there
"Open as ..." menue.
If I want to send now EXAMPLE.JPG to this email address
I just select "Send as email to tar...@mail.de" from the "Open as ..."
menue of EXAMPLE.JPG and the mail program will receive the JPEG file,
create a new message containing the MIME encoded JPEG file EXAMPLE.JPG,
set the reciever of that message to tar...@mail.de,
and set the subject to EXAMPLE.
This message will then be placed in the outbox waiting for editing or
sending. So you can drop more pictures in the same message and add text as
you like.
Unfortunately you have to delete one unwanted sentence which will be added
by the MIME encapsulation process. Perhaps it is possible to find out
where exactly this stems from and how to avoid it.
This prevents me currently from adding the switch /XS to the parameters
line to get the message immediately send.
In case you like to change the receiving email address just add square
brackets around it so the line reads:
Parameters
/Q:"%*" [tar...@mail.de] "%**N"
and each time you invoke this program object a popup dialog will ask for
it. Or I prepare as many program objects as I have different receivers. Or
I could write a REXX program to create such objects from a list of
addresses.
MR/2 ICE allows also to address a group with one virtual address like
best_friends@groups. The group can consist of a list of email addresses
maintained within MR/2 ICE. Single entries of this list can be switched on
or off. And names of simple files with a list of email addresses can also
be part of such a group definition. That allows for externally maintained
lists.
The parameters line starts with the "/Q:".
That switch tells MR/2 ICE what to do.
It expects three more values "full filename" "send-to-address" "subject".
To give these I use normal WPS parameters with double qoutes around them
to handle blanks in file names properly.
So you can drop any files onto this program object and they will be
separately brought into email messages.
A.D. Fundum
> which will be added by the MIME encapsulation process.
Just wondering: what happens if you give it an a MIME-file with a
proper MIME-header? Example, save the 8 lines in a file, remove the 8
*'s and use your MR/2 ICE-method:
*--LsIE3XCVf22hZwC
*Content-Type: application/octet-stream; name="Question.TXT"
*Content-Transfer-Encoding: base64
*Content-ID: <1UbUMlQN...@dotje.be>
*Content-Description: MIME MIME'd twice?
*
*RWluZHdhbmRmcmVpPw0K
*--LsIE3XCVf22hZwC--
It may MIME the MIME (raw). Or it may recognize the MIME-headers and
use it as-is (cooked), i.e. not adding an extra sentence. But I think
it should re-MIME the MIME (/ordinary textfile) with the added
sentence, which isn't wrong.
I'm not sure if some preprocessor has any use otherwise, if the above
doesn't work. E.g. argument checking or file size checking (IF
Stream(mimefile,'C','QUERY SIZE')>5000000 THEN DO;SAY "Too large, will
be rejected by ISP or the office's e-mail server";EXIT;END). But hey,
it's just a sentence.
> could write a REXX program to create such objects from
> a list of addresses.
Again, in this thread: why not? And release it. Getting the
SysCreateObject()-setupstring right seems to be the hard part now,
given what you already figured out.
Two new remarks, Rich Walch mentioned the WPS earlier. I think a
must-have are translated messages, same use of the language as the OS
itself does. Eighter already included (Select a language from the list
of available eCS-languages), or ask for a DIY-replament text with a
default WPS text. E.g.:
/* Get the word for a "keyboard", ugly-mode */
text='tastatur'
SAY 'Enter the name of the device, as used in the'
SAY 'context "I just spilled coffee on my ...", or press'
SAY 'ENTER to use the default:' text
CALL CharOut '','Your preferred name of this device is? '
PARSE PULL new
new=Strip(new)
IF new<>'' THEN text=new
SAY 'You just spilled coffee on your' text||'.'
Nice-to-have, but not that important: easy way to (initially) edit the
associations. I don't have a clue which files you're likely to e-mail,
and which files you'll never want to e-mail.
> To give these I use normal WPS parameters with double quotes
> around them to handle blanks in file names properly.
Perfect, supporting HPFS e.a. (and also allowing for arguments after
the filename).
---
Lutz
> > Unfortunately you have to delete one unwanted sentence
> > which will be added by the MIME encapsulation process.
>Just wondering: what happens if you give it an a MIME-file with a proper
>MIME-header? Example, save the 8 lines in a file, remove the 8 *'s and
>use your MR/2 ICE-method:
>*--LsIE3XCVf22hZwC
>*Content-Type: application/octet-stream; name="Question.TXT"
>*Content-Transfer-Encoding: base64
>*Content-ID: <1UbUMlQN...@dotje.be>
>*Content-Description: MIME MIME'd twice?
>*
>*RWluZHdhbmRmcmVpPw0K
>*--LsIE3XCVf22hZwC--
Well, I haven't looked into it further so perhaps some tries like this
will reveal useful details.
So far the MIME encapsulation process for a JPEG file named
"Wienermobile.jpg" results in (first lines only):
__________________________________________________
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="===_4C52D112_=="
This is a MIME encapsulated message.
--===_4C52D112_==
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Please briefly describe the problem you have experienced with this
particular message:
--===_4C52D112_==
Content-Type: application/octet-stream; name="Wienermobile.jpg"
Content-Transfer-Encoding: base64
_________________________________________________
>It may MIME the MIME (raw). Or it may recognize the MIME-headers and use
>it as-is (cooked), i.e. not adding an extra sentence. But I think it
>should re-MIME the MIME (/ordinary textfile) with the added sentence,
>which isn't wrong.
Probably this line "Please briefly ..." will be added anyway, but I may
try with other filetypes to see if that makes any difference.
>I'm not sure if some preprocessor has any use otherwise, if the above
>doesn't work. E.g. argument checking or file size checking (IF
>Stream(mimefile,'C','QUERY SIZE')>5000000 THEN DO;SAY "Too large, will be
>rejected by ISP or the office's e-mail server";EXIT;END). But hey, it's
>just a sentence.
MR/2 ICE allows for filters which can be a REXX script to be activated
before sending a message so that could be the way for mending the message
and doing more checking as you mention above.
> > could write a REXX program to create such objects from
> > a list of addresses.
>Again, in this thread: why not? And release it. Getting the
>SysCreateObject()-setupstring right seems to be the hard part now, given
>what you already figured out.
Sure, its not difficult to do so, similar code has been written already
many times and is used in installation scripts, but is there real need for
it? Anyone still using MR/2 ICE?
A.D. Fundum
> with this particular message:
> -------Begin Encoded File-------
> Encoded filename: Wienermobile.jpg
> Decoded path: file:///C:\TCPIP\DECODED\Wienermobile.jpg
> Encoding type: Base 64
> File size: 0KB
> --------End Encoded File--------
LOL! The problem is that you didn't add a prefix to each line, so some
newsreaders recognize this as an attachment (cooked) instead of an
example (raw), and then one cannot really tell what your original text
was. HTH! ;-)
BTW, seriously: problem with the sentence understood. But I still
have to give MR/2 ICE a try...
--
steen bondo
> Once Marcus and I are happy with the current changes, we will make a
> public release.
I used to use rexxmail (did some . One feature I liked a lot, was the
capability to perform whatever you needed, by sending an email 'home' -
ie sending a specific file to someone, retstart server, via a rexx
script. Had a great filtering system... feature rich...
One thing I did not like, was that RM made a great deal of mess in INI
files - as I recall it.
--
cheers
---
steen
John Small
wrote:
Could you be more specific about "a great deal of mess"?
As far as I can see, Rexxmail does not use the OS/2 INI files
directly. It does, however, create what some may consider to be a lot
of objects (about which the WPS stores information in the the INI
files).
--
John Small