Re: CSSMTP user exit and external email

[Andrew Rowley]

On 21/06/2017 10:52 PM, Paul Gilmartin wrote:

Nice.  I see:
 final String username = "smtp-username";
 final String password = "smtp-password";

Rather than hard-coding, could these be extracted from RACF (or other?)
database?  Or kept in suitably protected user-specific files?
RACF? Maybe, but you would have to figure out how to get the data using 
Java. Protected files, certainly.


You might want to move all the hard coded items into some sort of 
external configuration e.g. read them from DDs. The sample isn't 
intended to be the ideal solution, it is intended as a working example 
of what can be done, expected to be extended and modified as required. 
While you don't want to hard code stuff in production code, it often 
makes things clearer in a sample where you just want to understand the 
code. Abstraction etc. can be desirable in production code because it 
hides implementation details, but the details are what you want to see 
in a sample.



What about headers?  Ideally, I might expect:
 From: z/OS-ID
 Sender: "smtp-username"

You can set headers as required:
https://javaee.github.io/javamail/docs/api/javax/mail/internet/MimeMessage.html#setHeader-java.lang.String-java.lang.String-
also:
https://javaee.github.io/javamail/docs/api/javax/mail/internet/MimeMessage.html#setReplyTo-javax.mail.Address:A-

What your mail server allows is a different question - but part of the 
original question was how to enforce corporate mail standards on mail 
originating from z/OS.



Might these be publicized (not stored) on CBTTAPE.org to attract
users to Black Hill's storefront?


They could certainly be linked etc. from cbttape.org. I'm not sure 
whether they would be suitable for the CBT tape itself since it's really 
just a sample, not something you would use in production. I have some 
ideas for other Java utilities that could be candidates for the CBT tape 
however...


--
Andrew Rowley
Black Hill Software
+61 413 302 386

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CSSMTP user exit and external email

[Paul Gilmartin]

On Wed, 21 Jun 2017 21:50:47 +1000, Andrew Rowley wrote:
>
>I have written up a sample Java program to send email from z/OS via
>Gmail here:
>https://www.blackhillsoftware.com/news/2017/06/21/sending-email-from-zos-using-java/
>
>Java on z/OS is a giant leap forward in ease of doing things - when I
>first decided to test this, I Googled "java send email via Gmail" and
>had a test program working within 30 minutes.
> 
Nice.  I see:
final String username = "smtp-username";
final String password = "smtp-password";

Rather than hard-coding, could these be extracted from RACF (or other?)
database?  Or kept in suitably protected user-specific files?

What about headers?  Ideally, I might expect:
From: z/OS-ID
Sender: "smtp-username"

or:
Reply-to: z/OS-ID

But would GMail or a corporate mail server tolerate these, which might appear
to be used for forgeries or mail-bombing?

Hardcoding these or a corporate server should not be a problem:
props.put("mail.smtp.host", "smtp.gmail.com");
props.put("mail.smtp.port", "587");

Might these be publicized (not stored) on CBTTAPE.org to attract
users to Black Hill's storefront?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CSSMTP user exit and external email

[Jousma, David]

Andrew,  thank-you very much for taking the time to put up the sample.   

Dave

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Andrew Rowley
Sent: Wednesday, June 21, 2017 7:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSSMTP user exit and external email

On 20/06/2017 09:30 PM, Jousma, David wrote:
> Sounds interesting.  Where would I learn more about this?
>
I have written up a sample Java program to send email from z/OS via Gmail here:
https://www.blackhillsoftware.com/news/2017/06/21/sending-email-from-zos-using-java/

Java on z/OS is a giant leap forward in ease of doing things - when I first 
decided to test this, I Googled "java send email via Gmail" and had a test 
program working within 30 minutes.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN


This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CSSMTP user exit and external email

[Andrew Rowley]

On 20/06/2017 09:30 PM, Jousma, David wrote:

Sounds interesting.  Where would I learn more about this?

I have written up a sample Java program to send email from z/OS via 
Gmail here:

https://www.blackhillsoftware.com/news/2017/06/21/sending-email-from-zos-using-java/

Java on z/OS is a giant leap forward in ease of doing things - when I 
first decided to test this, I Googled "java send email via Gmail" and 
had a test program working within 30 minutes.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CSSMTP user exit and external email

[Paul Gilmartin]

On 2017-06-20, at 05:30, Jousma, David wrote:

> Sounds interesting.  Where would I learn more about this?
>  
Who administers your corporate mail server?  On a Linux system,
I have configured mutt with simply:

# From: https://ubuntuforums.org/showthread.php?t=1946910
# Also make sure the packages gnutls-bin openssl libsasl2-2 # installed.
set smtp_url="smtps://paulgboul...@aim.com@SMTP.AIM.com:465/"
set smtp_pass="***"
set realname="Paul Gilmartin (π)"
set from="paulgboul...@aim.com"

Mutt is open-source, so you might copy (subject to GPL?) what it does.
Or start with:
https://en.wikipedia.org/wiki/SMTPS
https://tools.ietf.org/html/rfc6409

Some of those could be hard-coded in the interface; others extracted
from RACF.  Synchronizing password changes might remain manual.
Might the user update his own smtp_pass with no special privilege?


> -Original Message-
> From: Andrew Rowley
> Sent: Tuesday, June 20, 2017 3:22 AM
> 
> Instead of running a SMTP server on z/OS, my inclination would be to define 
> one or more email users for your z/OS systems in your corporate mail servers, 
> and use e.g. Java to log in to the mail server and send the mail. Then you 
> can use your standard corporate mail controls over what mail that userid can 
> send.
>  
I concur enthusiastically.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CSSMTP user exit and external email

[Jousma, David]

Sounds interesting.  Where would I learn more about this?

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Andrew Rowley
Sent: Tuesday, June 20, 2017 3:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSSMTP user exit and external email

On 16/06/2017 9:30 PM, Jousma, David wrote:
>   We have had quite a few requests to allow for external email, and have been 
> reviewing the controls that are available.

Instead of running a SMTP server on z/OS, my inclination would be to define one 
or more email users for your z/OS systems in your corporate mail servers, and 
use e.g. Java to log in to the mail server and send the mail. Then you can use 
your standard corporate mail controls over what mail that userid can send.

-- 
Andrew Rowley
Black Hill Software
+61 413 302 386

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CSSMTP user exit and external email

[Andrew Rowley]

On 16/06/2017 9:30 PM, Jousma, David wrote:

  We have had quite a few requests to allow for external email, and have been 
reviewing the controls that are available.


Instead of running a SMTP server on z/OS, my inclination would be to 
define one or more email users for your z/OS systems in your corporate 
mail servers, and use e.g. Java to log in to the mail server and send 
the mail. Then you can use your standard corporate mail controls over 
what mail that userid can send.


--
Andrew Rowley
Black Hill Software
+61 413 302 386

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CSSMTP user exit and external email

[Jesse 1 Robinson]

I don't want to be alarmist, and I certainly would not recommend beating on the 
hornet's nest just to see who lives there, but the truth is that any file or 
sysout you have legitimate access to could be transformed into a file that 
could be sent as an attachment pretty much anywhere your email system allows. 
Auditors spawned in the last millennium still cling to the archaic fiction that 
sending something directly from z/OS constitutes a unique risk. Just don't 
dwell too long on the list of sins that one could commit with PC tools. 

Also BTW I'm parked on z/OS 2.1 so was unaware of the new native controls 
available in 2.3. I still think that SAF offers the best hope, but you'll need 
to sharpen your coding pencil. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Monday, June 19, 2017 4:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: CSSMTP user exit and external email

Skip, Gil,

Thanks for your feedback.  Our shop is really no different than many on this 
list.   Mainframe environment is held it a "higher standard", right or wrong.  
Mainframe SMTP here has always been a roll your own as far as creating the SMTP 
text.   The biggest fear has been someone (internal) creating an email spoofing 
someone else, since there were no controls, and really there still aren’t any.  
 Sure, I can validate that the person submitting the email has the authority to 
do so, but from the available exit in z/OS 2.2 world, I have no way to 
programmatically validate that the person has formatted the contents of the 
email to be from themselves, and not from someone else, and there-in lies the 
problem for us.  Until z/OS 2.3 comes along with email addr support in RACF, 
how do I validate that?  And yes, if someone did spoof the FROM:, we would go 
back through the logs to see who did it, and take all appropriate actions.

The #3 in my list is again just typical "higher standard" issues with Audit.  
The immediate need we have for allowing external email has to do with 
limitations with the IDAA (Netizza) hardware doing problem notifications to IBM 
via EMAIL instead of a "phone home".   Audit wants us to limit the outbound to 
certain domains like *@xx.ibm.com.

Skip, you brought up the RYO program at your shop.  I can see some legitimacy 
in creating something like and doing the SAF calls as you mention.  I suppose I 
could do a WHEN PROGRAM type spool access for actually placing the formatted 
SMTP text on the spool as a way to ensure all email is properly formatted.   To 
do that, I'd have to create some yet-to-exist RACF(TSS) resource for every 
employee's email address for the RYO program to read.  For that, I might as 
well wait until the native support that arrives in z/OS V2.3.

I am meeting with them again to understand their concerns about mainframe vs 
Outlook email.

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Sunday, June 18, 2017 11:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSSMTP user exit and external email

It was pointed out to me that I may have given #3 too short shrift. We do not 
control destination addresses, but I suppose that a shop may have such a 
requirement. Again: if not for Outlook, then why for SMTP?

If one is to use a program to generate the SMTP text, then it would be a simple 
extension to include a SAF check for the To: address. It could be as high-level 
as validating the URL itself as eligible for SMTP mail or a specific check that 
this particular Sender is allowed to send mail to that URL. Like OP, I would 
strenuously avoid hard-coding a whitelist even at the general URL level. SAF is 
flexible and easy to use via standard product commands. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Sunday, June 18, 2017 2:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: CSSMTP user exit and external email

On 2017-06-17, at 21:06, Jesse 1 Robinson wrote:

> We have an RYO program available to the entire company. I use it 
> routinely to send messages and attachments internally and externally 
> with no impediments. The author of this program feels that
> 
> #1 

Re: CSSMTP user exit and external email

[Lucas Rosalen]

I second Mark about XMITIP.
You can always get a process in place to compile the REXX code and have
some kind of "product management" system.
And, as it's a REXX program, you can very easily wrap a REXX "exit" around
it to do whatever you like.

---
*Lucas Rosalen*
Emails: rosalen.lu...@gmail.com / *lrosa...@pl.ibm.com
<lrosa...@br.ibm.com>*
LinkedIn: http://br.linkedin.com/in/lrosalen
Phone: +48 (71) 792 809 198


2017-06-19 14:30 GMT+02:00 Mark Regan <marktre...@gmail.com>:

> Same at my previous employer, but you can always request an exception if
> you have a process in place at your site for doing  so. Of course when I
> installed XMITIP nearly 20 years ago, there was no concern then about using
> REXX programs written by another sysprog from another company. At least
> with XMITIP it is not compiled code and you do have all the source code to
> review.
>
>
>
> On Mon, Jun 19, 2017 at 8:21 AM Jousma, David <david.jou...@53.com> wrote:
>
> > Thanks Mark, yes, I have played with it in the past.  I may have to
> relook
> > at it again.   We've always steered away from "shareware" for general
> > consumption.
> >
> > _
> > Dave Jousma
> > Manager Mainframe Engineering, Assistant Vice President
> > david.jou...@53.com
> > 1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
> > p 616.653.8429 <(616)%20653-8429>
> > f 616.653.2717 <(616)%20653-2717>
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Mark Regan
> > Sent: Monday, June 19, 2017 7:45 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: CSSMTP user exit and external email
> >
> > Have you look at using Lionel Dyck's freeware XMITIP REXX program? More
> > info available at
> > https://protect2.fireeye.com/url?k=097bb6942d49e08b-
> e22c0dea1464f52c=http://www.lbdsoftware.com/xmitip.html
> > .
> >
> > On Mon, Jun 19, 2017 at 7:22 AM Jousma, David <david.jou...@53.com>
> wrote:
> >
> > > Skip, Gil,
> > >
> > > Thanks for your feedback.  Our shop is really no different than many on
> > > this list.   Mainframe environment is held it a "higher standard",
> right
> > or
> > > wrong.  Mainframe SMTP here has always been a roll your own as far as
> > > creating the SMTP text.   The biggest fear has been someone (internal)
> > > creating an email spoofing someone else, since there were no controls,
> > and
> > > really there still aren’t any.   Sure, I can validate that the person
> > > submitting the email has the authority to do so, but from the
> > > available exit in z/OS 2.2 world, I have no way to programmatically
> > > validate that the person has formatted the contents of the email to be
> > > from themselves, and not from someone else, and there-in lies the
> > > problem for us.  Until z/OS
> > > 2.3 comes along with email addr support in RACF, how do I validate
> that?
> > > And yes, if someone did spoof the FROM:, we would go back through the
> > > logs to see who did it, and take all appropriate actions.
> > >
> > > The #3 in my list is again just typical "higher standard" issues with
> > > Audit.  The immediate need we have for allowing external email has to
> > > do with limitations with the IDAA (Netizza) hardware doing problem
> > > notifications to IBM via EMAIL instead of a "phone home".   Audit wants
> > us
> > > to limit the outbound to certain domains like *@xx.ibm.com.
> > >
> > > Skip, you brought up the RYO program at your shop.  I can see some
> > > legitimacy in creating something like and doing the SAF calls as you
> > > mention.  I suppose I could do a WHEN PROGRAM type spool access for
> > > actually placing the formatted SMTP text on the spool as a way to
> ensure
> > > all email is properly formatted.   To do that, I'd have to create some
> > > yet-to-exist RACF(TSS) resource for every employee's email address for
> > > the RYO program to read.  For that, I might as well wait until the
> > > native support that arrives in z/OS V2.3.
> > >
> > > I am meeting with them again to understand their concerns about
> > > mainframe vs Outlook email.
> > >
> > > _
> 

Re: CSSMTP user exit and external email

[Mark Regan]

Same at my previous employer, but you can always request an exception if
you have a process in place at your site for doing  so. Of course when I
installed XMITIP nearly 20 years ago, there was no concern then about using
REXX programs written by another sysprog from another company. At least
with XMITIP it is not compiled code and you do have all the source code to
review.



On Mon, Jun 19, 2017 at 8:21 AM Jousma, David <david.jou...@53.com> wrote:

> Thanks Mark, yes, I have played with it in the past.  I may have to relook
> at it again.   We've always steered away from "shareware" for general
> consumption.
>
> _
> Dave Jousma
> Manager Mainframe Engineering, Assistant Vice President
> david.jou...@53.com
> 1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
> p 616.653.8429 <(616)%20653-8429>
> f 616.653.2717 <(616)%20653-2717>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Mark Regan
> Sent: Monday, June 19, 2017 7:45 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: CSSMTP user exit and external email
>
> Have you look at using Lionel Dyck's freeware XMITIP REXX program? More
> info available at
> https://protect2.fireeye.com/url?k=097bb6942d49e08b-e22c0dea1464f52c=http://www.lbdsoftware.com/xmitip.html
> .
>
> On Mon, Jun 19, 2017 at 7:22 AM Jousma, David <david.jou...@53.com> wrote:
>
> > Skip, Gil,
> >
> > Thanks for your feedback.  Our shop is really no different than many on
> > this list.   Mainframe environment is held it a "higher standard", right
> or
> > wrong.  Mainframe SMTP here has always been a roll your own as far as
> > creating the SMTP text.   The biggest fear has been someone (internal)
> > creating an email spoofing someone else, since there were no controls,
> and
> > really there still aren’t any.   Sure, I can validate that the person
> > submitting the email has the authority to do so, but from the
> > available exit in z/OS 2.2 world, I have no way to programmatically
> > validate that the person has formatted the contents of the email to be
> > from themselves, and not from someone else, and there-in lies the
> > problem for us.  Until z/OS
> > 2.3 comes along with email addr support in RACF, how do I validate that?
> > And yes, if someone did spoof the FROM:, we would go back through the
> > logs to see who did it, and take all appropriate actions.
> >
> > The #3 in my list is again just typical "higher standard" issues with
> > Audit.  The immediate need we have for allowing external email has to
> > do with limitations with the IDAA (Netizza) hardware doing problem
> > notifications to IBM via EMAIL instead of a "phone home".   Audit wants
> us
> > to limit the outbound to certain domains like *@xx.ibm.com.
> >
> > Skip, you brought up the RYO program at your shop.  I can see some
> > legitimacy in creating something like and doing the SAF calls as you
> > mention.  I suppose I could do a WHEN PROGRAM type spool access for
> > actually placing the formatted SMTP text on the spool as a way to ensure
> > all email is properly formatted.   To do that, I'd have to create some
> > yet-to-exist RACF(TSS) resource for every employee's email address for
> > the RYO program to read.  For that, I might as well wait until the
> > native support that arrives in z/OS V2.3.
> >
> > I am meeting with them again to understand their concerns about
> > mainframe vs Outlook email.
> >
> > _
> > Dave Jousma
> > Manager Mainframe Engineering, Assistant Vice President
> > david.jou...@53.com
> > 1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429
> <(616)%20653-8429>
> > <(616)%20653-8429> f 616.653.2717 <(616)%20653-2717> <(616)%20653-2717>
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Jesse 1 Robinson
> > Sent: Sunday, June 18, 2017 11:08 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: CSSMTP user exit and external email
> >
> > It was pointed out to me that I may have given #3 too short shrift. We
> > do not control destination addresses, but I suppose that a shop may
> > have such a requirement. Again: if not for Outlook, then why for SMTP?
> >
> > If one is to use a program to generate the SMTP text, then it would be
> > a simple extension to include a SAF check for the To: address. It
&g

Re: CSSMTP user exit and external email

[Jousma, David]

Thanks Mark, yes, I have played with it in the past.  I may have to relook at 
it again.   We've always steered away from "shareware" for general consumption.

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Regan
Sent: Monday, June 19, 2017 7:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSSMTP user exit and external email

Have you look at using Lionel Dyck's freeware XMITIP REXX program? More info 
available at 
https://protect2.fireeye.com/url?k=097bb6942d49e08b-e22c0dea1464f52c=http://www.lbdsoftware.com/xmitip.html
 .

On Mon, Jun 19, 2017 at 7:22 AM Jousma, David <david.jou...@53.com> wrote:

> Skip, Gil,
>
> Thanks for your feedback.  Our shop is really no different than many on
> this list.   Mainframe environment is held it a "higher standard", right or
> wrong.  Mainframe SMTP here has always been a roll your own as far as
> creating the SMTP text.   The biggest fear has been someone (internal)
> creating an email spoofing someone else, since there were no controls, and
> really there still aren’t any.   Sure, I can validate that the person
> submitting the email has the authority to do so, but from the 
> available exit in z/OS 2.2 world, I have no way to programmatically 
> validate that the person has formatted the contents of the email to be 
> from themselves, and not from someone else, and there-in lies the 
> problem for us.  Until z/OS
> 2.3 comes along with email addr support in RACF, how do I validate that?
> And yes, if someone did spoof the FROM:, we would go back through the 
> logs to see who did it, and take all appropriate actions.
>
> The #3 in my list is again just typical "higher standard" issues with 
> Audit.  The immediate need we have for allowing external email has to 
> do with limitations with the IDAA (Netizza) hardware doing problem
> notifications to IBM via EMAIL instead of a "phone home".   Audit wants us
> to limit the outbound to certain domains like *@xx.ibm.com.
>
> Skip, you brought up the RYO program at your shop.  I can see some 
> legitimacy in creating something like and doing the SAF calls as you 
> mention.  I suppose I could do a WHEN PROGRAM type spool access for 
> actually placing the formatted SMTP text on the spool as a way to ensure
> all email is properly formatted.   To do that, I'd have to create some
> yet-to-exist RACF(TSS) resource for every employee's email address for 
> the RYO program to read.  For that, I might as well wait until the 
> native support that arrives in z/OS V2.3.
>
> I am meeting with them again to understand their concerns about 
> mainframe vs Outlook email.
>
> _
> Dave Jousma
> Manager Mainframe Engineering, Assistant Vice President 
> david.jou...@53.com
> 1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 
> <(616)%20653-8429> f 616.653.2717 <(616)%20653-2717>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Jesse 1 Robinson
> Sent: Sunday, June 18, 2017 11:08 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: CSSMTP user exit and external email
>
> It was pointed out to me that I may have given #3 too short shrift. We 
> do not control destination addresses, but I suppose that a shop may 
> have such a requirement. Again: if not for Outlook, then why for SMTP?
>
> If one is to use a program to generate the SMTP text, then it would be 
> a simple extension to include a SAF check for the To: address. It 
> could be as high-level as validating the URL itself as eligible for 
> SMTP mail or a specific check that this particular Sender is allowed 
> to send mail to that URL. Like OP, I would strenuously avoid 
> hard-coding a whitelist even at the general URL level. SAF is flexible 
> and easy to use via standard product commands.
>
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 <(323)%20715-0595> Mobile
> 626-543-6132 <(626)%20543-6132> Office ⇐=== NEW robin...@sce.com
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Sunday, June 18, 2017 2:02 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: CSSMTP user exit and external email
>
> On 2017-06-17, at 21:06, Jesse 1 Robi

Re: CSSMTP user exit and external email

[Mark Regan]

Have you look at using Lionel Dyck's freeware XMITIP REXX program? More
info available at http://www.lbdsoftware.com/xmitip.html .

On Mon, Jun 19, 2017 at 7:22 AM Jousma, David <david.jou...@53.com> wrote:

> Skip, Gil,
>
> Thanks for your feedback.  Our shop is really no different than many on
> this list.   Mainframe environment is held it a "higher standard", right or
> wrong.  Mainframe SMTP here has always been a roll your own as far as
> creating the SMTP text.   The biggest fear has been someone (internal)
> creating an email spoofing someone else, since there were no controls, and
> really there still aren’t any.   Sure, I can validate that the person
> submitting the email has the authority to do so, but from the available
> exit in z/OS 2.2 world, I have no way to programmatically validate that the
> person has formatted the contents of the email to be from themselves, and
> not from someone else, and there-in lies the problem for us.  Until z/OS
> 2.3 comes along with email addr support in RACF, how do I validate that?
> And yes, if someone did spoof the FROM:, we would go back through the logs
> to see who did it, and take all appropriate actions.
>
> The #3 in my list is again just typical "higher standard" issues with
> Audit.  The immediate need we have for allowing external email has to do
> with limitations with the IDAA (Netizza) hardware doing problem
> notifications to IBM via EMAIL instead of a "phone home".   Audit wants us
> to limit the outbound to certain domains like *@xx.ibm.com.
>
> Skip, you brought up the RYO program at your shop.  I can see some
> legitimacy in creating something like and doing the SAF calls as you
> mention.  I suppose I could do a WHEN PROGRAM type spool access for
> actually placing the formatted SMTP text on the spool as a way to ensure
> all email is properly formatted.   To do that, I'd have to create some
> yet-to-exist RACF(TSS) resource for every employee's email address for the
> RYO program to read.  For that, I might as well wait until the native
> support that arrives in z/OS V2.3.
>
> I am meeting with them again to understand their concerns about mainframe
> vs Outlook email.
>
> _
> Dave Jousma
> Manager Mainframe Engineering, Assistant Vice President
> david.jou...@53.com
> 1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
> p 616.653.8429 <(616)%20653-8429>
> f 616.653.2717 <(616)%20653-2717>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jesse 1 Robinson
> Sent: Sunday, June 18, 2017 11:08 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: CSSMTP user exit and external email
>
> It was pointed out to me that I may have given #3 too short shrift. We do
> not control destination addresses, but I suppose that a shop may have such
> a requirement. Again: if not for Outlook, then why for SMTP?
>
> If one is to use a program to generate the SMTP text, then it would be a
> simple extension to include a SAF check for the To: address. It could be as
> high-level as validating the URL itself as eligible for SMTP mail or a
> specific check that this particular Sender is allowed to send mail to that
> URL. Like OP, I would strenuously avoid hard-coding a whitelist even at the
> general URL level. SAF is flexible and easy to use via standard product
> commands.
>
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 <(323)%20715-0595> Mobile
> 626-543-6132 <(626)%20543-6132> Office ⇐=== NEW
> robin...@sce.com
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Sunday, June 18, 2017 2:02 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: CSSMTP user exit and external email
>
> On 2017-06-17, at 21:06, Jesse 1 Robinson wrote:
>
> > We have an RYO program available to the entire company. I use it
> > routinely to send messages and attachments internally and externally
> > with no impediments. The author of this program feels that
> >
> > #1 is satisfied by simply allowing anyone to use it. Does OP have
> restrictions as to who can send ordinary email via Outlook/Lotus/whatever?
> If not, then why put onerous limitations on SMTP? If so, then there exists
> an extraordinary level of control that needs to be duplicated in the SMTP
> environment. No implementation suggestions.
> >
> I pretty much agree.  Looking at the headers of the OP's message:
>
> Received: from mailgw5.53.com ([2

Re: CSSMTP user exit and external email

[Jousma, David]

Skip, Gil,

Thanks for your feedback.  Our shop is really no different than many on this 
list.   Mainframe environment is held it a "higher standard", right or wrong.  
Mainframe SMTP here has always been a roll your own as far as creating the SMTP 
text.   The biggest fear has been someone (internal) creating an email spoofing 
someone else, since there were no controls, and really there still aren’t any.  
 Sure, I can validate that the person submitting the email has the authority to 
do so, but from the available exit in z/OS 2.2 world, I have no way to 
programmatically validate that the person has formatted the contents of the 
email to be from themselves, and not from someone else, and there-in lies the 
problem for us.  Until z/OS 2.3 comes along with email addr support in RACF, 
how do I validate that?  And yes, if someone did spoof the FROM:, we would go 
back through the logs to see who did it, and take all appropriate actions.

The #3 in my list is again just typical "higher standard" issues with Audit.  
The immediate need we have for allowing external email has to do with 
limitations with the IDAA (Netizza) hardware doing problem notifications to IBM 
via EMAIL instead of a "phone home".   Audit wants us to limit the outbound to 
certain domains like *@xx.ibm.com.

Skip, you brought up the RYO program at your shop.  I can see some legitimacy 
in creating something like and doing the SAF calls as you mention.  I suppose I 
could do a WHEN PROGRAM type spool access for actually placing the formatted 
SMTP text on the spool as a way to ensure all email is properly formatted.   To 
do that, I'd have to create some yet-to-exist RACF(TSS) resource for every 
employee's email address for the RYO program to read.  For that, I might as 
well wait until the native support that arrives in z/OS V2.3.

I am meeting with them again to understand their concerns about mainframe vs 
Outlook email.

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Sunday, June 18, 2017 11:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSSMTP user exit and external email

It was pointed out to me that I may have given #3 too short shrift. We do not 
control destination addresses, but I suppose that a shop may have such a 
requirement. Again: if not for Outlook, then why for SMTP?

If one is to use a program to generate the SMTP text, then it would be a simple 
extension to include a SAF check for the To: address. It could be as high-level 
as validating the URL itself as eligible for SMTP mail or a specific check that 
this particular Sender is allowed to send mail to that URL. Like OP, I would 
strenuously avoid hard-coding a whitelist even at the general URL level. SAF is 
flexible and easy to use via standard product commands. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Sunday, June 18, 2017 2:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: CSSMTP user exit and external email

On 2017-06-17, at 21:06, Jesse 1 Robinson wrote:

> We have an RYO program available to the entire company. I use it 
> routinely to send messages and attachments internally and externally 
> with no impediments. The author of this program feels that
> 
> #1 is satisfied by simply allowing anyone to use it. Does OP have 
> restrictions as to who can send ordinary email via Outlook/Lotus/whatever? If 
> not, then why put onerous limitations on SMTP? If so, then there exists an 
> extraordinary level of control that needs to be duplicated in the SMTP 
> environment. No implementation suggestions. 
>  
I pretty much agree.  Looking at the headers of the OP's message:

Received: from mailgw5.53.com ([216.82.180.36]) by mailapp-atl-1.ua.edu with
  ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jun 2017 06:30:34 -0500
X-IronPort-AV: E=Sophos;i="5.39,347,1493697600";
   d="dat'59?scan'59,208,59";a="65124346"
Received: from unknown (HELO SOFLOKYDCDLPS04.INFO53.COM) ([10.212.195.196]) 
by
  mailgw5.53.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Jun 2017
  07:30:33 -0400
Received: from S1FLOKYDCE2KX20.dm0001.info53.com
  (s1flokydce2kx20.dm0001.info53.com [10.212.163.30]) by
  SOFLOKYDCDLPS04.INFO53.COM (RSA Interceptor) for
  <ibm-main@listserv.ua.edu>; Fri

Re: CSSMTP user exit and external email

[Jesse 1 Robinson]

It was pointed out to me that I may have given #3 too short shrift. We do not 
control destination addresses, but I suppose that a shop may have such a 
requirement. Again: if not for Outlook, then why for SMTP?

If one is to use a program to generate the SMTP text, then it would be a simple 
extension to include a SAF check for the To: address. It could be as high-level 
as validating the URL itself as eligible for SMTP mail or a specific check that 
this particular Sender is allowed to send mail to that URL. Like OP, I would 
strenuously avoid hard-coding a whitelist even at the general URL level. SAF is 
flexible and easy to use via standard product commands. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Sunday, June 18, 2017 2:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: CSSMTP user exit and external email

On 2017-06-17, at 21:06, Jesse 1 Robinson wrote:

> We have an RYO program available to the entire company. I use it 
> routinely to send messages and attachments internally and externally 
> with no impediments. The author of this program feels that
> 
> #1 is satisfied by simply allowing anyone to use it. Does OP have 
> restrictions as to who can send ordinary email via Outlook/Lotus/whatever? If 
> not, then why put onerous limitations on SMTP? If so, then there exists an 
> extraordinary level of control that needs to be duplicated in the SMTP 
> environment. No implementation suggestions. 
>  
I pretty much agree.  Looking at the headers of the OP's message:

Received: from mailgw5.53.com ([216.82.180.36]) by mailapp-atl-1.ua.edu with
  ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jun 2017 06:30:34 -0500
X-IronPort-AV: E=Sophos;i="5.39,347,1493697600";
   d="dat'59?scan'59,208,59";a="65124346"
Received: from unknown (HELO SOFLOKYDCDLPS04.INFO53.COM) ([10.212.195.196]) 
by
  mailgw5.53.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Jun 2017
  07:30:33 -0400
Received: from S1FLOKYDCE2KX20.dm0001.info53.com
  (s1flokydce2kx20.dm0001.info53.com [10.212.163.30]) by
  SOFLOKYDCDLPS04.INFO53.COM (RSA Interceptor) for
  <ibm-main@listserv.ua.edu>; Fri, 16 Jun 2017 07:30:24 -0400
Received: from S1FLOKYDCE2KX05.dm0001.info53.com ([169.254.7.59]) by
  S1FLOKYDCE2KX20.dm0001.info53.com ([10.212.163.30]) with mapi id
  14.03.0319.002; Fri, 16 Jun 2017 07:30:24 -0400
...
Sender:   IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
From: "Jousma, David" <david.jou...@53.com>

(Note the proper use of "From:" vis-a-vis "Sender:".)  ("169.254.7.59"?  
A self-assigned IP address, not more typical DHCP?)

and:
502 $ nslookup
> set query=mx
> 53.com
Server: 205.171.3.25
Address:205.171.3.25#53

Non-authoritative answer:
53.com  mail exchanger = 10 mailgw9.53.com.
53.com  mail exchanger = 10 mailgw5.53.com.
53.com  mail exchanger = 10 mailgw3.53.com.
53.com  mail exchanger = 10 mailgw7.53.com.

It appears that 53.com has (several) smart mail host(s).  These should be 
capable of enforcing all of 53.com's corporate standards if CSSMTP is 
configured to route via mailgw*.53.com.  The tricky part may be to get David's 
z/OS jobs to properly present "David.Jousma's" credentials to that smart host.  
How do 53.com's employees currently identify themselves to their SMTP server?  
For the ISP I'm using here and Linux, I can keep the information in 
~/.mutt/muttrc, but synching is manual.

There should not be a z/OS user exit replicating the smart host rules and 
attempting to stay synchronized with them.

> #2 is handled by the RYO program, which fetches sender name from SAF. User 
> can place any desired name in the From: field for visibility, but the true 
> identity is revealed and documented via SAF. One day a rogue user 
> impersonates the CIO. Next day she is required to present her true name at 
> the unemployment office. 
> 
> #3 seems pointless. If the To: user does not exist at the named URL, then the 
> email fails. Just like any other incorrectly addressed email. Whether 
> internal or external. What is to be gained by blocking the user from an 
> everyday typo? Does anyone do that for standard email? 
> 
> -Original Message-
> From: Jousma, David
> Sent: Friday, June 16, 2017 4:30 AM
> 
> I'm looking for some feedback from shops that are already doing this.  We 
> converted to the newer CSSMT

Re: CSSMTP user exit and external email

[Paul Gilmartin]

On 2017-06-17, at 21:06, Jesse 1 Robinson wrote:

> We have an RYO program available to the entire company. I use it routinely to 
> send messages and attachments internally and externally with no impediments. 
> The author of this program feels that 
> 
> #1 is satisfied by simply allowing anyone to use it. Does OP have 
> restrictions as to who can send ordinary email via Outlook/Lotus/whatever? If 
> not, then why put onerous limitations on SMTP? If so, then there exists an 
> extraordinary level of control that needs to be duplicated in the SMTP 
> environment. No implementation suggestions. 
>  
I pretty much agree.  Looking at the headers of the OP's message:

Received: from mailgw5.53.com ([216.82.180.36]) by mailapp-atl-1.ua.edu with
  ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jun 2017 06:30:34 -0500
X-IronPort-AV: E=Sophos;i="5.39,347,1493697600";
   d="dat'59?scan'59,208,59";a="65124346"
Received: from unknown (HELO SOFLOKYDCDLPS04.INFO53.COM) ([10.212.195.196]) 
by
  mailgw5.53.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Jun 2017
  07:30:33 -0400
Received: from S1FLOKYDCE2KX20.dm0001.info53.com
  (s1flokydce2kx20.dm0001.info53.com [10.212.163.30]) by
  SOFLOKYDCDLPS04.INFO53.COM (RSA Interceptor) for
  ; Fri, 16 Jun 2017 07:30:24 -0400
Received: from S1FLOKYDCE2KX05.dm0001.info53.com ([169.254.7.59]) by
  S1FLOKYDCE2KX20.dm0001.info53.com ([10.212.163.30]) with mapi id
  14.03.0319.002; Fri, 16 Jun 2017 07:30:24 -0400
...
Sender:   IBM Mainframe Discussion List 
From: "Jousma, David" 

(Note the proper use of "From:" vis-a-vis "Sender:".)  ("169.254.7.59"?  
A self-assigned IP address, not more typical DHCP?)

and:
502 $ nslookup
> set query=mx
> 53.com
Server: 205.171.3.25
Address:205.171.3.25#53

Non-authoritative answer:
53.com  mail exchanger = 10 mailgw9.53.com.
53.com  mail exchanger = 10 mailgw5.53.com.
53.com  mail exchanger = 10 mailgw3.53.com.
53.com  mail exchanger = 10 mailgw7.53.com.

It appears that 53.com has (several) smart mail host(s).  These should
be capable of enforcing all of 53.com's corporate standards if CSSMTP is
configured to route via mailgw*.53.com.  The tricky part may be to get
David's z/OS jobs to properly present "David.Jousma's" credentials to
that smart host.  How do 53.com's employees currently identify
themselves to their SMTP server?  For the ISP I'm using here and Linux,
I can keep the information in ~/.mutt/muttrc, but synching is manual.

There should not be a z/OS user exit replicating the smart host rules and
attempting to stay synchronized with them.

> #2 is handled by the RYO program, which fetches sender name from SAF. User 
> can place any desired name in the From: field for visibility, but the true 
> identity is revealed and documented via SAF. One day a rogue user 
> impersonates the CIO. Next day she is required to present her true name at 
> the unemployment office. 
> 
> #3 seems pointless. If the To: user does not exist at the named URL, then the 
> email fails. Just like any other incorrectly addressed email. Whether 
> internal or external. What is to be gained by blocking the user from an 
> everyday typo? Does anyone do that for standard email? 
> 
> -Original Message-
> From: Jousma, David
> Sent: Friday, June 16, 2017 4:30 AM
> 
> I'm looking for some feedback from shops that are already doing this.  We 
> converted to the newer CSSMTP a year or so ago.  Up until now, the only email 
> generated from our mainframe systems has been internal email only.  It's 
> mostly simple reports from batch jobs, etc.  Any attempt to send email 
> externally has been rejected.   We have had quite a few requests to allow for 
> external email, and have been reviewing the controls that are available.  So, 
> there are at least 3 challenges we can think of:
> 
> 1)  Who is allowed to send external email?  We are able to control *who* 
> can successfully deposit mail in the spool by securing the writer name that 
> CSSMTP looks at, and only allow authorized users to send external email.
> 
> 2)  Validating the FROM on the email content?  Audit & Risk are concerned 
> with rogue email claiming to be from CEO, etc.  We are mostly mitigating this 
> by item #1, and only allowing a "from" of 
> nore...@53.com with a custom EZATCPIPCSSMTPV3 exit.   
> This issue should be solved with z/OS V2.3 with the added email support in 
> RACF and JES.
> 
> 3)  Validating at least at the domain level, the TO: recipients.  Not 
> sure how to handle this.  Don't really want to hard code a whitelist of 
> allowed domains.
> 
> Any ideas on how to handle #3 above?
>  
For all of #1, #2, and #3, rely on your company's 

Re: CSSMTP user exit and external email

[Jesse 1 Robinson]

We have an RYO program available to the entire company. I use it routinely to 
send messages and attachments internally and externally with no impediments. 
The author of this program feels that 

#1 is satisfied by simply allowing anyone to use it. Does OP have restrictions 
as to who can send ordinary email via Outlook/Lotus/whatever? If not, then why 
put onerous limitations on SMTP? If so, then there exists an extraordinary 
level of control that needs to be duplicated in the SMTP environment. No 
implementation suggestions. 

#2 is handled by the RYO program, which fetches sender name from SAF. User can 
place any desired name in the From: field for visibility, but the true identity 
is revealed and documented via SAF. One day a rogue user impersonates the CIO. 
Next day she is required to present her true name at the unemployment office. 

#3 seems pointless. If the To: user does not exist at the named URL, then the 
email fails. Just like any other incorrectly addressed email. Whether internal 
or external. What is to be gained by blocking the user from an everyday typo? 
Does anyone do that for standard email? 



.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Friday, June 16, 2017 4:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):CSSMTP user exit and external email

All,

I'm looking for some feedback from shops that are already doing this.  We 
converted to the newer CSSMTP a year or so ago.  Up until now, the only email 
generated from our mainframe systems has been internal email only.  It's mostly 
simple reports from batch jobs, etc.  Any attempt to send email externally has 
been rejected.   We have had quite a few requests to allow for external email, 
and have been reviewing the controls that are available.  So, there are at 
least 3 challenges we can think of:


1)  Who is allowed to send external email?  We are able to control *who* 
can successfully deposit mail in the spool by securing the writer name that 
CSSMTP looks at, and only allow authorized users to send external email.

2)  Validating the FROM on the email content?  Audit & Risk are concerned 
with rogue email claiming to be from CEO, etc.  We are mostly mitigating this 
by item #1, and only allowing a "from" of nore...@53.com 
with a custom EZATCPIPCSSMTPV3 exit.   This issue should be solved with z/OS 
V2.3 with the added email support in RACF and JES.

3)  Validating at least at the domain level, the TO: recipients.  Not sure 
how to handle this.  Don't really want to hard code a whitelist of allowed 
domains.

Any ideas on how to handle #3 above?

dave


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN