EmailDiscussions.com - View Single Post

n5bb · 1 Dec 2022, 11:05 AM

The Fastmail issue on Monday, November 28, appears to be due to an internal delay between Fastmail servers after authentication but before delivery into the user Inbox. Of course, this might have been due to some external issue, such as delays in checking against an external database for spam prevention.

I discovered this by looking at a number of emails I received at around (plus/minus an hour or two) 28 Nov 2022 11:00:00 -0500 (EST time zone at the Fastmail main servers). That's around 1600 GMT (UTC) on Monday, Nov 28.
If you want to check your messages, look for messages sent at around the time shown above. Look at the Received headers immediately following the final X- header (X-Mail-from).
In one example, a message was received from mx6.messagingengine.com by mailmx.nyi.internal at 10:37:24 -0500. The header immediately above that one shows that the message was then received from mx6 by compute2.internal at 11:15:08 -0500. That's a delay of 37 minutes and 44 seconds.
After that long internal delay, the message was delivered to the mailbox (top Received header) less than one second later. All other time stamps show normal short delays between the sending system and the Fastmail servers.

If you never receive a message supposedly sent to you, it can in some cases be due to the message not actually being sent, even though this may not be obvious to the sender.

Let's say you are using an email client. You compose an email and click Send.
But what if something prevents the message from being sent before you close the email client or turn off your computing device. For example, you might lose your WiFi or cellular connection or in some other manner access to the SMTP server you are using.
What's supposed to happen is for the email client to keep trying to connect and send that message, or let the user know there is some problem preventing the message being sent. In some cases there may be an Outbox (or other output queue) which shows messages which haven't been actually sent because the user was offline.
If that queued message isn't sent when the client goes back online, the message is stuck where the user might not notice it. In the past, I have seen a message get stuck where it didn't want to send even when I tried to force a retransmission when using an email client.
Another issue can be a malformed attempt at composing an email. If you enter an invalid or incorrect email address or forget to add a subject, the email client or webmail system may in some cases show an error to the user. But if the user closes the email client or webmail session or loses connectivity to the SMTP or sending webmail system before the user notices and repairs the issue, in some cases that message might be lost without being sent.
This issue caused difficulties for me with Fastmail webmail a few years ago when using a device at a remote location using an unreliable WiFi or cellular connection. I clicked Send, but the webmail system couldn't be reached and the message could be lost when I had to close the browser. But now Fastmail webmail uses the Save Draft feature to automatically (and/or manually) save temporary draft copies of the message you are composing. But you need to check your Drafts folder from time to time to be sure you don't have any unsent messages sitting there you intended to send!

Bill

1 Dec 2022, 11:05 AM	#6
n5bb Intergalactic Postmaster Join Date: May 2004 Location: Irving, Texas Posts: 8,927	Fastmail delay on Nov 28 seems to have been an internal issue The Fastmail issue on Monday, November 28, appears to be due to an internal delay between Fastmail servers after authentication but before delivery into the user Inbox. Of course, this might have been due to some external issue, such as delays in checking against an external database for spam prevention. I discovered this by looking at a number of emails I received at around (plus/minus an hour or two) 28 Nov 2022 11:00:00 -0500 (EST time zone at the Fastmail main servers). That's around 1600 GMT (UTC) on Monday, Nov 28. If you want to check your messages, look for messages sent at around the time shown above. Look at the Received headers immediately following the final X- header (X-Mail-from). In one example, a message was received from mx6.messagingengine.com by mailmx.nyi.internal at 10:37:24 -0500. The header immediately above that one shows that the message was then received from mx6 by compute2.internal at 11:15:08 -0500. That's a delay of 37 minutes and 44 seconds. After that long internal delay, the message was delivered to the mailbox (top Received header) less than one second later. All other time stamps show normal short delays between the sending system and the Fastmail servers. If you never receive a message supposedly sent to you, it can in some cases be due to the message not actually being sent, even though this may not be obvious to the sender. Let's say you are using an email client. You compose an email and click Send. But what if something prevents the message from being sent before you close the email client or turn off your computing device. For example, you might lose your WiFi or cellular connection or in some other manner access to the SMTP server you are using. What's supposed to happen is for the email client to keep trying to connect and send that message, or let the user know there is some problem preventing the message being sent. In some cases there may be an Outbox (or other output queue) which shows messages which haven't been actually sent because the user was offline. If that queued message isn't sent when the client goes back online, the message is stuck where the user might not notice it. In the past, I have seen a message get stuck where it didn't want to send even when I tried to force a retransmission when using an email client. Another issue can be a malformed attempt at composing an email. If you enter an invalid or incorrect email address or forget to add a subject, the email client or webmail system may in some cases show an error to the user. But if the user closes the email client or webmail session or loses connectivity to the SMTP or sending webmail system before the user notices and repairs the issue, in some cases that message might be lost without being sent. This issue caused difficulties for me with Fastmail webmail a few years ago when using a device at a remote location using an unreliable WiFi or cellular connection. I clicked Send, but the webmail system couldn't be reached and the message could be lost when I had to close the browser. But now Fastmail webmail uses the Save Draft feature to automatically (and/or manually) save temporary draft copies of the message you are composing. But you need to check your Drafts folder from time to time to be sure you don't have any unsent messages sitting there you intended to send! Bill