The SNDDST command and the SNADS infrastructure was modified by IBM to allow communication between SNADS and SMTP. However, it is not a SMTP facility. If you use it to send SMTP e-mail, you will have to adjust to the SNA attributes.
A far better choice would be the QtmmSendMail API or one of the free available utilities from the internet. (Programming a significant e-mail client isn’t trivial.)
If you insist upon using SNDDST, there are a couple options.
First, you can modify your e-mail attributes the your system directory entry. That works okay if your user ID is the only one involved; it’s much less feasible if you need this done for multiple users or if you want to keep your current e-mail attributes.
Otherwise, you can use system security APIs to help around your problem.
Create a user ID in the system directory to hold the e-mail attributes that you want. Associate that entry to an existing profile or create a user profile for it. Then you can write two fairly small programs — one to call just before SNDDST and the other for just after SNDDST. (SNDDST can be run as many times as needed between the CALLs.)
The first program would retrieve a profile handle for the job user profile and a profile handle for your ‘generic e-mail’ user profile. It would then set the profile handle with the Set Profile Handle (QWTSETP) API to change the job’s current user to your ‘generic’ user and return. Your SNDDST will then be executed as if the ‘generic’ profile actually was running the job. The second program then set the job profile handle back to the original, releases both handles and returns.
The reason you would write those as two separate *PGMs is so that you can compile them both with USRPRF(*OWNER) and have them be owned by a profile powerful enough to be switching profile handles without always needing to know passwords.
Overall, it seems easier just to use SMTP facilities from the start. But it can be done.