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
