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 [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Jousma, David Sent: Friday, June 16, 2017 4:30 AM To: [email protected] 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 [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? dave ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
