BENEFITS OF BEACONHELP AND SUPPORTUSING BEACON

Resolving Email Problems

Roy Biggs, the Team Lead for on-going help, gives us the following tips on how to maximise the chances of your Beacon email being delivered successfully, and how to approach problem-solving if problems do arise.

An Insight to email Issues

When a problem occurs with Beacon email, Beacon’s E-mail delivery log can provide information that may help in identifying the cause. Before delving deeper in the E-mail delivery log, it is probably worth understanding a couple of points.

The first is that Beacon’s E-mail delivery log is not an error log, but a status log with the status of each e-mail address entry continually updated as the mail progresses through the network. If an e-mail encounters a problem such as rejection by the recipient server, the E-mail delivery log entry may contain additional error information that may help in the diagnosis of the problem.

The second point is that whilst it may appear the sending of e-mail is instantaneous, it is not. e-mail whether, sent from Beacon or another e-mail service provider, takes time to be delivered. Most times it is delivered in seconds but it is not uncommon, even under normal circumstances, for it to take minutes or even hours. In situations where a recipient server has to temporarily reject an e-mail and possibly multiple times, delivery can take days, weeks or in extreme cases, months.

When investigating a Beacon e-mail issue and needing to find the relevant log in the E-mail delivery log it is important to remember these points and to use the Sender’s user name, the subject line information and, if known, the precise time the e-mail was sent to find the specific log. This is because the timestamps in the individual status lines, in any additional information or in e-mails sent by Beacon to the Site Administrator, originate from the recipient server or the member’s actions so are always after the original e-mail was sent.

Document Email Delivery Explained in the Knowledge Base https://u3abeacon.zendesk.com/hc/en-gb/articles/360007389117-Email-Delivery-explained provides details of the various status messages found in the E-mail delivery log. Some status are created by Beacon but most are created by SendGrid, Beacon’s e-mail service provider and in many cases, using information provided by the recipient server.

When sending an e-mail, the sending server, negotiates with the recipient server, assuming they can connect to each other, to place a copy of the e-mail on the recipient server. They do this using SMTP (Simple Mail Transfer Protocol) and a sequence of commands and status response codes. Generally, the recipient server has three options:

  • All being well, it will accept the e-mail, deliver it to its user and return status code 250 to the sender. This will be reported in the E-mail delivery log as Delivered.
  • There may be a temporary condition that prevents the recipient server accepting the e-mail. In this situation, it should return a status code beginning with 4XX such as 450 - Mail box unavailable to the sending server. This will appear in Beacon’s E-mail delivery log as Blocked together with the status information. Blocking allows the sending server to attempt resending the e-mail and whilst again it may be Blocked, it will usually be delivered after the temporary condition is removed. After a succession of Blocked attempts and if still unable to accept the e-mail, the recipient server may reject it permanently by returning a 5XX status code to the sending server. When this occurs and because of the intentional delay between resend attempts, a permanent rejection is likely to occur long after the e-mail was originally sent.
  • A permanent error will appear in the E-mail delivery log as Bounced and usually with the additional 5XX code information. Such and error can occur for many reasons and analysis of the E-mail delivery log entry is critical in understanding the root cause. Common reasons for Bounce are the e-mail address is wrong such as it contains a typo or does not exist and probably because the member has changed their e-mail service provider but has forgotten to notify their u3a. Other common reasons for Bounced e-mails are due to the recipient server considering the e-mail is spam or malicious. On this point it is worth remembering that Beacon e-mail has a characteristic of a spam or malicious e-mail sender by being a one-to-many sender. By this I mean all Beacon e-mail, regardless of the u3a or user sending it, originates from a single IP address and with a ‘From’ address of noreply@u3abeacon.org.uk. Moreover, u3as collectively send well over a million e-mails a month and during the pandemic, exceeded 1.5 million e-mails! This makes following the guidance in Tips for Sending Email from Beacon in the Knowledge Base https://u3abeacon.zendesk.com/hc/en-gb/articles/360007431577-Tips-for-Sending-Emails-from-Beacon.
  • When SendGrid receives a Bounce, it will block (this is different to a recipient server’s Blocked) the e-mail address to prevent further attempts to send e-mail and possible reputational damage to Beacon’s mail server. Before e-mail can be sent to blocked member e-mail addresses again, they will have to be unblocked using Beacon’s E-mail unblocker. This function is only available to Site Administrators when logged in as Site Administrator and appears under Misc on Beacon’s main menu. Before unblocking an e-mail address, please ensure it is correct and if necessary check this with your member. This is particularly important with e-mail addresses @talktalk (free), @tiscali, @lineone and the freeserve suite of domains ie @orange, @orangehome, @wanadoo, @fsxxxx etc, @freeserve as the current owners of these once free e-mail services have adopted new policies leading to some u3a members moving to new e-mail service providers.

The Beacon HelpDesk can assist in analysing E-mail delivery logs and advising on possible resolutions to e-mail problems. Contact the team by raising a ticket at https://u3abeacon.zendesk.com . When reporting a problem, it will help if you can provide the full status entry, for the affected member e-mail address and the Log header that includes the sender’s name, subject information and timestamp in the E-mail delivery log header. If possible please send them as screen captures.

Roy Biggs, Team Lead, on-going help.