EmailDiscussions.com  

Go Back   EmailDiscussions.com > Email Service Provider-specific Forums > FastMail Forum
Register FAQ Members List Calendar Search Today's Posts Mark Forums Read
Stay in touch wirelessly

FastMail Forum All posts relating to FastMail.FM should go here: suggestions, comments, requests for help, complaints, technical issues etc.

Reply
 
Thread Tools
Old 6 Dec 2021, 03:49 PM   #16
pjroutledge
Member
 
Join Date: Jan 2010
Location: Melbourne, Oz
Posts: 92
Is there a difference between the username parts of your Fastmail and Google email addresses?

For example, are you using something like '[email protected]' and '[email protected]'?

I have encountered services that won't accept symbols like '+' in an email address (despite it being valid) and record the email address as 'name [email protected]' (ie replacing the '+' with a space) which doesn't work but is not necessarily detected as the reason for failing.

That's just an example. Maybe it's worth testing an alternative if you are using different usernames?

(Unrelated but similar issue: this service doesn't seem to consider '[email protected]' to be a valid email address but it automatically converts '[email protected]' to display as an email link above.)

Last edited by pjroutledge : 6 Dec 2021 at 03:59 PM.
pjroutledge is offline   Reply With Quote
Old 6 Dec 2021, 03:55 PM   #17
n5bb
Intergalactic Postmaster
 
Join Date: May 2004
Location: Irving, Texas
Posts: 8,750
Arrow TTL (Time To Live) is crucial

Your DNS records include a TTL (Time To Live) field for each record. The TTL value specifies the requested time (in seconds) that DNS entries (such as MX) are cached. See:
https://en.wikipedia.org/wiki/Time_to_live

So if your old TTL value for the email related records (MX, SPF TXT, DMARC TXT) was 86,400 (one day), then over one day (maybe two days) before the changeover date you would change those TTL values to something small (such as 600 for 10 minutes). Then after the original TTL delay has passed (with some additional delay for good measure), you can change the DNS records (and their TTL values) to the new values.

Some servers may check your DNS records sooner than the TTL value specifies. But you can't depend on them using the new DNS record values until after the TTL-specified delay expires. This also depends on when the servers happened to have a need to check your DNS records. This is why some email servers may use the old MX value and others the new value.

Your sites should be:
  • Examine your old TTL values and write them down.
  • Change the TTL values of DNS records you will be changing to a small value (maybe 600). Be sure you verify that the authoritative DNS TTL values are actually changed by running a test.
  • Wait a bit longer than the original (old) TTL delay time. After that delay, any check of your DNS records should indicate a small TTL, so your MX entry should not then be cached very long by servers following the rules.
  • Change your DNS MX and other email-related records to the new desired values, including new TTL values (maybe an hour or a day).
But note this warning at the Wikipedia entry:
Quote:
However, a problem persists in that some caching DNS nameservers set their own TTLs regardless of the authoritative records, thus it cannot be guaranteed that all downstream DNS servers have the new records after the TTL has expired.
Also, some services accept different characters in the email address. Don't use any non-standard characters in your email address.

Bill
n5bb is offline   Reply With Quote
Old 6 Dec 2021, 04:29 PM   #18
BritTim
The "e" in e-mail
 
Join Date: May 2003
Location: mostly in Thailand
Posts: 2,968
Quote:
Originally Posted by Stokkes View Post
This is just baffling. I'm in IT professionally and really what I need to do is find a way to talk to a Fastmail admin - someone with root level access to the servers so we can see what's going on.
If, as I suspect, the issue is at the sending end, and Fastmail never sees any attempt to send the message, I cannot see how root access to Fastmail's servers would be any help. What is needed is the logs at the sending end. Do any of the senders who cannot reach Fastmail have good support teams who might be willing to work with you? Have you looked at the failing senders to see if there is a common factor (such as their using the same mail service)?

Those suggesting TTL and email address issues have presumably not considered the tests you have done switching back to Google and then to Fastmail again. The sending side (if the narrative so far is accurate) simply cannot reach the Fastmail MX servers.
BritTim is offline   Reply With Quote
Old 6 Dec 2021, 11:25 PM   #19
Stokkes
Junior Member
 
Join Date: Dec 2021
Posts: 15
Quote:
Originally Posted by pjroutledge View Post
Is there a difference between the username parts of your Fastmail and Google email addresses?

For example, are you using something like '[email protected]' and '[email protected]'?

I have encountered services that won't accept symbols like '+' in an email address (despite it being valid) and record the email address as 'name [email protected]' (ie replacing the '+' with a space) which doesn't work but is not necessarily detected as the reason for failing.

That's just an example. Maybe it's worth testing an alternative if you are using different usernames?

(Unrelated but similar issue: this service doesn't seem to consider '[email protected]' to be a valid email address but it automatically converts '[email protected]' to display as an email link above.)
The email addresses between Google/Fastmail are identical. My email is identical,username is identical. Not using any special characters or anything.

It's hard to test using alternatives as I can't easily reproduce the problem except with Paybright - because with Paybright I can actually trigger an email to my address anytime I want. Thing is, since I don't get the emails so i can't login.. catch 22.
Stokkes is offline   Reply With Quote
Old 6 Dec 2021, 11:27 PM   #20
Stokkes
Junior Member
 
Join Date: Dec 2021
Posts: 15
Quote:
Originally Posted by n5bb View Post
Your DNS records include a TTL (Time To Live) field for each record. The TTL value specifies the requested time (in seconds) that DNS entries (such as MX) are cached. See:
https://en.wikipedia.org/wiki/Time_to_live

So if your old TTL value for the email related records (MX, SPF TXT, DMARC TXT) was 86,400 (one day), then over one day (maybe two days) before the changeover date you would change those TTL values to something small (such as 600 for 10 minutes). Then after the original TTL delay has passed (with some additional delay for good measure), you can change the DNS records (and their TTL values) to the new values.

Some servers may check your DNS records sooner than the TTL value specifies. But you can't depend on them using the new DNS record values until after the TTL-specified delay expires. This also depends on when the servers happened to have a need to check your DNS records. This is why some email servers may use the old MX value and others the new value.

Your sites should be:
  • Examine your old TTL values and write them down.
  • Change the TTL values of DNS records you will be changing to a small value (maybe 600). Be sure you verify that the authoritative DNS TTL values are actually changed by running a test.
  • Wait a bit longer than the original (old) TTL delay time. After that delay, any check of your DNS records should indicate a small TTL, so your MX entry should not then be cached very long by servers following the rules.
  • Change your DNS MX and other email-related records to the new desired values, including new TTL values (maybe an hour or a day).
But note this warning at the Wikipedia entry:
Also, some services accept different characters in the email address. Don't use any non-standard characters in your email address.

Bill
Yeah about 2 weeks before I changed to Fastmail I set the TTL in Cloudflare (which manges my DNS) to 1 min for my MX records. You're right though that some DNS caches.. However, I'm pretty sure between Nov 20 to Dec 1 the cache would have expired (at least I hope so??) So while the cache can explain why email may not flow immediately after the change, it doesn't (or shouldn't) explain why it doesn't flow after a few weeks.
Stokkes is offline   Reply With Quote
Old 6 Dec 2021, 11:29 PM   #21
Stokkes
Junior Member
 
Join Date: Dec 2021
Posts: 15
Quote:
Originally Posted by BritTim View Post
If, as I suspect, the issue is at the sending end, and Fastmail never sees any attempt to send the message, I cannot see how root access to Fastmail's servers would be any help. What is needed is the logs at the sending end. Do any of the senders who cannot reach Fastmail have good support teams who might be willing to work with you? Have you looked at the failing senders to see if there is a common factor (such as their using the same mail service)?

Those suggesting TTL and email address issues have presumably not considered the tests you have done switching back to Google and then to Fastmail again. The sending side (if the narrative so far is accurate) simply cannot reach the Fastmail MX servers.
I'm not 100% convinced the people I have been talking to so far (first level support maybe?) are actually giving me a straight answer.

I'll give you a good example - my Sales advisor from Tesla can email me directly from his Tesla account and it works fine. When he uses his "system" which sends from Tesla.com as well, but shows his address - I don't get it and their system shows the email as "Undeliverable".

It's definitely, almost certainly, related to something about mass-email systems. Tesla, Shopify, some of my newsletters, Paybright, all use mass email systems to send email. Individual emails from people - no problem.
Stokkes is offline   Reply With Quote
Old 6 Dec 2021, 11:40 PM   #22
lpn
Member
 
Join Date: Apr 2007
Posts: 72
Quote:
Originally Posted by Stokkes View Post
I'm not 100% convinced the people I have been talking to so far (first level support maybe?) are actually giving me a straight answer.

I'll give you a good example - my Sales advisor from Tesla can email me directly from his Tesla account and it works fine. When he uses his "system" which sends from Tesla.com as well, but shows his address - I don't get it and their system shows the email as "Undeliverable".

It's definitely, almost certainly, related to something about mass-email systems. Tesla, Shopify, some of my newsletters, Paybright, all use mass email systems to send email. Individual emails from people - no problem.
Perhaps these companies are using a transaction email provider that for some reason has not updated the DNS records of your domain.
lpn is offline   Reply With Quote
Old 7 Dec 2021, 12:44 AM   #23
Stokkes
Junior Member
 
Join Date: Dec 2021
Posts: 15
Quote:
Originally Posted by lpn View Post
Perhaps these companies are using a transaction email provider that for some reason has not updated the DNS records of your domain.
That's my going theory right now.
Stokkes is offline   Reply With Quote
Old 7 Dec 2021, 03:31 AM   #24
BritTim
The "e" in e-mail
 
Join Date: May 2003
Location: mostly in Thailand
Posts: 2,968
Quote:
Originally Posted by lpn View Post
Perhaps these companies are using a transaction email provider that for some reason has not updated the DNS records of your domain.
Possibly, but why then do the messages not arrive in the Google mailbox? Does Google reject mail for active accounts if it detects that its MX servers are not in the current DNS? That would be a bit surprising because we tend to rely on the fact that messages may arrive at either the old or new mail server, for a limited time, when migrating from one system to another.
BritTim is offline   Reply With Quote
Old 7 Dec 2021, 04:55 AM   #25
Stokkes
Junior Member
 
Join Date: Dec 2021
Posts: 15
Here's the answer one of the providers I'm unable to receive messages got as a bounce.

Recipient
address rejected: User unknown in virtual mailbox table

Which makes absolutely no sense since as I said I get 99+% of my email so obviously the address exists.
Stokkes is offline   Reply With Quote
Old 7 Dec 2021, 05:01 AM   #26
n5bb
Intergalactic Postmaster
 
Join Date: May 2004
Location: Irving, Texas
Posts: 8,750
Quote:
Originally Posted by Stokkes View Post
Here's the answer one of the providers I'm unable to receive messages got as a bounce.

Recipient
address rejected: User unknown in virtual mailbox table

Which makes absolutely no sense since as I said I get 99+% of my email so obviously the address exists.
Was that a message sent to the Fastmail server? If so, was it sent to a personal domain or a Fastmail-owned domain? That is what you get if the email address is spelled incorrectly. A common mistake is fastmail.com vs fastmail.fm or some other variant. So look carefully at the full bounce message (will full headers if possible) and be sure that it’s addressed to the correct target address.

Bill
n5bb is offline   Reply With Quote
Old 7 Dec 2021, 05:42 AM   #27
Stokkes
Junior Member
 
Join Date: Dec 2021
Posts: 15
Quote:
Originally Posted by n5bb View Post
Was that a message sent to the Fastmail server? If so, was it sent to a personal domain or a Fastmail-owned domain? That is what you get if the email address is spelled incorrectly. A common mistake is fastmail.com vs fastmail.fm or some other variant. So look carefully at the full bounce message (will full headers if possible) and be sure that itís addressed to the correct target address.

Bill
Yes.. That's what the fastmail server responded with. And I guarantee you the address was spelled correctly since I've been on this mailing list for years. Stopped receiving email the moment I switched to Fastmail.

I'm trying to get them to send me the full message (they only sent me the copy and paste of the error). If I can get that I can send it to Fastmail support.
Stokkes is offline   Reply With Quote
Old 7 Dec 2021, 10:27 AM   #28
Terry
The "e" in e-mail
 
Join Date: Jul 2002
Location: VK4
Posts: 2,925
check that you have in1-smtp.messagingengine.com and not fastmail.com
Terry is offline   Reply With Quote
Old 7 Dec 2021, 01:38 PM   #29
Stokkes
Junior Member
 
Join Date: Dec 2021
Posts: 15
Quote:
Originally Posted by Terry View Post
check that you have in1-smtp.messagingengine.com and not fastmail.com
As I've said I receive 99.9% of my email. If I had the wrong MX entries I'd be getting bubkus.
Stokkes is offline   Reply With Quote
Old 7 Dec 2021, 05:23 PM   #30
hadaso
The "e" in e-mail
 
Join Date: Oct 2002
Location: Holon, Israel.
Posts: 4,610
This feels like a greylisting issue: normal mail gets through. Systems that send bulk mail and are configured not to retry sending do not get through (e.g. a system that sends a code that's valid for the next five minutes might be configured not to resend after more than five minutes have passed if the first try fails. So it fails greylisting and after repeatedly failing greylisting might be automatically added to a local blacklist).
hadaso is offline   Reply With Quote
Reply


Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +9. The time now is 03:21 PM.

 

Copyright EmailDiscussions.com 1998-2013. All Rights Reserved. Privacy Policy