Quote:
Originally Posted by InquiringMind
Currently I am having a problem of getting severe delays in receiving emails that have attachments that are going from Polarismail to a Fastmail account that uses Fastmail's domain
...
When I raised the connectivity problem with Fastmail's "Tech Support" I got the response from them that it is a very hard problem and must be some routing issue only solvable by a wizard and hobbits.
I suggested to Fastmail's "Tech Spport" that since I have Spam Filtering turned off and am not using custom domains, that perhaps their general spam filter was having a problem analyzing pdf's and image files...
their response was again that they believe it to be some bizarre routing issue and very very hard to solve.
2. These database catagories and the values entered therein are very difficult to understand.
|
The "database" categories are mainly the IP addresses of the name servers that someone wanting to send mail to you has to look up (or more likely their mail provider has to once they've "sent the email to their provider for onward transmission) to find out where to send your mails to, and the IP address of the servers willing to accept your mails.
Internet traffic is not generally sent directly from the sending machine to the receiving one; instead it passes through any number of intermediate machines - none of which are under the control of you, or your mail provider, or the receiving system.
There are bottlenecks though - most mail (and website traffic and everything else) between eg the UK and the US will pass through one of a limited set of machines each end of the transatlantic cables.
As many machines in these networks are connected to many others there's more than one way for a piece of information to be sent from one to another. It could go directly (if there's a direct connection between the two machines and it's not too busy) or it could take a very indirect route passing through umpteen intermediate machines.
The internet was designed in the first place as a military/defence-network with resilience built in so that if machines (or cities) were wiped off the net traffic could still flow from places (not yet wiped off) to others ... and would find its own route through machines that were still connected. It's not necessarily efficient though.
Each of those machines has to keep uptodate a list of the machines it is currently connected to, and those that are reachable through the ones it is connected to.
Quite often loops get defined - so a message being sent from machine A to machine K might go to B and then C and then D .... and then D (for reasons no-one can fathom might send it back to B because it "knows" that its route to K is via B. Or was, even if it isn't any longer. And then maybe B sends it to E next time rather than C.
And maybe it NEVER gets to K. Or only does when one particular jump is less busy than usual. Or ...
It's NOT easy for eg Fastmail to work out why incoming traffic doesn't arrive timeously. Even if they can decide that there's a problem between two (sets of) machines, they don't necessarily have any way to contact the people who administer those machines, let alone the ability to convince them that there's a problem in the routeing tables in their machines.
If Fastmail think routeing is the problem then this has nothing to do with their spam processing .... which would only happen once your slow-to-arrive mail has arrived at FM. They can hardly scan the attachments before they arrive.
If you think your mails (& attachments) HAVE arrived at FM and then got lost inside FM's own network that's completely different.
All those hops from machine to machine are what's described in successive sets of "Received:" headers in a mail. The ones nearest the top of the "raw mail" are those that happened most recently. If you look at the timestamps on a mail that arrived, but took ages to arrive, you should see on which "hop" the delay occurred. You would need to look at a set of delayed emails to see if they all get delayed at the same point.