In most cases, they are fairly accurate (at least to within a few seconds), but it’s definitely not foolproof. However, this has one interesting flaw: it still assumes everyone’s clock is set correctly, including all the mail servers.
#Send to kindle app taking a long time full#
In the example above, the message spent over a full minute on the spam filtering service’s server before being passed to my server. In theory, once you account for time zones, you can relatively accurately trace how long the mail spent on each server along the way, and thus identify any potential bottlenecks. In that last entry, for example, “08:15:11 -0700” indicates 8:15 am in the time zone 7 hours behind UTC (Universal Time Coordinated or, less correctly, GMT, Greenwich Mean Time). Note that each timestamp is in 24-hour notation, and also includes its time zone designation. Each “hop”, as they’re called, includes the timestamp the message was received, which I’ve highlighted in bold above. Starting at the bottom and working upwards, you can see the email message make its way from my email service provider () to a spam-filtering service, and then on to my server (). With ESMTP id 8njXs1vAjrlP3xsh (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO)
#Send to kindle app taking a long time series#
The header will have a series of lines that look similar to this: Received: from (:56405 helo=)īy with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88) If you examine the mail headers of a message, 2 you can see the date and time that each mail server along the way acted on the message.
The clock on the computer sending the email was set incorrectly. If you’ve ever seen email (particularly spam) “from the future”, that’s probably what’s happened. If they have their date and time set wrong, that wrong date and time shows up on the email they send. One thing making things very confusing is that the date and time displayed on the email are usually the date and time the email was sent, as displayed from the sender’s computer. The sender had to take steps to re-send the mail. Depending on how long all that took, it could look like a delay, but it definitely wasn’t automatic. On getting the bounce notification, the sender could try again, and if you’d made room in your mailbox since the first attempt, the mail might be delivered as expected. On rare occasions, it might be discarded. If your mailbox is full, most email services return a message to the sender - called a “ bounce” - indicating your message could not be delivered. Delays versus bouncesĪ full mailbox is typically not a reason for a delay. 1 Delays may be minutes, hours, or, in worst-case scenarios, even days.Īnd all those delays are OK, at least as far as the servers are concerned. Naturally, there are other potential causes for delays, including how often you check your mail. Most often, that’s due to a flood of spam. I would guess that in most cases, delayed email is due to one of the mail servers along the way being overloaded and running slowly. In fact, if they’re overloaded with mail, spam, or other tasks, they could take a while, and that’s quite OK according to email protocols. Surprisingly, there’s no requirement that those servers operate quickly, or in any timely fashion.
:max_bytes(150000):strip_icc()/addapprovedemailaddress-1bcf939e382443329f024e00685d2b6a.jpg "send to kindle app taking a long time")
The sender’s email server, and yours, of course but it’s possible that several intermediate servers may also be involved, each one receiving and then passing the email on to the next server along the route. While it seems email goes directly from your outbox to your recipient’s inbox, in reality, it travels across multiple servers. Delays are most commonly caused by Server issues and floods of spam. The email infrastructure has improved to the point that it’s almost always very fast, but delays can still happen. Email was never designed to be instant, and was built with tolerance for lengthy delays.
0 kommentar(er)
