topic Re: Restricting sending emails to external email ids from Linux using sas program in Administration and Deployment

Restricting sending emails to external email ids from Linux using sas program

sasprofile — Sat, 30 Jul 2016 03:51:40 GMT

Hello friends

I have a question how can I restrict someone sending emails to external(personal)and internal email ids from Linux server using sas program or email program.

I would appreciate anyone's suggestions and ideas on this

Thank you in Advance

Re: Restricting sending emails to external email ids from Linux using sas program

ChrisHemedinger — Sat, 30 Jul 2016 15:14:17 GMT

You want to prevent a user from programmatically sending e-mails using FILENAME EMAIL or another SMTP utility?

I don't think that there is a way to restrict this in SAS (the LOCKDOWN option doesn't seem to include FILENAME EMAIL, though you could try it). Ideally, you would restrict the SMTP server itself -- even if you prevent the SAS language from using it, seems like you're after a wider approach that would also restrict the many "built-in" tools that offer SMTP access.

Re: Restricting sending emails to external email ids from Linux using sas program

sasprofile — Sat, 30 Jul 2016 21:26:10 GMT

Yes my question is,Is there any way to encrypt the Emails that are sent from SAS code,because there is a chance that emails might have sensitive data.

Re: Restricting sending emails to external email ids from Linux using sas program

SASKiwi — Sun, 31 Jul 2016 19:33:19 GMT

Encryption of emails would be a feature of your email system - nothing to do with SAS. Talk to your email administrator.

Re: Restricting sending emails to external email ids from Linux using sas program

sasprofile — Mon, 01 Aug 2016 06:21:28 GMT

SASKiwi Thanks for your reply So you are saying there is now way to encrypt the E-Mails that will be sent from SAS Codem, but I have seen from below SAS Note,There is away.but when I used its not working may be am not using in the right way. From the below SAS link it says we can use the EMAIL access method with secure SMTP servers by specifying the Transport Layer Security (TLS) protocol in the EMAILHOST= system option. TLS encrypts data between the client and the outgoing SMTP Server. This action does not guarantee an encrypted connection between the client and the recipient of the message. Message-level encryption and digital signing are currently not supported. For more information, see EMAILHOST= System Option in SAS System Options: Reference. (http://support.sas.com/documentation/cdl/en/lestmtsref/68024/HTML/default/viewer.htm#n0ig2krarrz6vtn1aw9zzvtez4qo.htm): so am not sure as per the above Note from SAS does this blocking the external Email id works or not,please advice me. below is the code I tried with,but looks like its not working for me. options emailsys = smtp emailid = 'testemail@abc.com' emailpw = 'test123' emailhost = 'smtp.abc.com' emailport = 25 ; options emailhost= ( "smtp.abc.com" STARTTLS auth=LOGIN /* your Outlook address */ id='testemail@abc.com' /* optional: encode PW with PROC PWENCODE */ pw="test123" port=587 ) ; filename f_email email to = 'testemail@abc.com' from = 'testemail123@abc.com' subject = 'Automatic Email Sending Test'; data _null_; file f_email; put 'This is a test email with an RTF attachment via SAS programming.'; run;

Re: Restricting sending emails to external email ids from Linux using sas program

PaulHomes — Mon, 01 Aug 2016 08:07:51 GMT

I think there might be a confusion here between session encryption (such as TLS/STARTTLS) and message encryption (such as S/MIME).

The code you posted uses SAS to send an email by connecting to an SMTP server, initially unencrypted on port 587, and then upgrading the connection to encrypted using STARTTLS. The transfer of the message between SAS (as a client) and the SMTP server is then over an encrypted connection. Someone on the same network that could capture the traffic would have a hard time decrypting it. However the email message itself is not encrypted. The server that received the message may not be the ultimate destination for the receipient. It may relay the message onto another server (or series of servers) before it gets to the recipient. Any of those intermediate servers can inspect the message contents. Additionally you cannot be sure that any of those intermediate servers will use TLS when passing the message on (after the initial exchange between SAS and the first server). Where this is an issue, email message encryption (such as S/MIME) can be considered. In that situation the message itself is encrypted for the recipient(s) such that only the receipient(s) should be able to decrypt it. The message may or may not pass over encrypted connections between the intermediate servers and the intermediate servers will not be able to decrypt the message contents.

My understanding is that SAS supports session encryption (TLS/STARTTLS) but not message encryption such as S/MIME.

You mentioned the code didn't work for you but you didn't post the error you got. You may want to talk to your local email admin as they will be able to advise which ports the server will accept messages on and the protocols that it supports.

Re: Restricting sending emails to external email ids from Linux using sas program

PaulHomes — Mon, 01 Aug 2016 08:20:53 GMT

@ChrisHemedinger - I noted that the documentation link posted below by @sasprofileon the filename statement email acess method states that:

When SAS is in a locked-down state, the FILENAME statement, EMAIL access method is not available. Your server administrator can re-enable this access method so that it is accessible in the locked-down state. For more information, see SAS Processing Restrictions for Servers in a Locked-Down State in SAS Language Reference: Concepts.

Of course, as you suggested, there may still be other ways to email SAS output - attachments via PC email clients, photos via smartphones etc. It sounds like it would be a good idea for @sasprofile to talk to their in-house security team about their support and policies for outbound email monitoring and data leakage prevention in general.