One can effectively use the IBM i SMTP and POP servers to route emails originated
by iMail. These servers are part of the core operating system and thus no extra cost.

The IP of the IBM System i in this example will given as 192.168.0.128.

Helpful Hand: If you need an extra hand, contact us to get a quote to have inFORM Decisions do the work for you. Click Here to get a quote or call us at (800) 858-5544.

You will need:
An email account to use as the from address. This account can be in either of these formats:
JohnDoe@DoeDomain.com, or
JohnDoe@Server.DoeDomain.com

These instructions will work with the account in the first, more common format.

The IBM i server must understand itself as DoeDomain.com. This can be established
by making an entry in the hosts table, menu CFGTCP option 10.

A user profile, JohnDoe, must be established with a password.
A directory entry must be established for him.

WRKDIRE, option 1 to add.

Complete the first screen as a normal directory entry, then:

Press F19 to add an SMTP name:

Returning to the main definition of the directory entry, page down a few pages
and set the following:

Mail Service Level - 2 System message store
Preferred Address - 3 SMTP Name

If you intend to transmit emails outside the company's intranet, please be aware of the following
additional requirements:

Some companies restrict outbound port 25, the well known smtp port. This port will need to be opened
so that the IBM i may transmit email outside the intranet.

The company's DNS records must be altered:

• An A or CNAME record must be established for the apparent source IP of the SMTP server.
• An MX record must be established for the server name provided in the A or CNAME record.
• The SPF must be reviewed, altered and/or created as appropriate to provide for the IBM i SMTP Server.

Menu IMAIL, option 1 to configure iMail.

Set the SMTP Host Mail Server to the IP of the IBM i server: 192.168.0.128
Set the SMTP Port to: 00025
Set the Email Send Method.(SMTP/ESMTP) to: SMTP

Set these addresses: Sender Address, Default From Address to JohnDoe@DoeDomain.com.

Start Operations Navigator, and drill down to Network, Servers, TCP/IP.
Right click on the SMTP server and select properties.

The following settings are “cookbook”, and should work in basic situations.
This presumes the default setup.

General Tab:

Use Mail Router: None

Relay Restrictions Tab:

Allow Relay Messages: Set the radio button to Specified.
In the bottom of the dialog work with the Addresses Allowed to Relay dialog to
specify the subnets and masks allowed to work with this email server. This should include:

192.168.0.128 255.255.255.255 to include the IBM i server itself
192.168.1.0 255.255.255.0 to include all of Doe Corporation's PC's.

Multiple Domains Tab:

Check the checkbox: Specify domains associated with each interface.
Use the dialog to add DoeDomain.com to the interface 192.168.0.128.

Additional Parameters Tab:

Uncheck Support Delivery Status Notification to cause the server to return emails to the sender rather than notify one email address of all failures.

When done click 'OK' to save. Then right click on the SMTP server and select 'stop'. Next right click on the SMTP server and select 'start'.

Next right click on the POP server and select the General Tab:

Check the checkbox to start when TCP/IP is started.
Click the radio button to specify non-secure only.
Click 'OK' to save. Then stop and restart the server as you did for the SMTP server above.

At this point the SMTP and POP servers should both be running.

Using a PC client such as Outlook, configure a new profile as follows:

1. User name: johndoe
2. Password: greenscreen password
3. Email address: JohnDoe@DoeDomain.com
4. SMTP Server address: 192.168.0.128 - the IP of the IBM i server.
5. SMTP Port: 25
6. Use POP3 for retrieving email, not imap.

You should now be able to send and receive email using Outlook, with the email server being
the IBM i.

Go to menu iMail, option 12. Send a message to JohnDoe@DoeDomain.com.
Then, go to Outlook and check for new emails. It should be in the inbox.

A user reported that a specific email is not reaching one of their recipients. The email appears as ‘SNT’ in the iMail log, but it was confirmed that the recipient did not receive the email.

If the user sends email to this email address from Outlook it works fine. Just not working out of the iMail server.

The iMail job log indicates that the email was sent, but the recipient hasn’t received it.
In the job, we can see the successful negotiations to the email server/relay. iMail reached out to the email server/relay and the server/relay replied with an acknowledgment. Later, we see that the email server/relay replied with the message that it queued up the message for sending “R: 250 2.0.0 Ok: queued as 76987E006C”. The question is: Did the email server/relay send the email package that it placed in the queue and what was the output of sending the email or not sending the email to the recipient “eaglenest@lakestreetcom.com”.
Below is a breakdown of the information provided from the exchange server. It clearly shows that the email for “eaglelake@mainstreet.com” was not sent. See the information under Conclusion and Issues for the details.

1. Email Connection and Processing:

1. The email connection was established successfully.
2. The email was accepted for processing by `postfix`.

2. Recipient Information:

1. The email was intended for two recipients: `eaglenest@lakestreetcom.com` and `XXRISKI@XXMETALS.COM`.

3. Delivery Status:

1. For `eaglenest@lakestreetcom.com`:
   1. The email was deferred. The host `mx-99.us-east.tamailcloud.com` refused to talk to the sending server due to the IP `[999.41.198.25]` being listed on Cloudmart CSI Suspect, which is causing throttling.
   2. Status: Deferred.
2. For `XXRISKI@XXMETALS.COM`:
   1. The email was successfully sent and queued by `smtp1-mke.securence.COM` with the response `250 OK, queued as 1722950656860-027-00122558`.
   2. Status: Sent.

Conclusion: - The email to `XXRISKI@XXMETALS.COM` was successfully sent. - The email to `eaglenest@lakestreetcom.com` was not sent and is currently deferred due to the sending server's IP being listed on Cloudmart CSI Suspect.

Issues: - The main issue is that the IP `[999.41.198.25]` is listed on the Cloudmart CSI Suspect list, causing the email to `eaglenest@lakestreetcom.com` to be deferred. This needs to be addressed to ensure successful delivery.

Naturally, there is a certain amount of unreasonable expectation that a recipient would have to clear emails via a whitelist with their IT folks to receive a sales quote. At the same time in today's security-minded IT environments, we've seen tighter scrutiny regarding inbound emails. In some situations, inbound emails are highly filtered and tested for malicious content, phishing, and SPAM.

So the question is, what mitigation actions can be done by the sender to assure as much as possible that the emails going out are well received?…

Senders can check to make sure they have good email authentication protocols, reverse DNS lookup, good IP address reputation (not on a blacklist), good content quality, and make sure emails are not accidentally sending malicious email content.

Helpful items to consider when assuring that emails going from iMail on your IBM i server through a relay server successfully reach recipients without being blocked or rejected by receiving email servers. These items will help mitigate situations in which iMail successfully hands the email package to the relay server for transport, but the email does not reach the recipient on the To Address of the email.

1. Email Authentication Protocols

• SPF (Sender Policy Framework): Ensure your SPF record is correctly set up in your DNS settings. This helps verify that your email server is authorized to send emails on behalf of your domain.
• DKIM (DomainKeys Identified Mail): Implement DKIM by adding a digital signature to your emails, which verifies that the email content hasn’t been altered during transit.
• DMARC (Domain-based Message Authentication, Reporting & Conformance): Use DMARC to specify how receiving mail servers should handle emails that fail SPF or DKIM checks. Set it to “quarantine” or “reject” after monitoring.

2. Reverse DNS Lookup

• Ensure your mail server’s IP address has a corresponding PTR record in DNS, mapping the IP to your domain. This helps validate your email server’s identity.

3. IP Address Reputation

• IP Blacklists: Check if your server's IP address is listed on any blacklists. Being listed can cause your emails to be marked as SPAM.
• Warm-up New IP Addresses: If using a new IP, send emails gradually to establish a positive reputation.

4. Content Quality

• Avoid SPAM Trigger Words: Be mindful of language and formatting that could be flagged as spam, such as excessive use of all caps, exclamation marks, or phrases like “Buy now.”
• Proper HTML Formatting: Ensure your emails have clean HTML code. Poorly formatted HTML can trigger spam filters.
• Balanced Text-to-Image Ratio: Avoid using too many images with little text, as this can be seen as a spam tactic.

5. Subscription Management

• Unsubscribe Link: Include a clear and functional unsubscribe link in all promotional emails to comply with regulations like CAN-SPAM.
• Consent: Ensure you have explicit consent (opt-in) from recipients before sending marketing emails.

6. Sending Practices

• Avoid Bulk Sending: Don’t send large volumes of emails at once. This can trigger spam filters or overwhelm your server’s reputation.
• Monitor Bounce Rates: High bounce rates can signal spam-like behavior. Regularly clean your email lists to avoid sending to invalid addresses.
• Consistent Sending Patterns: Sudden spikes in email volume can raise red flags. Maintain consistent sending habits.

7. Monitor Feedback Loops

• Some ISPs provide feedback loops (FBL) that notify you when recipients mark your emails as spam. Monitoring these can help you address issues quickly.

8. Check for Malware or Phishing Links

• Scan Emails: Regularly scan outgoing emails to ensure they don’t contain malicious attachments or phishing links, as these are prime reasons for being marked as spam.

9. Email Throttling

• Implement email throttling to limit the number of emails sent per minute/hour, especially if you’re sending a large campaign.

By addressing these points, you can significantly reduce the chances of your emails being marked as spam or flagged as bad emails.

[ Up To iMail ]