MMAIL is another fantastic open-source project that fills a hole in IBM's standard offerings.

In my previous article, I introduced you to Thomas Raddatz's iSphere, one of the most robust enhancements to Rational Developer for i (RDi) out there and one that happens to be open source. In so doing, I made a passing reference to another open-source utility, Giovanni Perotti's MMAIL. MMAIL is an absolutely phenomenal piece of native software for the IBM i that is also open source.

Why Not Use IBM's Email Commands?

That's a great question! And if it were that easy, this might be a very short article. Unfortunately, the IBM commands have features that make them less than universally useful, particularly for my business case. The two commands are SNDDST and SNDSMTPEMM, and they each have their foibles.

SNDDST, for example, has been around since the early cave computers. It has all kinds of parameters relating to the infamous Document Library Services (DLS) framework. If you've never worked with DLS (and its commands CPYTOPCD and CPYFRMPCD), be thankful. Even for us dinosaurs, the 8.3 DOS-based limitations of that file system seem out of date. But the most challenging requirement is that the caller needs to be in the system directory.

The other problem with SNDDST is that you cannot override the sender's address. To do that, you have to create another entry using the ADDUSRSMTP command. This value is the one that will be used anytime you send an SMTP message using SNDDST. As it turns out, that's also the place the SNDSMTPEMM command gets its information, so a slightly more modern approach might be to eschew the system directory completely and use only SMTP users. You can do this, but you have to do a number of things, including changing your system's global SMTP attributes using the CHGSMTPA command. I'm never comfortable recommending changes at this level, so I'll leave it to you to decide if you want to do this. A good IBM document on the process can be found here.

One of the harder pieces for either approach, though, is planning for failover. When you add a new user profile, the user profile has to be enrolled on every system with a slightly different entry. The requires a bit of clever programming to replicate a user profile from one machine to another; you have to determine the unique entry on each target.

If Only There Were an Alternative!

Wouldn't it be great to have a simple, easy way to send an email? Let me specify from address, to address, and message text, and just let me send it. And maybe an attachment. Or a spooled file. Well, that's exactly what MMAIL does and more. A whole lot more, in fact! Once you've installed MMAIL, any user can send an email message. For example, let's say you just want to send a quick message from one user to another. It would be really nice to just be able to plug those values into an email address and send it. This is the idea behind the command EMLPTUMSG (E-mail impromptu message).

EMLPTUMSG SUBJECT('Meeting Reminder')    

         FROMADDR(This email address is being protected from spambots. You need JavaScript enabled to view it.')

         TOADDR(This email address is being protected from spambots. You need JavaScript enabled to view it.')

         MSGTXT('Just a reminder, we have a meeting at 10AM')

This is really quite simple, and it might be easier to just do that from a desktop mail client. The EMLMSG command has a slightly different configuration. This command expects a previously created stream file, which will be used as the body of the message.

EMLMSG SUBJECT('Morning Wakeup')    

     FROMADDR(This email address is being protected from spambots. You need JavaScript enabled to view it.')

     TO(This email address is being protected from spambots. You need JavaScript enabled to view it.'/*N/*TO)

     TXTSTMF('/mailtext/morning-wrapup-20201101.txt')

You may have a separate process entirely that sets up that text message, and then after you review it, you send it off. The TO address in this example is actually a distribution list; this is something that your company would maintain in your primary mail system. If you don't have distribution lists, MMAIL also allows you to set up distributions in the MMAIL product itself.

At this point you have probably noticed that this can not only send a message to anybody, but also send a message from (on behalf of) anybody. That's the primary feature that I needed, but it can get you in trouble as well. In a highly secure environment using SNDDST, users can send emails only if they are in the system directory, and access to the directory can be locked down tightly to administrative personnel only. While this approach has a lot of appeal to some businesses, it has its drawbacks, too. Take an environment where you have a server job that processes requests from many users. In order to create emails with the appropriate sender, the server job has to switch profiles, either by submitting a job or by swapping profiles. This adds complexity to the process.

Let's say you have a different situation. You might have a business package that already maintains lists of email addresses, both for your internal users and for your customers and vendors, and you have security in place for the maintenance of those addresses. The server job referenced above can access those files to get the email address information. In that case, you would write your own wrapper around the appropriate MMAIL command and call it in your server program. No, you don't have to worry about swapping profiles or maintaining the system directory.

Other Features

MMAIL has many other capabilities. I haven't really gotten around to anything more than minimal testing for some of them, but they look powerful. For example, MMAIL can send a spooled file as an attachment. You specify the spooled file like you would for any other command: the job, the spooled file name, and the spool number. MMAIL grabs the spooled file and sends it as a text attachment. Alternatively, you can tell it to convert the spooled file to PDF; it will attempt that as well. It has support for HTML messages, including some nice features like taking an HTML version of a report and then adding hyperlinks for web pages and email addresses.

But the single most important thing about MMAIL, and the reason it's in this article, is that it is free and open source. You can go review the programs to see how they work, and Giovanni has also included a service program. With the service program, if the commands don't work exactly how you want them to, you can get a little more technical and embed these features directly in your program. Or you can add your own features. In our environment, we use message descriptions a lot to support substitution variables. I'm going to write an extension to MMAIL to allow you to specify the body of the text as a 7-character message ID and up to 256 bytes of substitution data. And if I get it to work, I'll see if I can send it back to Giovanni to be included in a subsequent release; that's how open source works!

Also note that if you want to learn about commands—how to create them, how to write the support program, and how to create help panels—I highly recommend the MMAIL source code. There are lots of commands, many with lists of qualified parameters, and once you get the hang of that, you can create just about any kind of command you need.

Wrap-up

MMAIL is another great open-source product. I included the link to the product above, and here's a general link to the EASY400 web site. I was hoping to include a link to a donation page, but I was unable to find one. But in any case, if you do find the software helpful, be sure to let Giovanni know!