It is easier to eat soup with a fork than to notify Bell Canada of issues with THEIR infrastructure or servers.
Some background:
One of my clients, let's call him John, who is NOT a Bell customer, sent an email to Suzy who IS a Bell customer. So basically:
john@abc.com sends an email to suzy@bell.ca (both names and email addresses are made up)
Ten minutes later, John gets a "Returned Mail" with the following error message:
Naturally, John emails me (since I host his email) and asks me why he can't contact Suzy. John is sure he has the correct email address for Suzy.
The error message is straightforward (mostly). I know what's wrong. I figured this is a piece of cake... I'll just forward this error message to Postmaster@isp.intranet.bell.ca (which is the email address at the bottom of the error message) so Bell's admins can change/fix the PTR record for their email server.
Nope. I can't email Postmaster@isp.intranet.bell.ca. No such email address. There isn't even an email server at isp.intranet.bell.ca. No worries. I'll just call Bell to report the issue.
After multiple phone calls, multiple transfers between departments and agents, NOT one agent knew what a PTR record is (which is somewhat understandable). When I asked to talk to a manager, an admin, an engineer, or "someone who handles your email servers" 7 out of the 8 agents told me:
1. They can't do anything unless I give them an account number - not even transfer me to a manager... not even notify their admins/engineers... nothing.
2. Their customer, Suzy, should contact Bell directly.
First, I'm not a Bell customer. I don't have an account with Bell. I don't have an account number. I find it silly (to keep it PG) that Bell agents need a string of digits in order to connect me to right person so I can report the issue. They refused to send/report the issue to their own admins/engineers.
Second, because of the nature of this issue, Suzy likely has NO CLUE that there is anything wrong with her email. What exactly is she going to report? Even she knew what the issue is, she's likely to have the same problem conveying the issue to Bell's agents as I did. And IF she can report it, why can't I? Magic string of digits?
The issue (in more detail):
Suzy is forwarding her Bell emails to Gmail (a very common thing). This why the error message John got came from gmail-smtp-in.l.google.com, a Google email server, and not Bell.
When John sent an email to Suzy, my email server sent John's message to 204.101.250.50, one of Bell's email servers, then Bell's email server forwarded the message to the Google's email server mentioned above. So, Me>Bell>Google. That's the path.
To reduce/prevent spam, Google's email servers check the PTR record & IP of the email server sending the message (Bell, in this case). The IPs need to match. In this case, they don't... and so Google rejects John's email to Suzy (and all emails coming from for the mis-configured Bell email server at 204.101.250.50). Suzy gets NO notification of this rejection.
The actual issue:
Bell's email server at 204.101.250.50 has PTR record of tor12vmxfep02.srvr.bell.ca. (https://toolbox.googleapps.com/apps/dig/)
However, tor12vmxfep02.srvr.bell.ca. resolves to 204.101.250.60 ...when it should resolve to 204.101.250.50
It's also possible that tor12vmxfep02.srvr.bell.ca is the wrong PTR record for 204.101.250.50 in the first place. Either way, there is a problem here,
Consequences:
There 2 different consequences here:
1. Bell customers connteced to 204.101.250.50 won't be able to send emails to Gmail OR any other company that has the same PTR policy as Google.
2. IF a Bell customer has forwarded their Bell email to Gmail, like Suzy, other people, like John, won't be able to send them emails to their Bell email address.
However, Bell has multiple email servers. And that complicates things a little bit.
I assume (but I could be wrong) Bell load balances their email servers. Basically, that means every time a customer tries to sign-in to their email, Bell gives them a random email server to connect to. If a customer happens to connect to 204.101.250.50 they won't be able to send email to Gmail. If they happen to connect to one of Bell's other "good" email servers, they will. The downside, in this case, is that this issue might persist for weeks, or even months, before the right admin/engineer at Bell notices it.
I don't know how email forwarding works on an email server, or how load balancing complicates email forwarding. That said, clearly at least one of Bell's email servers must be responsible for forwarding emails, and if that server happens to be 204.101.250.50, emails forwarded to Gmail and other companies with the same PTR policy will fail.
I tried, boys. The 8th Bell agent took some notes, but I doubt my notes will reach the right person at Bell.
Some background:
One of my clients, let's call him John, who is NOT a Bell customer, sent an email to Suzy who IS a Bell customer. So basically:
john@abc.com sends an email to suzy@bell.ca (both names and email addresses are made up)
Ten minutes later, John gets a "Returned Mail" with the following error message:
Naturally, John emails me (since I host his email) and asks me why he can't contact Suzy. John is sure he has the correct email address for Suzy.
The error message is straightforward (mostly). I know what's wrong. I figured this is a piece of cake... I'll just forward this error message to Postmaster@isp.intranet.bell.ca (which is the email address at the bottom of the error message) so Bell's admins can change/fix the PTR record for their email server.
Nope. I can't email Postmaster@isp.intranet.bell.ca. No such email address. There isn't even an email server at isp.intranet.bell.ca. No worries. I'll just call Bell to report the issue.
After multiple phone calls, multiple transfers between departments and agents, NOT one agent knew what a PTR record is (which is somewhat understandable). When I asked to talk to a manager, an admin, an engineer, or "someone who handles your email servers" 7 out of the 8 agents told me:
1. They can't do anything unless I give them an account number - not even transfer me to a manager... not even notify their admins/engineers... nothing.
2. Their customer, Suzy, should contact Bell directly.
First, I'm not a Bell customer. I don't have an account with Bell. I don't have an account number. I find it silly (to keep it PG) that Bell agents need a string of digits in order to connect me to right person so I can report the issue. They refused to send/report the issue to their own admins/engineers.
Second, because of the nature of this issue, Suzy likely has NO CLUE that there is anything wrong with her email. What exactly is she going to report? Even she knew what the issue is, she's likely to have the same problem conveying the issue to Bell's agents as I did. And IF she can report it, why can't I? Magic string of digits?
The issue (in more detail):
Suzy is forwarding her Bell emails to Gmail (a very common thing). This why the error message John got came from gmail-smtp-in.l.google.com, a Google email server, and not Bell.
When John sent an email to Suzy, my email server sent John's message to 204.101.250.50, one of Bell's email servers, then Bell's email server forwarded the message to the Google's email server mentioned above. So, Me>Bell>Google. That's the path.
To reduce/prevent spam, Google's email servers check the PTR record & IP of the email server sending the message (Bell, in this case). The IPs need to match. In this case, they don't... and so Google rejects John's email to Suzy (and all emails coming from for the mis-configured Bell email server at 204.101.250.50). Suzy gets NO notification of this rejection.
The actual issue:
Bell's email server at 204.101.250.50 has PTR record of tor12vmxfep02.srvr.bell.ca. (https://toolbox.googleapps.com/apps/dig/)
However, tor12vmxfep02.srvr.bell.ca. resolves to 204.101.250.60 ...when it should resolve to 204.101.250.50
It's also possible that tor12vmxfep02.srvr.bell.ca is the wrong PTR record for 204.101.250.50 in the first place. Either way, there is a problem here,
Consequences:
There 2 different consequences here:
1. Bell customers connteced to 204.101.250.50 won't be able to send emails to Gmail OR any other company that has the same PTR policy as Google.
2. IF a Bell customer has forwarded their Bell email to Gmail, like Suzy, other people, like John, won't be able to send them emails to their Bell email address.
However, Bell has multiple email servers. And that complicates things a little bit.
I assume (but I could be wrong) Bell load balances their email servers. Basically, that means every time a customer tries to sign-in to their email, Bell gives them a random email server to connect to. If a customer happens to connect to 204.101.250.50 they won't be able to send email to Gmail. If they happen to connect to one of Bell's other "good" email servers, they will. The downside, in this case, is that this issue might persist for weeks, or even months, before the right admin/engineer at Bell notices it.
I don't know how email forwarding works on an email server, or how load balancing complicates email forwarding. That said, clearly at least one of Bell's email servers must be responsible for forwarding emails, and if that server happens to be 204.101.250.50, emails forwarded to Gmail and other companies with the same PTR policy will fail.
I tried, boys. The 8th Bell agent took some notes, but I doubt my notes will reach the right person at Bell.
Last edited: