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: [email protected] / *[email protected] <[email protected]>* LinkedIn: http://br.linkedin.com/in/lrosalen Phone: +48 (71) 792 809 198 2017-06-19 14:30 GMT+02:00 Mark Regan <[email protected]>: > 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 <[email protected]> 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 > > [email protected] > > 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:[email protected]] On > > Behalf Of Mark Regan > > Sent: Monday, June 19, 2017 7:45 AM > > To: [email protected] > > 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&u=http://www.lbdsoftware.com/xmitip.html > > . > > > > On Mon, Jun 19, 2017 at 7:22 AM Jousma, David <[email protected]> > 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 > > > [email protected] > > > 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:[email protected]] > > > On Behalf Of Jesse 1 Robinson > > > Sent: Sunday, June 18, 2017 11:08 AM > > > To: [email protected] > > > 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> <(323)%20715-0595> Mobile > > > 626-543-6132 <(626)%20543-6132> <(626)%20543-6132> Office ⇐=== NEW > > [email protected] > > > > > > > > > -----Original Message----- > > > From: IBM Mainframe Discussion List [mailto:[email protected]] > On > > > Behalf Of Paul Gilmartin > > > Sent: Sunday, June 18, 2017 2:02 AM > > > To: [email protected] > > > 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 > > > <[email protected]>; 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 < > > [email protected]> > > > From: "Jousma, David" <[email protected]> > > > > > > (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 > [email protected] > > > <mailto:[email protected]> 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 smart mail host. > > > > > > -- gil > > > > > > > > > ---------------------------------------------------------------------- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to [email protected] 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 [email protected] with the message: INFO IBM-MAIN > > > > > -- > > > > Regards, > > > > Mark T. Regan > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to [email protected] 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 [email protected] with the message: INFO IBM-MAIN > > > -- > > Regards, > > Mark T. Regan > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
