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
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.
---
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