[[[start#imail | Up To iMail ]]] ====== Using iMail with the IBM i SMTP and POP Servers ====== 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. [[https://informdecisions.com/support/|Click Here]] to get a quote or call us at (800) 858-5544. ===== Requirements ===== 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. ==== Host Table Setup ==== 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. {{pub:imail:hoststable.png?500|}} ==== User Profile Setup ==== 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: {{pub:imail:addsmtpname.png?500|}} 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 {{pub:imail:mailservicelevel.png?500|}} ==== DNS Requirements ==== If you intend to transmit emails outside the company's intranet, please be aware of the following \\ additional requirements: === Firewall === 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. === DNS === 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. \\ ===== Configuring iMail ===== 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. ===== Configuring IBM i Servers ===== 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 Route**r: 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 Email Client ===== 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. ===== Final Test ===== 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. ===== Relay Issues ===== 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. {{:pub:imail:imail-ns1.jpg?600|}}\\ 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". {{:pub:imail:imail-ns2.jpg?600|}}\\ 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: - The email connection was established successfully. - The email was accepted for processing by `postfix`. 2. Recipient Information: - The email was intended for two recipients: `eaglenest@lakestreetcom.com` and `XXRISKI@XXMETALS.COM`. 3. Delivery Status: - For `eaglenest@lakestreetcom.com`: - 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. - Status: Deferred. - For `XXRISKI@XXMETALS.COM`: - The email was successfully sent and queued by `smtp1-mke.securence.COM` with the response `250 OK, queued as 1722950656860-027-00122558`. - 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. ===== Relay Considerations ===== 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. \\ ---- [[[start#imail | Up To iMail ]]]