Re: Sending email from the Mainframe

[Seymour J Metz]

My source is the IETF, and every issue is a semantic issue. I did searches for 
bounce and DSN on a bunch of RFCs, and they all agreed. In particular, thr RFC 
that you cited, 3464, lists DSN types that are not bounces.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Grant Taylor <023065957af1-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, August 30, 2020 11:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Sending email from the Mainframe

On 8/29/20 6:50 PM, Seymour J Metz wrote:
> According to the IETF, every bounce is a DSN but not every DSN is a bounce.

Would you please cite your source?

I also wonder if we're having somewhat of a semantic issue.  I'm
specifically referring to a bounce (which is a superset of the latter)
that is formatted per RFC 3464 -- An Extensible Message Format for
Delivery Status Notifications (which is a subset of the former).

Per RFC 3462 § 2 — Format of a Delivery Status Notification — A DSN is a
MIME message with a top-level content-type of multipart/report (defined
in [REPORT]).  When a multipart/report content is used to transmit a DSN:

(a) The report-type parameter of the multipart/report content is
"delivery-status".

(b) The first component of the multipart/report contains a
human-readable explanation of the DSN, as described in [REPORT].

(c) The second component of the multipart/report is of content-type
message/delivery-status, described in section 2.1 of this document.

(d) If the original message or a portion of the message is to be
returned to the sender, it appears as the third component of the
multipart/report.

Not all bounces conform to these specifications, ergo not all bounces
are a DSN (as specified by RFC 3462).  All (failure) DSNs are bounces.

Aside:  I guess there are also success DSNs.  I don't know if they would
be considered a bounce or not.  They are an email about the delivery of
another email, thus fall into the category of bounce like email.



--
Grant. . . .
unix || die

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sending email from the Mainframe

[Grant Taylor]

On 8/29/20 6:50 PM, Seymour J Metz wrote:

According to the IETF, every bounce is a DSN but not every DSN is a bounce.


Would you please cite your source?

I also wonder if we're having somewhat of a semantic issue.  I'm 
specifically referring to a bounce (which is a superset of the latter) 
that is formatted per RFC 3464 -- An Extensible Message Format for 
Delivery Status Notifications (which is a subset of the former).


Per RFC 3462 § 2 — Format of a Delivery Status Notification — A DSN is a 
MIME message with a top-level content-type of multipart/report (defined 
in [REPORT]).  When a multipart/report content is used to transmit a DSN:


(a) The report-type parameter of the multipart/report content is 
"delivery-status".


(b) The first component of the multipart/report contains a 
human-readable explanation of the DSN, as described in [REPORT].


(c) The second component of the multipart/report is of content-type 
message/delivery-status, described in section 2.1 of this document.


(d) If the original message or a portion of the message is to be 
returned to the sender, it appears as the third component of the 
multipart/report.


Not all bounces conform to these specifications, ergo not all bounces 
are a DSN (as specified by RFC 3462).  All (failure) DSNs are bounces.


Aside:  I guess there are also success DSNs.  I don't know if they would 
be considered a bounce or not.  They are an email about the delivery of 
another email, thus fall into the category of bounce like email.




--
Grant. . . .
unix || die

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sending email from the Mainframe

[Seymour J Metz]

Your question has an assumption contrary to fact. Just because you get a 220 
response doesn't meant that the message has been delivered. In fact, it doesn't 
even guaranty that the destination mailbox is valid; the receiving server could 
relay the message to another server that checks addresses; and, yes, such 
configurations exist, whether they should or not.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Grant Taylor <023065957af1-dmarc-requ...@listserv.ua.edu>
Sent: Friday, August 28, 2020 10:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Sending email from the Mainframe

On 8/28/20 5:44 PM, Seymour J Metz wrote:
> Doing a direct to MX session will let you see rejection messages,
> but your firewall may not allow that and even if it does you could
> get a subsequesen DSN.

If you are the sending system, you would be the one to generate said
DSN.  So ... why would you generate a DSN when you already know that the
recipient is not valid.



--
Grant. . . .
unix || die

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sending email from the Mainframe

[Seymour J Metz]

According to the IETF, every bounce is a DSN but not every DSN is a bounce.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Grant Taylor <023065957af1-dmarc-requ...@listserv.ua.edu>
Sent: Friday, August 28, 2020 10:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Sending email from the Mainframe

On 8/28/20 5:46 PM, Seymour J Metz wrote:
> A DSN *is* a standard bounce.

Yes.  But not all bounces are DSNs.



--
Grant. . . .
unix || die

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sending email from the Mainframe

[Grant Taylor]

On 8/28/20 5:46 PM, Seymour J Metz wrote:

A DSN *is* a standard bounce.


Yes.  But not all bounces are DSNs.



--
Grant. . . .
unix || die

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sending email from the Mainframe

[Grant Taylor]

On 8/28/20 5:44 PM, Seymour J Metz wrote:
Doing a direct to MX session will let you see rejection messages, 
but your firewall may not allow that and even if it does you could 
get a subsequesen DSN.


If you are the sending system, you would be the one to generate said 
DSN.  So ... why would you generate a DSN when you already know that the 
recipient is not valid.




--
Grant. . . .
unix || die

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sending email from the Mainframe

[Seymour J Metz]

I agree that a mail to SPOOL gateway would be nice and an RFE would be 
appropriate. I'm not sure that I would call dropping the facility a glaring 
deficiency, but it is certainly unfortunate.

I assume that IBM simply wants people to use an e-mail client off of the 
mainframe.

No, adding errors-to doesn't change anything; you still need an external mail 
application to read the response once SMTP is gone.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Friday, August 28, 2020 9:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Sending email from the Mainframe

On Fri, 28 Aug 2020 13:01:54 +, Seymour J Metz wrote:

>Once CSSMTP has submitted your e-mail, it has no involvement. You should get a 
>DSN if there is a problem, but, unlike SMTP, CSSMTP does not handle incoming 
>mail.

The inability to handle Delivery Status Notifications is a glaring
deficiency of CSSMTP, worthy of an RFE to repair this regression.

Might this be partly mitigated by supplying an "Errors-to:" header?

Was security a motivator for ending support of incoming mail,
possibly because DSNs often reproduce the entire, possibly
sensitive, email bodies?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sending email from the Mainframe

[Seymour J Metz]

Note that silently dropping suspected spam, or silently moving it to a junk 
folder, greatly increases the cost of false positives. A well managed mail 
system sends 55x responses and DSNs for suspected spam. 

Also note that a user may be sorting legitimate mail based on, e.g., source, 
subject,  and that he may not examine all of his inboxes with the same 
frequency.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Joel C. Ewing 
Sent: Friday, August 28, 2020 9:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Sending email from the Mainframe

You seem to be asking for an impossibility here because the email
protocol as currently implemented doesn't support this.There is no
way for a sender of email to distinguish between email that is accepted
by its target domain but classed (correctly or incorrectly) as  spam and
thrown into the bit bucket to protect end users and make spammers waste
their transmission resources, and email that is accepted and actually
stored for retrieval by the recipient.  Some servers won't even tell a
sender if the target email account doesn't exist, because that info is
also useful to spammers.   So, "successful" transmission to the target
domain can occur even when there will be no actual delivery to any end
user, and email rejection by the receiving domain is only a subset of
the potential failures.

Even successful receipt and successful storage of an email by the target
domain doesn't mean that the intended recipient will ever login to the
account, retrieve it and actually read it.   In fact, the user's local
email client may even have additional filters that trash some received
email based on his own criteria.  Acceptance by the domain's mail server
doesn't mean the email will ever be "delivered" to the actual end user.

The email protocol does still allow for requesting a return email
receipt when the email is actually opened, but that was one of the first
features grossly abused by spammers wanting to locate actively-used
email accounts; so all reasonable email clients default to suppression
of automatic "receipt" responses.  It would have to be a highly unusual
situation before most informed users would ever allow a receipt to be
returned.

Being able to accurately verify successful delivery of email to an
actual email account would be a tremendous boon to spammers and other
undesirable users of emai, so I wouldn't expect to see this situation
change until much better ways of dealing with that problem exist.

The only way at present to know for certain that email was actually
sent, delivered, and read requires co-operation by the recipient to send
a return email reply that has content that clearly demonstrates it is
not just an automated response to the  received email.  Other than that,
there is always room for some uncertainty that a failure could have
occurred that prevented receipt.
Joel C Ewing

On 8/28/20 6:57 AM, Sasso, Len wrote:
> Does anyone have JCL that sends an email, using CSSMTP, from the Mainframe 
> and if it is unable to be delivered, for any reason, sends an email back to 
> the Sender with a corresponding message?
>
>
> Thank You and Please Be Safe!
>
> Len Sasso
> Systems Administrator Senior
> CSRA, A General Dynamics Information Technology Company
> 327 Columbia TPKE
> Rensselaer, NY 12144
>
> Office Hours: M-F  7 AM - 3:45 PM
> Out-Of-Office: Friday, August 28, 2020  Noon - 3:45 PM
> Phone: (518) 257-4209
> Cell: (518) 894-0879
> Fax: (518) 257-4300
> len.sa...@gdit.com
> URL: www.gdit.com<http://www.gdit.com>
>
>
>
>
...

--
Joel C. Ewing

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sending email from the Mainframe

[Seymour J Metz]

A DSN *is* a standard bounce.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Grant Taylor <023065957af1-dmarc-requ...@listserv.ua.edu>
Sent: Friday, August 28, 2020 11:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Sending email from the Mainframe

On 8/28/20 7:36 AM, Paul Gilmartin wrote:
> The inability to handle Delivery Status Notifications is a glaring
> deficiency of CSSMTP, worthy of an RFE to repair this regression.

DSNs / MDNs / other non-standard bounces don't need to come back into
CSSMTP.  The just need to come back into an SMTP server.  It can be any
SMTP server, including the main corporate SMTP server.

It is entirely possible to send messages from CSSMTP and have the
bounces go back to a different server, and then collect bounces or
otherwise process them there.

> Might this be partly mitigated by supplying an "Errors-to:" header?

Unnecessary.

> Was security a motivator for ending support of incoming mail,
> possibly because DSNs often reproduce the entire, possibly
> sensitive, email bodies?

You can influence what is returned by using the optional "RET=HDRS"
parameter to the MAIL FROM statement.  Standards compliant servers
should only return the headers and not the message body.



--
Grant. . . .
unix || die

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sending email from the Mainframe

[Seymour J Metz]

Only use a web bug if you know that the receiving system won't treat it as spam 
and that the recieving mail client is configured to render HTML.

Doing a direct to MX session will let you see rejection messages, but your 
firewall may not allow that and even if it does you could get a subsequesen DSN.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Grant Taylor <023065957af1-dmarc-requ...@listserv.ua.edu>
Sent: Friday, August 28, 2020 12:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Sending email from the Mainframe

On 8/28/20 7:39 AM, Joel C. Ewing wrote:
> You seem to be asking for an impossibility here because the email
> protocol as currently implemented doesn't support this.

There is a way to have a relatively good indication if a message was
displayed or not.  It relies on HTML and unique per message URLs.  But
even that is not guaranteed.  It's just considerably more likely to
succeed than other methods.

> There is no way for a sender of email to distinguish between email
> that is accepted by its target domain but classed (correctly or
> incorrectly) as  spam and thrown into the bit bucket to protect end
> users and make spammers waste their transmission resources, and email
> that is accepted and actually stored for retrieval by the recipient.

Agreed.  It's very difficult, neigh impossible, to accurately detect
good email addresses.

> Some servers won't even tell a sender if the target email account
> doesn't exist, because that info is also useful to spammers.   So,
> "successful" transmission to the target domain can occur even when
> there will be no actual delivery to any end user, and email rejection
> by the receiving domain is only a subset of the potential failures.

However you can flip the logic on it's head.  You can detect known bad
email addresses and "fail fast".

If your JCL / job is doing it's own SMTP (and not relying on something
else to do it on it's behalf) it can deduce the SMTP rejections and have
a high degree of certainty that the email address has a problem.  This
also means that your JCL / job is not dependent on the DSN because it
has visibility to the SMTP status codes directly.

Remember, the DSN is a way for a sending SMTP server to notify a sender
which is outside of the SMTP exchange that there was a problem during /
inside of the SMTP exchange.

> The email protocol does still allow for requesting a return email
> receipt when the email is actually opened, but that was one of
> the first features grossly abused by spammers wanting to locate
> actively-used email accounts; so all reasonable email clients default
> to suppression of automatic "receipt" responses.

This is actually not part of the SMTP protocol.  Message Disposition
Notifications are a feature implemented by email clients and the senders
desire to receive one is conveyed by a header in the message.  The SMTP
server is oblivious to this.

SMTP is Delivery Status Notification
eMail client is Message Disposition Notification

> It would have to be a highly unusual situation before most informed
> users would ever allow a receipt to be returned.

I have on occasion responded to / allowed an MDN request.  But as a
general rule I have my email client prompt me and I almost always deny
the request.  About the only time I'll allow it is if it's from someone
I know on a topic that I am willing to voluntarily share that information.

> The only way at present to know for certain that email was actually
> sent, delivered, and read requires co-operation by the recipient to
> send a return email reply that has content that clearly demonstrates it
> is not just an automated response to the  received email.  Other than
> that, there is always room for some uncertainty that a failure could
> have occurred that prevented receipt.

There's a reason that Message Disposition Notifications use the term
"disposition".  Meaning that the message was displayed or printed.
There is no way that a computer can guarantee that the message was
actually read.  At least not currently.



--
Grant. . . .
unix || die

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sending email from the Mainframe

[Grant Taylor]

On 8/28/20 11:46 AM, Statler, David wrote:
You may be able to utilize the "Undeliverable" feature in the CSSSMTP 
Config setup. You can specify the action to take (store or delete) 
on a dead letter and a unix directory to store it in.


What does CSSMTP do if I send email from a perfectly valid (corporate) 
email address and it's unable to send my original message to the 
recipient(s) for some reason?


I would expect that CSSMTP would generate a bounce (proper RFC DSN) and 
send it to the my perfectly valid (corporate) email address.


That's what other contemporary MTAs do and what the RFCs indicate should 
be done.




--
Grant. . . .
unix || die

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sending email from the Mainframe

[Statler, David]

You may be able to utilize the "Undeliverable" feature in the CSSSMTP Config 
setup. You can specify the action to take (store or delete) on a dead letter 
and a unix directory to store it in.

David

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Sasso, Len
Sent: Friday, August 28, 2020 6:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Sending email from the Mainframe

Does anyone have JCL that sends an email, using CSSMTP, from the Mainframe and 
if it is unable to be delivered, for any reason, sends an email back to the 
Sender with a corresponding message?


Thank You and Please Be Safe!

Len Sasso
Systems Administrator Senior
CSRA, A General Dynamics Information Technology Company
327 Columbia TPKE
Rensselaer, NY 12144

Office Hours: M-F  7 AM - 3:45 PM
Out-Of-Office: Friday, August 28, 2020  Noon - 3:45 PM
Phone: (518) 257-4209
Cell: (518) 894-0879
Fax: (518) 257-4300
len.sa...@gdit.com
URL: 
https://protect2.fireeye.com/v1/url?k=d6ec75ce-8aadedc4-d6eeb904-0cc47a6d17ce-a101fbc807c29bfb=1=755c3fc4-a8e5-4af5-b36f-63034689dc4b=http%3A%2F%2Fwww.gdit.com%2F<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.gdit.com=DwIFAw=GSntNbUav5AC0JJIyPOufmfQT3u3zI7UKdoVzPd-7og=tIdjUplbIRGr4vkhlZCB7B_ivXjfG-CqQQpihq7_n5M=A3jH5NdknLIxIZ4iLhDO1ytRnN9_5HaAKpTTN1skTwU=eI5UbwvjxzRAFIvz4k92mpp_x_wDiI4uvQ3k-gW9uKs=
 >





From: IBM Mainframe Discussion List  on behalf of 
Timothy Sipples 
Sent: Friday, July 24, 2020 5:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Sending email from the Mainframe



 [External: Use caution with links & attachments]

Grant Taylor asks:
>What happens to email if CSSMTP (AT-TLS) is configured to *require* 
>encryption and the receiving system doesn't support encryption?

Fundamentally the same thing(s) that happen when the network connection is down 
or too slow (times out), for whatever reasons. Network encryption is part and 
parcel of the network path. This class of failures must already be catered for. 
In this case, Len Sasso's organization is mandating TLS 1.2+, and I agree with 
Shmuel Metz who wrote:
>If management has decreed that all SMTP traffic be encrypted, then 
>barring a configuration error the relay will accept encrypted traffic.

Moreover, it's entirely possible that your attitude would only increase relay 
administrators' burdens, the people who currently have to manage, support, 
monitor, and audit the e-mail traffic from the one and only system still 
transmitting over an unencrypted connection, a connection modality they'd very 
much like to retire as quickly as possible. You know, that "old, obsolete 
mainframe" that you're actively arguing should actually be as old and obsolete 
as you can possibly force it to be. (TLS is *really* not new.) Or it's entirely 
possible that the relay administrators aren't inclined or equipped to provide 
even mediocre service levels for unencrypted connections, or even that there's 
a lone dedicated relay gathering dust in a wiring closet somewhere to support 
this one unencrypted connection, a relay that nobody left in the organization 
even understands or really knows about, that isn't backed up or DR protected, 
that still runs on a 10 Mbps Ethernet segment that miraculously hasn't been 
disconnected yet. Hence the unencrypted connection is MORE prone to failure, 
not less. All very possible, even predictable and likely. And I haven't even 
gotten to the regulatory issues and penalties.

Conceivably you could also reduce or eliminate your personal security 
authentication failure planning and handling (hopefully automated) 
responsibilities if you effectively disable your SAF security provider, such as 
RACF. Then those few pesky authentication and authorization rejections wouldn't 
occur, and everyone could just go to the pub and stay there (or whatever). 
That's the logical consequence of your argument, isn't it? I don't think you've 
got a strong argument.

Sorry to be blunt here, but I feel compelled to offer my personal view (as 
always). My colleagues (and I mean that word expansively, in and out of
IBM) work really hard to deliver and support truly cutting edge capabilities, 
including downright amazing security capabilities, in/for this unique and 
indispensable platform. And this community, overall, often works really hard to 
put these capabilities into practice, in many cases literally to keep 
civilization functioning. Then there are a few people who manage a few of these 
systems, and...well, let's all strive to do better, OK?

[Why am I expecting a minor Twitter storm now? :-)]

- - - - - - - - - -
Timothy Sipples
I.T. Architect Executive
Digital Asset & Other Industry Solutions IBM Z & LinuxONE
- - - - - - - - - -
E-Mail: sipp...@sg.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists.

Re: Sending email from the Mainframe

[Grant Taylor]

On 8/28/20 7:39 AM, Joel C. Ewing wrote:
You seem to be asking for an impossibility here because the email 
protocol as currently implemented doesn't support this.


There is a way to have a relatively good indication if a message was 
displayed or not.  It relies on HTML and unique per message URLs.  But 
even that is not guaranteed.  It's just considerably more likely to 
succeed than other methods.


There is no way for a sender of email to distinguish between email 
that is accepted by its target domain but classed (correctly or 
incorrectly) as  spam and thrown into the bit bucket to protect end 
users and make spammers waste their transmission resources, and email 
that is accepted and actually stored for retrieval by the recipient.


Agreed.  It's very difficult, neigh impossible, to accurately detect 
good email addresses.


Some servers won't even tell a sender if the target email account 
doesn't exist, because that info is also useful to spammers.   So, 
"successful" transmission to the target domain can occur even when 
there will be no actual delivery to any end user, and email rejection 
by the receiving domain is only a subset of the potential failures.


However you can flip the logic on it's head.  You can detect known bad 
email addresses and "fail fast".


If your JCL / job is doing it's own SMTP (and not relying on something 
else to do it on it's behalf) it can deduce the SMTP rejections and have 
a high degree of certainty that the email address has a problem.  This 
also means that your JCL / job is not dependent on the DSN because it 
has visibility to the SMTP status codes directly.


Remember, the DSN is a way for a sending SMTP server to notify a sender 
which is outside of the SMTP exchange that there was a problem during / 
inside of the SMTP exchange.


The email protocol does still allow for requesting a return email 
receipt when the email is actually opened, but that was one of 
the first features grossly abused by spammers wanting to locate 
actively-used email accounts; so all reasonable email clients default 
to suppression of automatic "receipt" responses.


This is actually not part of the SMTP protocol.  Message Disposition 
Notifications are a feature implemented by email clients and the senders 
desire to receive one is conveyed by a header in the message.  The SMTP 
server is oblivious to this.


SMTP is Delivery Status Notification
eMail client is Message Disposition Notification

It would have to be a highly unusual situation before most informed 
users would ever allow a receipt to be returned.


I have on occasion responded to / allowed an MDN request.  But as a 
general rule I have my email client prompt me and I almost always deny 
the request.  About the only time I'll allow it is if it's from someone 
I know on a topic that I am willing to voluntarily share that information.


The only way at present to know for certain that email was actually 
sent, delivered, and read requires co-operation by the recipient to 
send a return email reply that has content that clearly demonstrates it 
is not just an automated response to the  received email.  Other than 
that, there is always room for some uncertainty that a failure could 
have occurred that prevented receipt.


There's a reason that Message Disposition Notifications use the term 
"disposition".  Meaning that the message was displayed or printed. 
There is no way that a computer can guarantee that the message was 
actually read.  At least not currently.




--
Grant. . . .
unix || die

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sending email from the Mainframe

[Grant Taylor]

On 8/28/20 7:36 AM, Paul Gilmartin wrote:

The inability to handle Delivery Status Notifications is a glaring
deficiency of CSSMTP, worthy of an RFE to repair this regression.


DSNs / MDNs / other non-standard bounces don't need to come back into 
CSSMTP.  The just need to come back into an SMTP server.  It can be any 
SMTP server, including the main corporate SMTP server.


It is entirely possible to send messages from CSSMTP and have the 
bounces go back to a different server, and then collect bounces or 
otherwise process them there.



Might this be partly mitigated by supplying an "Errors-to:" header?


Unnecessary.


Was security a motivator for ending support of incoming mail,
possibly because DSNs often reproduce the entire, possibly
sensitive, email bodies?


You can influence what is returned by using the optional "RET=HDRS" 
parameter to the MAIL FROM statement.  Standards compliant servers 
should only return the headers and not the message body.




--
Grant. . . .
unix || die

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sending email from the Mainframe

[Grant Taylor]

On 8/28/20 5:57 AM, Sasso, Len wrote:
Does anyone have JCL that sends an email, using CSSMTP, from the 
Mainframe and if it is unable to be delivered, for any reason, sends 
an email back to the Sender with a corresponding message?


I'm guessing that since CSSMTP is involved, the JCL / job is not 
speaking SMTP to a receiving server.


I'm not aware of any way that a job can know if there was a hard error 
(early rejection) if it's not doing the SMTP itself.  Maybe there is a 
way to ask CSSMTP to try to send the message and return an error to the 
calling job.


But both of these would only reliably detect a hard error (4xy, 5xy) 
from the receiving SMTP server and wouldn't work for anything downstream 
of that.


For anything downstream of that, you will need to rely on (hopefully) 
industry standard / RFC defined DSNs, or worse, home grown bounces.


(More about this in a reply to Paul's comment.)



--
Grant. . . .
unix || die

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sending email from the Mainframe

[Paul Gilmartin]

On Fri, 28 Aug 2020 08:39:33 -0500, Joel C. Ewing wrote:
>
>  It would have to be a highly unusual
>situation before most informed users would ever allow a receipt to be
>returned.
>
... very dangerous - there's tremendous fraud involved.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sending email from the Mainframe

[Joel C. Ewing]

You seem to be asking for an impossibility here because the email
protocol as currently implemented doesn't support this.    There is no
way for a sender of email to distinguish between email that is accepted
by its target domain but classed (correctly or incorrectly) as  spam and
thrown into the bit bucket to protect end users and make spammers waste
their transmission resources, and email that is accepted and actually
stored for retrieval by the recipient.  Some servers won't even tell a
sender if the target email account doesn't exist, because that info is
also useful to spammers.   So, "successful" transmission to the target
domain can occur even when there will be no actual delivery to any end
user, and email rejection by the receiving domain is only a subset of
the potential failures.

Even successful receipt and successful storage of an email by the target
domain doesn't mean that the intended recipient will ever login to the
account, retrieve it and actually read it.   In fact, the user's local
email client may even have additional filters that trash some received
email based on his own criteria.  Acceptance by the domain's mail server
doesn't mean the email will ever be "delivered" to the actual end user.

The email protocol does still allow for requesting a return email
receipt when the email is actually opened, but that was one of the first
features grossly abused by spammers wanting to locate actively-used
email accounts; so all reasonable email clients default to suppression
of automatic "receipt" responses.  It would have to be a highly unusual
situation before most informed users would ever allow a receipt to be
returned.

Being able to accurately verify successful delivery of email to an
actual email account would be a tremendous boon to spammers and other
undesirable users of emai, so I wouldn't expect to see this situation
change until much better ways of dealing with that problem exist.

The only way at present to know for certain that email was actually
sent, delivered, and read requires co-operation by the recipient to send
a return email reply that has content that clearly demonstrates it is
not just an automated response to the  received email.  Other than that,
there is always room for some uncertainty that a failure could have
occurred that prevented receipt.
    Joel C Ewing

On 8/28/20 6:57 AM, Sasso, Len wrote:
> Does anyone have JCL that sends an email, using CSSMTP, from the Mainframe 
> and if it is unable to be delivered, for any reason, sends an email back to 
> the Sender with a corresponding message?
>
>
> Thank You and Please Be Safe!
>
> Len Sasso
> Systems Administrator Senior
> CSRA, A General Dynamics Information Technology Company
> 327 Columbia TPKE
> Rensselaer, NY 12144
>
> Office Hours: M-F  7 AM - 3:45 PM
> Out-Of-Office: Friday, August 28, 2020  Noon - 3:45 PM
> Phone: (518) 257-4209
> Cell: (518) 894-0879
> Fax: (518) 257-4300
> len.sa...@gdit.com
> URL: www.gdit.com
>
>
>
>
...

-- 
Joel C. Ewing

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sending email from the Mainframe

[Paul Gilmartin]

On Fri, 28 Aug 2020 13:01:54 +, Seymour J Metz wrote:

>Once CSSMTP has submitted your e-mail, it has no involvement. You should get a 
>DSN if there is a problem, but, unlike SMTP, CSSMTP does not handle incoming 
>mail.

The inability to handle Delivery Status Notifications is a glaring
deficiency of CSSMTP, worthy of an RFE to repair this regression.

Might this be partly mitigated by supplying an "Errors-to:" header?

Was security a motivator for ending support of incoming mail,
possibly because DSNs often reproduce the entire, possibly
sensitive, email bodies?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sending email from the Mainframe

[Carmen Vitullo]

There are products that can do this, JES2MAIL is one we use, z/osmf can be used 
but I have configured z/osmf to use the lan (MS) smtp server and use jes2eds 
notification
//NFY NOTIFY EMAIL='u...@domain.com' after the jobcard. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sending email from the Mainframe

[Seymour J Metz]

Once CSSMTP has submitted your e-mail, it has no involvement. You should get a 
DSN if there is a problem, but, unlike SMTP, CSSMTP does not handle incoming 
mail.

There is a mechanism for requesting acknowledgement of successful delivery, but 
it is optional and often abused; many sites do not support it.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Sasso, Len 
Sent: Friday, August 28, 2020 7:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Sending email from the Mainframe

Does anyone have JCL that sends an email, using CSSMTP, from the Mainframe and 
if it is unable to be delivered, for any reason, sends an email back to the 
Sender with a corresponding message?


Thank You and Please Be Safe!

Len Sasso
Systems Administrator Senior
CSRA, A General Dynamics Information Technology Company
327 Columbia TPKE
Rensselaer, NY 12144

Office Hours: M-F  7 AM - 3:45 PM
Out-Of-Office: Friday, August 28, 2020  Noon - 3:45 PM
Phone: (518) 257-4209
Cell: (518) 894-0879
Fax: (518) 257-4300
len.sa...@gdit.com
URL: www.gdit.com<http://www.gdit.com>





From: IBM Mainframe Discussion List  on behalf of 
Timothy Sipples 
Sent: Friday, July 24, 2020 5:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Sending email from the Mainframe



 [External: Use caution with links & attachments]

Grant Taylor asks:
>What happens to email if CSSMTP (AT-TLS) is configured
>to *require* encryption and the receiving system doesn't
>support encryption?

Fundamentally the same thing(s) that happen when the network connection is
down or too slow (times out), for whatever reasons. Network encryption is
part and parcel of the network path. This class of failures must already
be catered for. In this case, Len Sasso's organization is mandating TLS
1.2+, and I agree with Shmuel Metz who wrote:
>If management has decreed that all SMTP traffic be encrypted,
>then barring a configuration error the relay will accept
>encrypted traffic.

Moreover, it's entirely possible that your attitude would only increase
relay administrators' burdens, the people who currently have to manage,
support, monitor, and audit the e-mail traffic from the one and only
system still transmitting over an unencrypted connection, a connection
modality they'd very much like to retire as quickly as possible. You know,
that "old, obsolete mainframe" that you're actively arguing should
actually be as old and obsolete as you can possibly force it to be. (TLS
is *really* not new.) Or it's entirely possible that the relay
administrators aren't inclined or equipped to provide even mediocre
service levels for unencrypted connections, or even that there's a lone
dedicated relay gathering dust in a wiring closet somewhere to support
this one unencrypted connection, a relay that nobody left in the
organization even understands or really knows about, that isn't backed up
or DR protected, that still runs on a 10 Mbps Ethernet segment that
miraculously hasn't been disconnected yet. Hence the unencrypted
connection is MORE prone to failure, not less. All very possible, even
predictable and likely. And I haven't even gotten to the regulatory issues
and penalties.

Conceivably you could also reduce or eliminate your personal security
authentication failure planning and handling (hopefully automated)
responsibilities if you effectively disable your SAF security provider,
such as RACF. Then those few pesky authentication and authorization
rejections wouldn't occur, and everyone could just go to the pub and stay
there (or whatever). That's the logical consequence of your argument,
isn't it? I don't think you've got a strong argument.

Sorry to be blunt here, but I feel compelled to offer my personal view (as
always). My colleagues (and I mean that word expansively, in and out of
IBM) work really hard to deliver and support truly cutting edge
capabilities, including downright amazing security capabilities, in/for
this unique and indispensable platform. And this community, overall, often
works really hard to put these capabilities into practice, in many cases
literally to keep civilization functioning. Then there are a few people
who manage a few of these systems, and...well, let's all strive to do
better, OK?

[Why am I expecting a minor Twitter storm now? :-)]

- - - - - - - - - -
Timothy Sipples
I.T. Architect Executive
Digital Asset & Other Industry Solutions
IBM Z & LinuxONE
- - - - - - - - - -
E-Mail: sipp...@sg.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@l

Re: Sending email from the Mainframe

[Sasso, Len]

Does anyone have JCL that sends an email, using CSSMTP, from the Mainframe and 
if it is unable to be delivered, for any reason, sends an email back to the 
Sender with a corresponding message?


Thank You and Please Be Safe!

Len Sasso
Systems Administrator Senior
CSRA, A General Dynamics Information Technology Company
327 Columbia TPKE
Rensselaer, NY 12144

Office Hours: M-F  7 AM - 3:45 PM
Out-Of-Office: Friday, August 28, 2020  Noon - 3:45 PM
Phone: (518) 257-4209
Cell: (518) 894-0879
Fax: (518) 257-4300
len.sa...@gdit.com
URL: www.gdit.com<http://www.gdit.com>





From: IBM Mainframe Discussion List  on behalf of 
Timothy Sipples 
Sent: Friday, July 24, 2020 5:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Sending email from the Mainframe



 [External: Use caution with links & attachments]

Grant Taylor asks:
>What happens to email if CSSMTP (AT-TLS) is configured
>to *require* encryption and the receiving system doesn't
>support encryption?

Fundamentally the same thing(s) that happen when the network connection is
down or too slow (times out), for whatever reasons. Network encryption is
part and parcel of the network path. This class of failures must already
be catered for. In this case, Len Sasso's organization is mandating TLS
1.2+, and I agree with Shmuel Metz who wrote:
>If management has decreed that all SMTP traffic be encrypted,
>then barring a configuration error the relay will accept
>encrypted traffic.

Moreover, it's entirely possible that your attitude would only increase
relay administrators' burdens, the people who currently have to manage,
support, monitor, and audit the e-mail traffic from the one and only
system still transmitting over an unencrypted connection, a connection
modality they'd very much like to retire as quickly as possible. You know,
that "old, obsolete mainframe" that you're actively arguing should
actually be as old and obsolete as you can possibly force it to be. (TLS
is *really* not new.) Or it's entirely possible that the relay
administrators aren't inclined or equipped to provide even mediocre
service levels for unencrypted connections, or even that there's a lone
dedicated relay gathering dust in a wiring closet somewhere to support
this one unencrypted connection, a relay that nobody left in the
organization even understands or really knows about, that isn't backed up
or DR protected, that still runs on a 10 Mbps Ethernet segment that
miraculously hasn't been disconnected yet. Hence the unencrypted
connection is MORE prone to failure, not less. All very possible, even
predictable and likely. And I haven't even gotten to the regulatory issues
and penalties.

Conceivably you could also reduce or eliminate your personal security
authentication failure planning and handling (hopefully automated)
responsibilities if you effectively disable your SAF security provider,
such as RACF. Then those few pesky authentication and authorization
rejections wouldn't occur, and everyone could just go to the pub and stay
there (or whatever). That's the logical consequence of your argument,
isn't it? I don't think you've got a strong argument.

Sorry to be blunt here, but I feel compelled to offer my personal view (as
always). My colleagues (and I mean that word expansively, in and out of
IBM) work really hard to deliver and support truly cutting edge
capabilities, including downright amazing security capabilities, in/for
this unique and indispensable platform. And this community, overall, often
works really hard to put these capabilities into practice, in many cases
literally to keep civilization functioning. Then there are a few people
who manage a few of these systems, and...well, let's all strive to do
better, OK?

[Why am I expecting a minor Twitter storm now? :-)]

- - - - - - - - - -
Timothy Sipples
I.T. Architect Executive
Digital Asset & Other Industry Solutions
IBM Z & LinuxONE
- - - - - - - - - -
E-Mail: sipp...@sg.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sending email from the Mainframe

[Timothy Sipples]

Grant Taylor asks:
>What happens to email if CSSMTP (AT-TLS) is configured
>to *require* encryption and the receiving system doesn't
>support encryption?

Fundamentally the same thing(s) that happen when the network connection is 
down or too slow (times out), for whatever reasons. Network encryption is 
part and parcel of the network path. This class of failures must already 
be catered for. In this case, Len Sasso's organization is mandating TLS 
1.2+, and I agree with Shmuel Metz who wrote:
>If management has decreed that all SMTP traffic be encrypted,
>then barring a configuration error the relay will accept
>encrypted traffic.

Moreover, it's entirely possible that your attitude would only increase 
relay administrators' burdens, the people who currently have to manage, 
support, monitor, and audit the e-mail traffic from the one and only 
system still transmitting over an unencrypted connection, a connection 
modality they'd very much like to retire as quickly as possible. You know, 
that "old, obsolete mainframe" that you're actively arguing should 
actually be as old and obsolete as you can possibly force it to be. (TLS 
is *really* not new.) Or it's entirely possible that the relay 
administrators aren't inclined or equipped to provide even mediocre 
service levels for unencrypted connections, or even that there's a lone 
dedicated relay gathering dust in a wiring closet somewhere to support 
this one unencrypted connection, a relay that nobody left in the 
organization even understands or really knows about, that isn't backed up 
or DR protected, that still runs on a 10 Mbps Ethernet segment that 
miraculously hasn't been disconnected yet. Hence the unencrypted 
connection is MORE prone to failure, not less. All very possible, even 
predictable and likely. And I haven't even gotten to the regulatory issues 
and penalties.

Conceivably you could also reduce or eliminate your personal security 
authentication failure planning and handling (hopefully automated) 
responsibilities if you effectively disable your SAF security provider, 
such as RACF. Then those few pesky authentication and authorization 
rejections wouldn't occur, and everyone could just go to the pub and stay 
there (or whatever). That's the logical consequence of your argument, 
isn't it? I don't think you've got a strong argument.

Sorry to be blunt here, but I feel compelled to offer my personal view (as 
always). My colleagues (and I mean that word expansively, in and out of 
IBM) work really hard to deliver and support truly cutting edge 
capabilities, including downright amazing security capabilities, in/for 
this unique and indispensable platform. And this community, overall, often 
works really hard to put these capabilities into practice, in many cases 
literally to keep civilization functioning. Then there are a few people 
who manage a few of these systems, and...well, let's all strive to do 
better, OK?

[Why am I expecting a minor Twitter storm now? :-)]

- - - - - - - - - -
Timothy Sipples
I.T. Architect Executive
Digital Asset & Other Industry Solutions
IBM Z & LinuxONE
- - - - - - - - - -
E-Mail: sipp...@sg.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sending email from the Mainframe

[Seymour J Metz]

> Given the prior comments about wanting to not smart host / off-load to a
> different local SMTP server, yes, I'm assuming direct-to-MX with my
> comments / questions.

That's a bad idea for several reasons.

> Sorry, that's somewhat nebulous.  Are you asking about the z/OS SYSPROGs
> or the company management that said SYSPROGs report to?

I'm talking whoever has authority over both the z/OS system and the network 
infrastructure, including firewalls, mail servers, routers and connection to an 
ISP or backbone.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Grant Taylor [023065957af1-dmarc-requ...@listserv.ua.edu]
Sent: Thursday, July 23, 2020 4:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Sending email from the Mainframe

On 7/23/20 2:27 PM, Seymour J Metz wrote:
> Are you assuming direct-to-MX?

Given the prior comments about wanting to not smart host / off-load to a
different local SMTP server, yes, I'm assuming direct-to-MX with my
comments / questions.

> Are you assuming using a mail server not under the control of the z/OS
> system's management.

Sorry, that's somewhat nebulous.  Are you asking about the z/OS SYSPROGs
or the company management that said SYSPROGs report to?

> If not, then I've already addressed the issue.

I agree that having z/OS smart-host to a different SMTP server that does
the to-MX sending would address my comments / questions.  I assume that
said smart-host is under the same company management hierarchy (or
subcontracted there from), even if it's not actually the z/OS SYSPROGs.

I believe that enforcing TLS with CSSMTP being used as direct-to-MX is
going to be problematic.  At least for a general outbound email.
Business-to-business might be considerably less problematic.



--
Grant. . . .
unix || die

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sending email from the Mainframe

[Grant Taylor]

On 7/23/20 2:27 PM, Seymour J Metz wrote:

Are you assuming direct-to-MX?


Given the prior comments about wanting to not smart host / off-load to a 
different local SMTP server, yes, I'm assuming direct-to-MX with my 
comments / questions.


Are you assuming using a mail server not under the control of the z/OS 
system's management.


Sorry, that's somewhat nebulous.  Are you asking about the z/OS SYSPROGs 
or the company management that said SYSPROGs report to?



If not, then I've already addressed the issue.


I agree that having z/OS smart-host to a different SMTP server that does 
the to-MX sending would address my comments / questions.  I assume that 
said smart-host is under the same company management hierarchy (or 
subcontracted there from), even if it's not actually the z/OS SYSPROGs.


I believe that enforcing TLS with CSSMTP being used as direct-to-MX is 
going to be problematic.  At least for a general outbound email. 
Business-to-business might be considerably less problematic.




--
Grant. . . .
unix || die

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sending email from the Mainframe

[Seymour J Metz]

> What happens to email if CSSMTP (AT-TLS) is configured to *require*
> encryption and the receiving system doesn't support encryption?

Are you assuming direct-to-MX? Are you assuming using a mail server not under 
the control of the z/OS system's management. If not, then I've already 
addressed the issue.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Grant Taylor [023065957af1-dmarc-requ...@listserv.ua.edu]
Sent: Thursday, July 23, 2020 11:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Sending email from the Mainframe

On 7/23/20 1:24 AM, Seymour J Metz wrote:
> But what, someone may ask, if the realy connects to a box that doesn't
> support TLS 1.2? The same thing as if the traffic from CSSMTP were
> unencrypted, and not the concern of the z/OS staff unless the relay
> is also running on z/OS.

What happens to email if CSSMTP (AT-TLS) is configured to *require*
encryption and the receiving system doesn't support encryption?

I presume that CSSMTP will fail to send the email b/c of the lack of
encryption.

What happens to these unsent emails?

Does an error get sent back to the sending application?

Do the unsent messages pile up in a spool somewhere?

Even at ~90% support for encryption, that's one in ten emails that can't
be sent via encrypted channels.  What happens to that 10% that can't be
sent with encryption?  Also, I don't believe the ~90% figure.  I believe
it to be somewhere between 60% and 70% and that there is a geographic
influence to the number.

I agree that requiring encryption is perfectly reasonable.  I think that
requiring TLS 1.2 is a laudable goal.

But I also think it would be negligent to fail to have a plan for email
that can't be sent via encrypted channels.

What happens to the email that CSSMTP (AT-TLS) wants to send if the
receiving system has an expired certificate and thus fails validation?
This is a fairly common short lived oops.

Also, I was not questioning the merit of TLS.  I was simply inquiring if
the requirement was for encryption, which can be accomplished multiple
ways, or if it was for TLS specifically.



--
Grant. . . .
unix || die

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sending email from the Mainframe

[Seymour J Metz]

There's a difference between questioning the accuracy of the stated reqirement 
and suggesting that he not comply with it. Why not simply ask the OP for the 
exact requirement imposed by management?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Grant Taylor [023065957af1-dmarc-requ...@listserv.ua.edu]
Sent: Thursday, July 23, 2020 12:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Sending email from the Mainframe

On 7/23/20 12:17 AM, Timothy Sipples wrote:
> I don't know why you're questioning Len's expressed*requirement*.

Experience.  Specifically experience that has included being down stream
of multiple telephone games.  Person A tells person B that they require
/encryption/.  Then person B tells person C that /TLS/ is required.  —
Person B innocently substituted "TLS" in place of "encryption" thinking
that it was the only way to meet the requirement.  —  So person C's
working understanding is that /TLS/ specifically is required when that
is not the case.  Person A might be perfectly satisfied with an IPsec VPN.

So experience has taught me to /politely/ inquire if the strict
requirement is for /TLS/ -or- /encryption/.

It may seem like a subtle difference.  But the difference has technical
ramifications.



--
Grant. . . .
unix || die

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sending email from the Mainframe

[Grant Taylor]

On 7/23/20 12:17 AM, Timothy Sipples wrote:

I don't know why you're questioning Len's expressed*requirement*.


Experience.  Specifically experience that has included being down stream 
of multiple telephone games.  Person A tells person B that they require 
/encryption/.  Then person B tells person C that /TLS/ is required.  — 
Person B innocently substituted "TLS" in place of "encryption" thinking 
that it was the only way to meet the requirement.  —  So person C's 
working understanding is that /TLS/ specifically is required when that 
is not the case.  Person A might be perfectly satisfied with an IPsec VPN.


So experience has taught me to /politely/ inquire if the strict 
requirement is for /TLS/ -or- /encryption/.


It may seem like a subtle difference.  But the difference has technical 
ramifications.




--
Grant. . . .
unix || die

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sending email from the Mainframe

[Grant Taylor]

On 7/23/20 1:24 AM, Seymour J Metz wrote:
But what, someone may ask, if the realy connects to a box that doesn't 
support TLS 1.2? The same thing as if the traffic from CSSMTP were 
unencrypted, and not the concern of the z/OS staff unless the relay 
is also running on z/OS.


What happens to email if CSSMTP (AT-TLS) is configured to *require* 
encryption and the receiving system doesn't support encryption?


I presume that CSSMTP will fail to send the email b/c of the lack of 
encryption.


What happens to these unsent emails?

Does an error get sent back to the sending application?

Do the unsent messages pile up in a spool somewhere?

Even at ~90% support for encryption, that's one in ten emails that can't 
be sent via encrypted channels.  What happens to that 10% that can't be 
sent with encryption?  Also, I don't believe the ~90% figure.  I believe 
it to be somewhere between 60% and 70% and that there is a geographic 
influence to the number.


I agree that requiring encryption is perfectly reasonable.  I think that 
requiring TLS 1.2 is a laudable goal.


But I also think it would be negligent to fail to have a plan for email 
that can't be sent via encrypted channels.


What happens to the email that CSSMTP (AT-TLS) wants to send if the 
receiving system has an expired certificate and thus fails validation? 
This is a fairly common short lived oops.


Also, I was not questioning the merit of TLS.  I was simply inquiring if 
the requirement was for encryption, which can be accomplished multiple 
ways, or if it was for TLS specifically.




--
Grant. . . .
unix || die

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sending email from the Mainframe

[Sasso, Len]

Tim:

Thank you, I thought it was a reasonable requirement.


Please Be Safe!

Thank You!

Len Sasso
Systems Administrator Senior
CSRA, A General Dynamics Information Technology Company
327 Columbia TPKE
Rensselaer, NY 12144

Office Hours: M-F  7 AM - 3:45 PM
Out-Of-Office:
Phone: (518) 257-4209
Cell: (518) 894-0879
Fax: (518) 257-4300
len.sa...@gdit.com
URL: www.gdit.com<http://www.gdit.com>





From: IBM Mainframe Discussion List  on behalf of 
Timothy Sipples 
Sent: Thursday, July 23, 2020 2:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Sending email from the Mainframe



 [External: Use caution with links & attachments]

Grant Taylor wrote:
>That means that z/OS's CSSMTP will be near or on par with other SMTP
>servers and related problems securing SMTP traffic.  Most of which have
>to do with the capabilities of the receiving SMTP server, which is
>outside of CSSMTP's control.

First of all, here's what Len Sasso wrote:
>All our messages must implement TLS 1.2 or higher for
>transport level encryption.

I don't know why you're questioning Len's expressed *requirement*. And
(don't worry, Len!) it's a very, very reasonable requirement in the year
2020 and beyond. For that matter it was a reasonable requirement 20+ years
ago, too.

Then there's this fact, which Lionel Dyck kindly pointed out:
>CSSMTP is a send only SMTP service - it does not receive anything.

Exactly. This is about getting TLS 1.2+ encryption enabled from z/OS at
least as far as the next hop. CSSMTP alone doesn't provide a return
mailbox.

According to Google's latest Transparency Report, available here:

https://urldefense.com/v3/__https://transparencyreport.google.com/safer-email/overview?hl=en__;!!JRQnnSFuzw7wjAKq6ti6!jQEpQBYYYTpvQzuolvNNqmVerCNjKRCLDoprizRvzc2Qp-ZFVX3swid6aX90zw$

93% of outgoing e-mail from Google and 94% of incoming e-mail to Google
rode over TLS between April 24, 2020, and July 23, 2020. Google's e-mail
services are heavily consumer-oriented ("How is piano practice going?"),
and well over 90% of it is encrypted in flight. Len Sasso is dealing with
an enterprise system, presumably. Maybe my cousin's medical insurance
claim acknowledgment is being e-mailed, or maybe your loan application
update is being e-mailed out to you. Does anyone seriously want to
question Len's requirement? Or would it be at least as appropriate to
question why you haven't enabled encryption for your SMTP and other
network traffic, if you haven't?

It's very frustrating to me when even basic security precautions and
practices are questioned like this. Get it turned on, please! It's quick,
easy, and no additional charge. And have a look at the z/OS Encryption
Readiness Tool ("zERT"), included with z/OS at no additional charge, to
get visibility on where you still have gaps.

>If you configure z/OS's CSSMTP to /require/ encryption, TLS 1.2 or
>otherwise, and the receiving SMTP system doesn't offer it, the email
>will be stuck on z/OS.

That's an available configuration choice, that's correct, and that's
exactly what *should* happen in myriad real world scenarios to avoid a
potential or actual security breach.

>Do you really want to have someone perform regular postmaster duties on
>z/OS?

As Lionel patiently explained, this is about whether Len Sasso's
requirement is satisfied, to encrypt e-mail traffic to the next hop. There
are no postperson duties here, not with CSSMTP. These are basic network
security duties, prudently practiced and respected for decades now.

But (hypothetically, off on your tangent) why not? It's an IMAP
mailbox the postperson(s) monitor, presumably. The postperson probably
isn't either configuring and administering a Kubernetes cluster or
navigating ISPF screens. If the mailbox were hosted on z/OS (yes, it can
be, with other software), what's the problem?

I'm a little confused here. Isn't this IBM-MAIN? Is there something you
wouldn't or don't like about providing more and more useful user services
from z/OS?

>It might be better to send the email to another exissting corporate
>SMTP server where someone is already handling the postmaster duties.

Yes, there's something else besides CSSMTP. OK, backing off that
tangent

>Simply enabling TLS on z/OS's CSSMTP is probably not sufficient to
>guarantee that the email transmission path to the next SMTP server will
>be encrypted.

It is if you configure AT-TLS to require it, which is par for the course
really.

>Both the sending end (CSSMTP) and the receiving end (remote SMTP server)
>need to support encryption.

Yes, and as you can see from Google's Transparency Report TLS isn't a rare
or exotic thing. (What year is this?)

>Most MTAs can be an encrypted client without their own TLS certificate.
>—  Though a /client/ TLS certificate can be entertaining to use in place
>of username and password for authenticating the sending system to a

Re: Sending email from the Mainframe

[Seymour J Metz]

Indeed.

CSSMTP is an SMTP client. It needs to connect to an SMTP server, and in most if 
not all installations there is an SMTP server dedicated to the purpose, which 
serves as a relay to the outside world. If management has decreed that all SMTP 
traffic be encrypted, then barring a configuration error the relay will accept 
encrypted traffic. If the relay doesn't support TLS 1.2 then create a trouble 
ticket.

Even if the data don't have privacy issues, I don't see how encryption for 
CSSMTP imposes an administrative burden beyond what the installation would need 
without the SMTP traffic. 

But what, someone may ask, if the realy connects to a box that doesn't support 
TLS 1.2? The same thing as if the traffic from CSSMTP were unencrypted, and not 
the concern of the z/OS staff unless the relay is also running on z/OS.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Timothy Sipples [sipp...@sg.ibm.com]
Sent: Thursday, July 23, 2020 2:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Sending email from the Mainframe

Grant Taylor wrote:
>That means that z/OS's CSSMTP will be near or on par with other SMTP
>servers and related problems securing SMTP traffic.  Most of which have
>to do with the capabilities of the receiving SMTP server, which is
>outside of CSSMTP's control.

First of all, here's what Len Sasso wrote:
>All our messages must implement TLS 1.2 or higher for
>transport level encryption.

I don't know why you're questioning Len's expressed *requirement*. And
(don't worry, Len!) it's a very, very reasonable requirement in the year
2020 and beyond. For that matter it was a reasonable requirement 20+ years
ago, too.

Then there's this fact, which Lionel Dyck kindly pointed out:
>CSSMTP is a send only SMTP service - it does not receive anything.

Exactly. This is about getting TLS 1.2+ encryption enabled from z/OS at
least as far as the next hop. CSSMTP alone doesn't provide a return
mailbox.

According to Google's latest Transparency Report, available here:

https://transparencyreport.google.com/safer-email/overview?hl=en

93% of outgoing e-mail from Google and 94% of incoming e-mail to Google
rode over TLS between April 24, 2020, and July 23, 2020. Google's e-mail
services are heavily consumer-oriented ("How is piano practice going?"),
and well over 90% of it is encrypted in flight. Len Sasso is dealing with
an enterprise system, presumably. Maybe my cousin's medical insurance
claim acknowledgment is being e-mailed, or maybe your loan application
update is being e-mailed out to you. Does anyone seriously want to
question Len's requirement? Or would it be at least as appropriate to
question why you haven't enabled encryption for your SMTP and other
network traffic, if you haven't?

It's very frustrating to me when even basic security precautions and
practices are questioned like this. Get it turned on, please! It's quick,
easy, and no additional charge. And have a look at the z/OS Encryption
Readiness Tool ("zERT"), included with z/OS at no additional charge, to
get visibility on where you still have gaps.

>If you configure z/OS's CSSMTP to /require/ encryption, TLS 1.2 or
>otherwise, and the receiving SMTP system doesn't offer it, the email
>will be stuck on z/OS.

That's an available configuration choice, that's correct, and that's
exactly what *should* happen in myriad real world scenarios to avoid a
potential or actual security breach.

>Do you really want to have someone perform regular postmaster duties on
>z/OS?

As Lionel patiently explained, this is about whether Len Sasso's
requirement is satisfied, to encrypt e-mail traffic to the next hop. There
are no postperson duties here, not with CSSMTP. These are basic network
security duties, prudently practiced and respected for decades now.

But (hypothetically, off on your tangent) why not? It's an IMAP
mailbox the postperson(s) monitor, presumably. The postperson probably
isn't either configuring and administering a Kubernetes cluster or
navigating ISPF screens. If the mailbox were hosted on z/OS (yes, it can
be, with other software), what's the problem?

I'm a little confused here. Isn't this IBM-MAIN? Is there something you
wouldn't or don't like about providing more and more useful user services
from z/OS?

>It might be better to send the email to another exissting corporate
>SMTP server where someone is already handling the postmaster duties.

Yes, there's something else besides CSSMTP. OK, backing off that
tangent

>Simply enabling TLS on z/OS's CSSMTP is probably not sufficient to
>guarantee that the email transmission path to the next SMTP server will
>be encrypted.

It is if you configure AT-TLS to require it, which is par for the course
really.

>Both the sending end (CSSMTP) and the receiving end (remote SMTP s

Re: Sending email from the Mainframe

[Timothy Sipples]

Grant Taylor wrote:
>That means that z/OS's CSSMTP will be near or on par with other SMTP
>servers and related problems securing SMTP traffic.  Most of which have
>to do with the capabilities of the receiving SMTP server, which is
>outside of CSSMTP's control.

First of all, here's what Len Sasso wrote:
>All our messages must implement TLS 1.2 or higher for
>transport level encryption.

I don't know why you're questioning Len's expressed *requirement*. And 
(don't worry, Len!) it's a very, very reasonable requirement in the year 
2020 and beyond. For that matter it was a reasonable requirement 20+ years 
ago, too.

Then there's this fact, which Lionel Dyck kindly pointed out:
>CSSMTP is a send only SMTP service - it does not receive anything.

Exactly. This is about getting TLS 1.2+ encryption enabled from z/OS at 
least as far as the next hop. CSSMTP alone doesn't provide a return 
mailbox.

According to Google's latest Transparency Report, available here:

https://transparencyreport.google.com/safer-email/overview?hl=en

93% of outgoing e-mail from Google and 94% of incoming e-mail to Google 
rode over TLS between April 24, 2020, and July 23, 2020. Google's e-mail 
services are heavily consumer-oriented ("How is piano practice going?"), 
and well over 90% of it is encrypted in flight. Len Sasso is dealing with 
an enterprise system, presumably. Maybe my cousin's medical insurance 
claim acknowledgment is being e-mailed, or maybe your loan application 
update is being e-mailed out to you. Does anyone seriously want to 
question Len's requirement? Or would it be at least as appropriate to 
question why you haven't enabled encryption for your SMTP and other 
network traffic, if you haven't?

It's very frustrating to me when even basic security precautions and 
practices are questioned like this. Get it turned on, please! It's quick, 
easy, and no additional charge. And have a look at the z/OS Encryption 
Readiness Tool ("zERT"), included with z/OS at no additional charge, to 
get visibility on where you still have gaps.

>If you configure z/OS's CSSMTP to /require/ encryption, TLS 1.2 or
>otherwise, and the receiving SMTP system doesn't offer it, the email
>will be stuck on z/OS.

That's an available configuration choice, that's correct, and that's 
exactly what *should* happen in myriad real world scenarios to avoid a 
potential or actual security breach.

>Do you really want to have someone perform regular postmaster duties on
>z/OS?

As Lionel patiently explained, this is about whether Len Sasso's 
requirement is satisfied, to encrypt e-mail traffic to the next hop. There 
are no postperson duties here, not with CSSMTP. These are basic network 
security duties, prudently practiced and respected for decades now.

But (hypothetically, off on your tangent) why not? It's an IMAP 
mailbox the postperson(s) monitor, presumably. The postperson probably 
isn't either configuring and administering a Kubernetes cluster or 
navigating ISPF screens. If the mailbox were hosted on z/OS (yes, it can 
be, with other software), what's the problem?

I'm a little confused here. Isn't this IBM-MAIN? Is there something you 
wouldn't or don't like about providing more and more useful user services 
from z/OS?

>It might be better to send the email to another exissting corporate
>SMTP server where someone is already handling the postmaster duties.

Yes, there's something else besides CSSMTP. OK, backing off that 
tangent

>Simply enabling TLS on z/OS's CSSMTP is probably not sufficient to
>guarantee that the email transmission path to the next SMTP server will
>be encrypted.

It is if you configure AT-TLS to require it, which is par for the course 
really.

>Both the sending end (CSSMTP) and the receiving end (remote SMTP server)
>need to support encryption.

Yes, and as you can see from Google's Transparency Report TLS isn't a rare 
or exotic thing. (What year is this?)

>Most MTAs can be an encrypted client without their own TLS certificate.
>—  Though a /client/ TLS certificate can be entertaining to use in place
>of username and password for authenticating the sending system to a 
relay.
>}:-)

Not merely "entertaining." It's one perfectly reasonable, prudent security 
measure to make spoofing more difficult.

>If the task at hand is to secure email, there are many ways
>to comply with the spirit -or- have acceptable risk between the
>mainframe and an SMTP server over a secure LAN in a secure data center.

Words fail me here.

>If you really want to adhere to the spirit, the email body contents
>should be encrypted.  So that it doesn't matter nearly as much if the
>SMTP transmission path is encrypted or not.  But that's another kettle
>of fish.

I agree it would be great to encrypt the e-mail body *also*, if possible. 
Two popular ways are PGP and S/MIME.

- - - - - - - - - -
Timothy Sipples
I.T. Architect Executive
Digital Asset & Other Industry Solutions
IBM Z & LinuxONE
- - - - - - - - - -
E-Mail: 

Re: Sending email from the Mainframe

[Lionel B Dyck]

CSSMTP is a send only SMTP service - it does not receive anything.


Lionel B. Dyck <
Website: https://www.lbdsoftware.com

"Worry more about your character than your reputation.  Character is what you 
are, reputation merely what others think you are." - John Wooden

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Grant Taylor
Sent: Wednesday, July 22, 2020 10:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Sending email from the Mainframe

On 7/22/20 2:17 AM, Timothy Sipples wrote:
> CSSMTP. No problem. IBM explains how to set up TLS with CSSMTP here 
> (current z/OS 2.4 documentation link, subject to change):
> 
> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v
> 2r4.halz002/cssmtp_tls.htm

That means that z/OS's CSSMTP will be near or on par with other SMTP servers 
and related problems securing SMTP traffic.  Most of which have to do with the 
capabilities of the receiving SMTP server, which is outside of CSSMTP's control.

> It's possible to require TLS 1.2+, exactly as you wish. (Good idea.)

If you configure z/OS's CSSMTP to /require/ encryption, TLS 1.2 or otherwise, 
and the receiving SMTP system doesn't offer it, the email will be stuck on z/OS.

Do you really want to have someone perform regular postmaster duties on z/OS?  
It might be better to send the email to another exissting corporate SMTP server 
where someone is already handling the postmaster duties.  With or without 
encryption, be it STARTTLS, SMTPS (possibly via AT-TLS), IPsec transport mode, 
traditional VPN (IPsec tunnel mode or something else).  The big question is 
where do you want the email that doesn't send to reside and who's responsible 
for managing the queue.

> Tony Thigpen wrote:
> 
> That's possible, but it means that your e-mail traffic is leaving your 
> z/OS machine in cleartext.

Maybe, or maybe not.  There are other ways to encrypt email leaving CSSMTP 
without STARTTLS or SMTPS.

> This class of security risks is easily avoidable if you simply enable 
> TLS on z/OS.

Simply enabling TLS on z/OS's CSSMTP is probably not sufficient to guarantee 
that the email transmission path to the next SMTP server will be encrypted.

Both the sending end (CSSMTP) and the receiving end (remote SMTP server) need 
to support encryption.  Most MTAs can be an encrypted client without their own 
TLS certificate.  —  Though a /client/ TLS certificate can be entertaining to 
use in place of username and password for authenticating the sending system to 
a relay.  }:-)

> (N.B. TLS is not "heavy lifting," or at least it hasn't been for a 
> very, very long time.) There may also be some unnecessary server 
> complexity in what you've done, adding some inherent fragility.

Perhaps.  Though I think there is some benefit to getting email queue 
management into the hands of people who's day job is administering email vs 
people who's day job is administering the mainframe, which quite likely is 
considerably more than just email.  ;-)

> To be clear (pun intended), there are still one or more e-mail servers 
> in the transmission path, of course.

It's possible, but difficult to get the SMTP server count down to one, the 
receiving system.  But this requires the sending application to be initiating 
outbound SMTP.  Much more common is to have two SMTP servers, the one the 
application uses to send and the one that receives it on the other end.  
Depending on how things are done, this second path could be 0, 1, or 2 SMTP 
transactions, each with or without encryption which may be inside or outside of 
SMTP.

> This is about encrypting the traffic, preferably with TLS certificate 
> authentication, as early as possible in the path.

That statement sounds like it's trying to put a check mark in a checkbox.  If 
the task at hand is to secure email, there are many ways to comply with the 
spirit -or- have acceptable risk between the mainframe and an SMTP server over 
a secure LAN in a secure data center.

If you really want to adhere to the spirit, the email body contents should be 
encrypted.  So that it doesn't matter nearly as much if the SMTP transmission 
path is encrypted or not.  But that's another kettle of fish.



--
Grant. . . .
unix || die

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sending email from the Mainframe

[Grant Taylor]

On 7/22/20 2:17 AM, Timothy Sipples wrote:
CSSMTP. No problem. IBM explains how to set up TLS with CSSMTP here 
(current z/OS 2.4 documentation link, subject to change):


https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.halz002/cssmtp_tls.htm


That means that z/OS's CSSMTP will be near or on par with other SMTP 
servers and related problems securing SMTP traffic.  Most of which have 
to do with the capabilities of the receiving SMTP server, which is 
outside of CSSMTP's control.



It's possible to require TLS 1.2+, exactly as you wish. (Good idea.)


If you configure z/OS's CSSMTP to /require/ encryption, TLS 1.2 or 
otherwise, and the receiving SMTP system doesn't offer it, the email 
will be stuck on z/OS.


Do you really want to have someone perform regular postmaster duties on 
z/OS?  It might be better to send the email to another exissting 
corporate SMTP server where someone is already handling the postmaster 
duties.  With or without encryption, be it STARTTLS, SMTPS (possibly via 
AT-TLS), IPsec transport mode, traditional VPN (IPsec tunnel mode or 
something else).  The big question is where do you want the email that 
doesn't send to reside and who's responsible for managing the queue.



Tony Thigpen wrote:

That's possible, but it means that your e-mail traffic is leaving 
your z/OS machine in cleartext.


Maybe, or maybe not.  There are other ways to encrypt email leaving 
CSSMTP without STARTTLS or SMTPS.


This class of security risks is easily avoidable if you simply enable 
TLS on z/OS.


Simply enabling TLS on z/OS's CSSMTP is probably not sufficient to 
guarantee that the email transmission path to the next SMTP server will 
be encrypted.


Both the sending end (CSSMTP) and the receiving end (remote SMTP server) 
need to support encryption.  Most MTAs can be an encrypted client 
without their own TLS certificate.  —  Though a /client/ TLS certificate 
can be entertaining to use in place of username and password for 
authenticating the sending system to a relay.  }:-)


(N.B. TLS is not "heavy lifting," or at least it hasn't been for 
a very, very long time.) There may also be some unnecessary server 
complexity in what you've done, adding some inherent fragility.


Perhaps.  Though I think there is some benefit to getting email queue 
management into the hands of people who's day job is administering email 
vs people who's day job is administering the mainframe, which quite 
likely is considerably more than just email.  ;-)


To be clear (pun intended), there are still one or more e-mail servers 
in the transmission path, of course.


It's possible, but difficult to get the SMTP server count down to one, 
the receiving system.  But this requires the sending application to be 
initiating outbound SMTP.  Much more common is to have two SMTP servers, 
the one the application uses to send and the one that receives it on the 
other end.  Depending on how things are done, this second path could be 
0, 1, or 2 SMTP transactions, each with or without encryption which may 
be inside or outside of SMTP.


This is about encrypting the traffic, preferably with TLS certificate 
authentication, as early as possible in the path.


That statement sounds like it's trying to put a check mark in a 
checkbox.  If the task at hand is to secure email, there are many ways 
to comply with the spirit -or- have acceptable risk between the 
mainframe and an SMTP server over a secure LAN in a secure data center.


If you really want to adhere to the spirit, the email body contents 
should be encrypted.  So that it doesn't matter nearly as much if the 
SMTP transmission path is encrypted or not.  But that's another kettle 
of fish.




--
Grant. . . .
unix || die

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sending email from the Mainframe

[Timothy Sipples]

Len Sasso wrote:
>We are using CSSMTP to send email from the Mainframe.
>All our messages must implement TLS 1.2 or higher for
>transport level encryption.
>What you using?

CSSMTP. No problem. IBM explains how to set up TLS with CSSMTP here 
(current z/OS 2.4 documentation link, subject to change):

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.halz002/cssmtp_tls.htm

It's possible to require TLS 1.2+, exactly as you wish. (Good idea.)

Tony Thigpen wrote:
>We found it easier to set up a small SMTP relay box on an
>Intel platform and let it do all the TLS heavy lifting.

That's possible, but it means that your e-mail traffic is leaving your 
z/OS machine in cleartext. This class of security risks is easily 
avoidable if you simply enable TLS on z/OS. (N.B. TLS is not "heavy 
lifting," or at least it hasn't been for a very, very long time.) There 
may also be some unnecessary server complexity in what you've done, adding 
some inherent fragility.

To be clear (pun intended), there are still one or more e-mail servers in 
the transmission path, of course. This is about encrypting the traffic, 
preferably with TLS certificate authentication, as early as possible in 
the path.

Allan Staller wrote:
>We send everything plain text to the corporate email server
>and let them handle it!

I offer the same suggestion as above.

- - - - - - - - - -
Timothy Sipples
I.T. Architect Executive
Digital Asset & Other Industry Solutions
IBM Z & LinuxONE
- - - - - - - - - -
E-Mail: sipp...@sg.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sending email from the Mainframe

[Allan Staller]

We send everything plain text to the corporate email server and let them handle 
it!

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Tony Thigpen
Sent: Tuesday, July 21, 2020 11:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Sending email from the Mainframe

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don't click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

We found it easier to set up a small SMTP relay box on an Intel platform and 
let it do all the TLS heavy lifting.

Tony Thigpen

Sasso, Len wrote on 7/21/20 9:44 AM:
> We are using CSSMTP to send email from the Mainframe. All our messages must 
> implement TLS 1.2 or higher for transport level encryption.
>
> What you using?
>
>
>
> Please Be Safe!
>
> Thank You!
>
> Len Sasso
> Systems Administrator Senior
> CSRA, A General Dynamics Information Technology Company
> 327 Columbia TPKE
> Rensselaer, NY 12144
>
> Office Hours: M-F  7 AM - 3:45 PM
> Out-Of-Office:
> Phone: (518) 257-4209
> Cell: (518) 894-0879
> Fax: (518) 257-4300
> len.sa...@gdit.com
> URL:
> https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.g
> dit.com%2Fdata=02%7C01%7Callan.staller%40HCL.COM%7Cb70e49b4651c41
> b4779308d82d8f672e%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637309
> 441231612280sdata=DKdycmphfcXuCDtHDQnoeN%2Bb3J9bXuMedWB%2FiobS2jo
> %3Dreserved=0<https://apc01.safelinks.protection.outlook.com/?url
> =http%3A%2F%2Fwww.gdit.com%2Fdata=02%7C01%7Callan.staller%40HCL.C
> OM%7Cb70e49b4651c41b4779308d82d8f672e%7C189de737c93a4f5a8b686f4ca99419
> 12%7C0%7C0%7C637309441231612280sdata=DKdycmphfcXuCDtHDQnoeN%2Bb3J
> 9bXuMedWB%2FiobS2jo%3Dreserved=0>
>
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::

The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sending email from the Mainframe

[Tony Thigpen]

We found it easier to set up a small SMTP relay box on an Intel platform 
and let it do all the TLS heavy lifting.


Tony Thigpen

Sasso, Len wrote on 7/21/20 9:44 AM:

We are using CSSMTP to send email from the Mainframe. All our messages must 
implement TLS 1.2 or higher for transport level encryption.

What you using?



Please Be Safe!

Thank You!

Len Sasso
Systems Administrator Senior
CSRA, A General Dynamics Information Technology Company
327 Columbia TPKE
Rensselaer, NY 12144

Office Hours: M-F  7 AM - 3:45 PM
Out-Of-Office:
Phone: (518) 257-4209
Cell: (518) 894-0879
Fax: (518) 257-4300
len.sa...@gdit.com
URL: www.gdit.com




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Sending email from the Mainframe

[Sasso, Len]

We are using CSSMTP to send email from the Mainframe. All our messages must 
implement TLS 1.2 or higher for transport level encryption.

What you using?



Please Be Safe!

Thank You!

Len Sasso
Systems Administrator Senior
CSRA, A General Dynamics Information Technology Company
327 Columbia TPKE
Rensselaer, NY 12144

Office Hours: M-F  7 AM - 3:45 PM
Out-Of-Office:
Phone: (518) 257-4209
Cell: (518) 894-0879
Fax: (518) 257-4300
len.sa...@gdit.com
URL: www.gdit.com




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN