On Thu, 9 May 2019 15:08:28 -0500, Lionel B Dyck wrote: >The issue seems to be that the z/VM RSCS, or the SMTP server, was taking the >data and truncating it to 80 bytes. > >I had the site change the secure_smtp setting in the XMITIPCU configuration >file from null to 1. This has nothing to do with security but SMTP on z/OS >would only validate the sending userid if the email arrived in NETDATA format >(TSO Transmit). By changing the setting to 1 to tell XMITIP that the SMTP >security was in play (even if it isn't) then XMITIP sent the email in NETDATA >format which solved the problem I had forgotten about this setting as it was >put in back in 2001 for a site that requested it and never thought about using >for this purpose. > Silly rule. PITA, in fact; Shouldn't need to encode text/plain.
OK. You appear to be sending via NJE, not Internet. What if the sender were a non-IBM system (e.g. Linux) which knows only Internet? I've done this in the distant past, as the CMS recipient. But things may have changed: o Internet is ASCII-based. How can you be sure the same ASCII<=>EBCDIC code pages are used by both sender and recipient; crucial for binary files such as NETDATA and .zip. (But base64 inoculates against most hazards.) The XMITIP doc says precious little about which code pages are used/presumed. is that worth a RCF? Can the user control this, something like SBDATACONN? o "validate the sending userid" Is this new practice, (not in my ancient memory)? I certainly got mail from strangers. Does this rule apply only to NJE? -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
