We do the same from our student system but all of those are automated and set to go under known pre-defined conditions. We average sending about 5,500 a day and maxed around 18,000 on day in the past year. We actually have all of our applications use a command, RPG call, stored procedure to "send" the email which just writes it to a database table. Then we have a never ending job that reads the database and uses the SMTP APIs (using a 3rd party interface that makes it easier) to push the email from the database into the SMTP engine. Also has a way to detect that the "TO" address is a phone number and instead of SMTP uses a call to a web service to send a text. We let employees access their "sent" database records to see what went out and let students see their "inbox" database records for up to 6 months (then we purge the database). Have very few issues with this process and when there is we can easily force a resend from the database
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Nathan Andelin
Sent: Wednesday, January 24, 2018 12:51 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: Re: IBM i SMTP email service
Mike,
In regard to your idea about building an IBM i application that sends mail through the IBM i SMTP service, that's what we did in our student information system:
https://imgur.com/a/zNRfJ
It sends messages to any number of recipients.
On Tue, Jan 23, 2018 at 9:11 AM, Mike Cunningham <mike.cunningham@xxxxxxx>
wrote:
All good questions. Right now we are exploring options. We have some
office that send out thousands of emails in adhoc requests. Last one
was near 5,000. (We have about 5,500 students). Up until a month ago
we had on site Exchange. In December we changed to Office 365 (many
advantages for higher ed outside just email services). Discovered
after that change that
O365 limits the "TO" box to 500 emails. So in the past a user could
cut/paste their entire 5,000 address list and send. Now they have to
select
500 at a time and send multiple times. Process killer? No, not in my
opinion, but there is sufficient push back from these offices to find
ways to make it better. So one alternative was to use the IBM I SMTP
server to send these mass emails by letting the user who needs to do
this connect and send as many as needed. (p.s. not my favorite
alternative but it is a possibility). Another avenue we are exploring
is a listserv what lets someone import a list of emails before sending
and then sending to the list. Could be some room for error here if
they load the list today with
1,000 and send their email, then next week load 2,000 without first
purging the original list. Emails could go to the wrong group. My
favorite option is we build a way for them to upload their list (csv),
we clear and then populate a database table and link that table to the
listsserv, or even just use the API calls to send the emails from the
i. Right now I don't know the complexity of the content of the emails
sent which might make that a limitation. HTML email with links and
images and multiple attachments. I don't think we could replicate the
capabilities of Outlook when composing an email.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
http://amzn.to/2dEadiD
________________________________
This email may contain confidential information about a Pennsylvania College of Technology student. It is intended solely for the use of the recipient. This email may contain information that is considered an “educational record” subject to the protections of the Family Educational Rights and Privacy Act Regulations. The regulations may be found at 34 C.F.R. Part 99 for your reference. The recipient may only use or disclose the information in accordance with the requirements of the Federal Educational Rights and Privacy Act Regulations. If you have received this transmission in error, please notify the sender immediately and permanently delete the email.
midrange.com
