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 <[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> > f 616.653.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> Mobile > 626-543-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
