Delay in receiving mails
 

Hi all,

Does anyone experiencing the same right now?

It's no wonder I couldn't get all 2FA and confirmation emails on time and I thought it was the sender's problem. After I tried sending a test email from other accounts to my FM account (custom domains) then I realized it's FM's issue instead.

I hope it will be fixed soon!

From Twitter:

@Fastmail on Twitter:

Alot of mail servers have lately been seeing delays,not just fastmail...

I have had mail someone sent me NOT ARRIVE AT ALL!!

What happens to them?? Are they just deleted from the server before going out??

It's impossible to say -without seeing server logs - why an email didn't arrive; it might not have been sent, it might have got lost en-route, it might have arrived but been deleted by the receiving system (eg at the SMTP gateway), or - lastly - it might have arrived but been misfiled in your folder hierarchy.

Having said that, it's clear to me that some sending email systems do not do retry at all. I've had (paper) letters from banks telling me that my email address is invalid and asking me to define it ... even when they've previously sent me email.

I think either their sending system does no retry and one failure (eg no route to the receiving system, or the receiving system is down for maintenance, or suffering a DDOS attack or...) and they give up. Decent systems retry - at intervals for up to a week.

Alternatively, although you'd think their computer systems have stored my email address and automatically use it when emailing me, maybe things are primitive and some clerk c&p my address from one place to another (which should be fine) or retypes it by eye (which might not be).

I have found it impossible to get normal cistomer service staff to engage on this matter, so these days - when I can be bothered - I raise a formal complaint with the bank(s) in question, asking for their evidence (ie SMTP logs) that they sent the email and asking for the log detail to show that a receiving system actually accepted it, or rejected it.

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

Thank you Billy for the update :)

Not scientific, but I find when emails I am expecting don't arrive most of the time they are in the Spam/Junk folder. Other times I have found they are sending the email to the wrong address, or they mangled the email address at their end. There is often nothing to alert the sender they are using an incorrect address. And, I have found that it is very easy to think I sent an email only to find it in my Drafts--I imagine that happens to everyone.

There is no "Y" in my name. Are you "Bamby"? :eek:

Hehe I hear ya buddy :)