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