Differences

This shows you the differences between two versions of the page.

--- pub:smtpi [2024/08/20 11:54] – kkramer
+++ pub:smtpi [2024/08/23 21:57] (current) – [Relay Issues] kkramer
@@ Line 165: / Line 165: @@
 ===== Relay Issues =====
-We have a user that is reporting that email is not reaching one of their recipients. The email appears as **‘snt’** in the iMail log, but it was confirmed that they did not receive the email.
+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.
+. Email Connection and Processing:
+   - The email connection was established successfully.
+   - The email was accepted for processing by `postfix`.
+. Recipient Information:
+   - The email was intended for two recipients: `eaglenest@lakestreetcom.com` and `XXRISKI@XXMETALS.COM`.
+. 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.
+. 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.
+. 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.
+. 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.
+. 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.
+. 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.
+. 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.
+. 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.
+. 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.
+. 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.
 \\