Let us face it QDLS is something of the past, back from the days when the Integrated File System (IFS) had not seen the light of day. If you have not yet abandoned using QDLS now is a good time to do so. I will not go into details, but knowing that OfficeVision and QDLS are deeply connected, you will understand that it is time to move on. By moving on I mean using the IFS. QDLS seems like just another directory, right? All QDLS data is stored in libraries named QDOC*, for more details please have a look at this link.
Hang on, but what has this to do with the SMTP server settings? The *SDD value for the SMTP server in the screen below refers to the “System Distribution Directory”. For which the command ADDDIRE has to be used to add a user, in order to enable a user to send mail. The only problem I have with this is the limited logging when mail is not being delivered.
So please be aware of the fact that to enable logging of what is going on with the *SDD setting is to “Enable journal entries”. When using the command DSPJRN QZMF the journal entries of the SMTP server can be viewed. Over the years I have seen too many mail problems, so I have learned to watch for entries like the one below:
As an alternative you can use IBM i Access Client Solutions => Schemas => QUSRSYS => Journals => QZMF => View Entries… to get something similar to this:
When investigating SMTP I prefer to use the value “*SMTP” the e-mail directory type, instead of *SDD. If you use this value in combination with parameter KEEPUNTIL:
Keep until (KEEPUNTIL)
Specifies the length of time to retain e-mail tracking information. For backwards compatibility this will only be valid when the DIRTYPE parameter is set to *SMTP or *SMTPMSF.
The KEEPUNTIL previously set does not change; otherwise, *DFT is used.
The SMTP server will not retain any e-mail tracking information after the e-mail has been put into a final state.
Specify the maximum number of seconds to retain e-mail tracking information after the e-mail has been put into a final state.
Setting it to the maximum value will allow you to keep a little over 14 days of mail logging details.
When you want to view what happened you need to run the command WRKSMTPEMM, which will show something like this:
Using option 8 will result in:
For obvious reasons I have blurred some text, but I think you see my point why the SMTP server also needs an upgrade and needs to move away from the old *SDD setting. If the work of moving from the WRKDIRE entry causes you a headache, please be aware of the command STRIMPSMTP. This command will help you with the migration to *SMTP.
If you are not convinced yet, maybe the comment below from IBM support will:
“*SDD is quite old SMTP mode. It has its own limitations and has been replaced by *SMTP mode. The Mail router usage has actually been deprecated in RFC 2821 though it is still working in *SDD mode. However, in *SMTP mode, you can use “Forwarding mail-hub server” to do the similar functions. “
The last think I would like to mention is that IBM has recommended PTFs for the SMTP server, which can be found here: https://www.ibm.com/support/pages/ibm-i-support-recommended-fixes Below an image example of how this looks when selecting a recommended PTF for the SMTP server:
As you can see, the PTF SI73026 has been replaced by SI74858 which is dated 21 November 2021. So if you do have issues with your SMTP first bring it up-to-date with PTFs.
Just to give you some background, SNDDST and SNDSMTPEMM can be used next to each other and they both can send mail. Also here SNDDST is something of the past, it does the job. The mail you get as a result from it, looks old if you ask me. It is more an AS/400 look and feel. While the SNDSMTPEMM command allows you to use HTML which is more an IBM i look and feel. Adding an attachment is the big difference here, SNDDST will allow you to add a document from QDLS, while SNDSMTPEMM allows you to add a file of the IFS.
I do hope that after reading this article you agree that application modernization does not stop there, after all the SMTP itself is also an application and now you know there is room for modernization there too.
Charles Charalambous says
This article is very interesting and detailed for IBM i users with email enabled on their LPAR’s. Troubleshooting email related errors involves way too many different components. Even then no guarantee you will pin-point the error. However, your article covers most of the main issues encountered. Plus, latest changes is recent OS versions.
Since 2016 we have an email related error on a single test LPAR which IBM have not been able to resolve. Only because the email uses a third party product LANSA and a LEMI components which use API’s to wrap and send the email. IBM blame LANSA and LANSA blame IBM. For whatever reason on system start-up after nightly backups the single test LPAR starts numerous (20 max) separate test environments within separate subsystems which produce numerous emails which crashes starting the QMSF jobs (5). An internal workaround delay starts the starting of the numerous separate test environments but this is not always successful.
We believe SMTP pgms related to QMSF jobs lock each other due to multiple environments and high volume emails.. However, your article will provide another fresh look at troubleshooting this unresolved issue. Especially now that we have upgraded to V7R4 from V7R3.
Agree SMTP is getting an overdue facelift with a touch of modernisation.
P.S. An article published by IBM makes interesting reading – QZMF Journal Entry Format is Incorrectly Documented
Document Reference #: N1011496 http://www-01.ibm.com/support/docview.wss?uid=nas8N1011496>
Can you explain pls. the following :
I wonder why such important feature like SMTP users list created with option 1 of WRKSMTPUSR command
creates AUTOMATICALLY the email address in an “old fashioned way” for example : SYSTEM name + Domain, like
eli.sh@SYSTEM.Doman.com – which makes un impossible authentication for sender on relayed SMTP server.
Why IBM is forcing the rule for creating email addresses for list of SMTP users if those addresses have nothing to do with reality ?