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 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 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<mailto: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 smart mail host. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
