SNDSMTPEMM with variable From address

[Alejandro M]

Hi all,
in our company, we started using SNDSMTPEMM command as it offered almost everything we need to send emails from i5. I'd never been able to figure out how to implement the relative API so we are very happy with this solution.
The problem is, you cannot specify "From" address, as IBM says such a feature could be dangerous and will not be implemented.
I thought I could implement the "From" parameter with a ghost SNDSMTPEMM command created by me: this new command should take all original command parameters (quite a lot) and in addition ask for a i5 user (or *CURRENT), then search on SMTP table for SMTP address, and submit a job that should run under i5 "From" user. This job should use the original SNDSMTPEMM, and will send the e-mail message with desired From user.
I'm having a hard time trying to figure how to pass the whole bunch of parameters from my "ghost" SNDSMTPEMM to the original SNDSMTPEMM command, without having to write down tenths of move instructions. The parameters structure of this command is huge and I can't see how to do this in an elegant and simpe way. Maybe anybody could suggest a solution?
Thank you in advance
Alejandro

[dunno]

Why do you need to change From header? To allow recipients to reply to
correct email address? If that's the case, then you might just set Reply-To
header accordingly.

--
dunno

[CRPence]

On 23-Sep-2015 02:10 -0600, Alejandro M wrote:
>
> In our company, we started using SNDSMTPEMM command as it offered

> to do this in an elegant and simple way. Maybe anybody could suggest
> a solution?

If the prior mention of establishing a Reply-To is not capable of
resolving the issue, then...

Consider intercepting the command invocation using the "Command Exit"
feature; modify the command string in a User Exit Program. As I recall,
Bruce Vining has written some articles about how to use that feature
implemented as an Exit Program (EXITPGM) for a registered exit [see Work
With Registration Information (WRKREGINF)].

Also, instead of Submit Job (SBMJOB) to start a new process, consider
using the effective /switch user/ feature [get profile handle and set
user APIs] to establish under which user the request is made.

--
Regards, Chuck

[Alejandro M]

Crpence,

thanks for your clues, I'm sure this is the way to go. I'm trying to figuring out the whole process. My main concern is about the dangers of changing current job's user, and being able to get back to the "real" user once the command is completed.

However this is the info I was looking for, thanks again.

[CRPence]

On 28-Sep-2015 02:36 -0600, Alejandro M wrote:

> On 23-Sep-2015 09:46 -0600, CRPence wrote:
>> On 23-Sep-2015 02:10 -0600, Alejandro M wrote:
>>>

>>> In our company, we started using SNDSMTPEMM command [...]
>>> cannot specify "From" address [...]
>>
>> [...]

>>
>> Consider intercepting the command invocation using the
>> "Command Exit" feature; modify the command string in a User Exit
>> Program. As I recall, Bruce Vining has written some articles about
>> how to use that feature implemented as an Exit Program (EXITPGM)
>> for a registered exit [see Work With Registration Information
>> (WRKREGINF)].
>>
>> Also, instead of Submit Job (SBMJOB) to start a new process,
>> consider using the effective /switch user/ feature [get profile
>> handle and set user APIs] to establish under which user the request
>> is made.
>>
>

If an effective server job is used, onto which the work is enqueued,
then the switch-user could occur in the server job instead of in the
requesting job. That would similarly avoid the Submit Job, while moving
the switch-user to a job that is not subject to issues such as with End
Request (ENDRQS); a cancel handler can ensure the switch back to the
original user in response to an otherwise unhandled\terminating error or
the end-request.

--
Regards, Chuck