Does TekSavvy "static IP" guarantee that you can run a mail server (hint: Bell's DOESN'T.)
Geoffrey Welsh
I'm doing some work for this guy who has "Business Internet High Speed Ultra"
(including "A Static IP")(1) from Bell. So we set up his domain's MX record
to point to our mail exchanger in a hosting center, and we forward to his
internal mail server via that static IP.
(1) http://www.bell.ca/shop/Sme.Sol.Internet.High.Speed.Static.Ip.page
A couple of days after we set this up, he's on the phone telling us that his
email isn't coming in. Sure enough, our mail exchanger is timing out trying
to connect to that IP address and mail is collecting in the spool directory.
OK, so maybe Bell's messing with port 25. I reconfigure his mail server and
our transport map to use port 2525. Everything works and I tell him the
problem's fixed.
Next day, he's a bit miffed because his email's not coming in again after I
told him I fixed it. Sure enough, they're blocking port 2525 as well... or
maybe I should say in stead, as port 25 works fine now. I can also connect
from any IP address OTHER than the one we want to be sending from. Whatever
port or IP address I choose works for a while and then doesn't, as if someone
or something sees it's being used for SMTP and blocks it for a while.
After hours on the horn to Bell support, Bell abuse, Bell networking, Bell
sales, and Bell repair, we were told that what we have is a static _dynamic_
address (as opposed to a static dedicated) and that this affects incoming
mail as well as outgoing mail. There is no fine print and nothing in the
terms and conditions of Business Internet High Speed Ultra saying you can't
operate a mail server on it, and the Bell sales person says that there is no
such limitation. Bell technical people, on the other hand, say that
salespeople don't know anything and it is an unwritten Bell policy not to
support mail servers on this type of service and what we need is "Business
Internet Dedicated service", which not only costs more but costs enough that
Bell doesn't advertise a price on their web site.(2)
(2)
http://www.bell.ca/shop/en_CA_ON/Sme.Sol.Internet.High.Speed.Dedicated.page
One conversation went something like this:
Bell guy: We don't support operating mail servers on that kind of service.
Me: We don't want you to support it, we just want you not to interfere with
basic TCP/IP connectivity.
My boss: Wait, if you're selling something as having no limitations, but you
all know that there are limitations, isn't that fraud?
Bell guy: We can't comment on the fraud question, but this service is not
appropriate for what you are trying to do.
Me: Well, if it isn't, can you at least let the customer out of their
contract so we have the option of finding them some connectivity from someone
other than Bell? You understand, we don't like you very much right now.
Bell guy: I'm sure something can be arranged. Let me transfer you to
billing...
My boss and I, together, screaming: NOOO! Please don't make us start
explaining this from scratch to yet another person who doesn't understand
what we're talking about!
We're not talking a lot of email here, maybe 50 or 100 a day tops, so I can't
imagine why Bell would allow a static IP but not SMTP, unless of course it's
a blatant way to force customers with mail servers to upgrade to a more
expensive service (as if $100/month wasn't enough, compared to TekSavvy's $59
+ $ for a fixed IP.)
I'd like to tell him to switch to TekSavvy's business DSL service with static
IP, but I'm afraid that TekSavvy's service might be limited by Bell at the
under-PPPoE level. Can anyone prove that we can solve the problem by
switching?
Thanks,
--
Geoffrey Welsh <Geoffrey [dot] Welsh [at] bigfoot [dot] com>
Under no circumstances will I ever purchase anything offered to me as the
result of an unsolicited email message. Nor will I forward chain letters,
petitions, mass mailings, or virus warnings to large numbers of others. This
is my contribution to the survival of the online community.
- Roger Ebert, Boulder Colorado 1996
Marc Bissonnette
keyboard. This was the result:
news:abbef$48f8d849$cf702104$74...@PRIMUS.CA:
You know, I ran into a similar problem with a customer of mine, as well:
They've got 9 POPs, want to handle all their own mail plus a few other
toys that require TCP/IP connectivity via their domain.
Long story short: Moving their services from Bell "business" to another
ISP and host literally solved everything. Given the client is an
engineering firm, their time is important and expensive: Client rep said
that dealing with Bell on almost *anything* was literally a 4 hour cost
to their company.
Bell *could* be the be all and end all of ISPs: Ghu knows they've got the
technology and infrastructure. However, the past decade has proven,
beyond a shadow of a doubt that their people on both the front-line and
executive level just don't want to cater to anything but the "connect to
the web and read email from my grand kids" consumer base. (I'm excluding
the Bell folk who actually work in the switching centres and in the
field: I've had the pleasure of meeting a great deal of them and nearly
all of them were competent people who are exemplary of their career
sector)
Bottom line: If you need anything other than a basic residential internet
connection, don't choose your telco or cableco.
--
Marc Bissonnette
Looking for a new ISP? http://www.canadianisp.com
Largest ISP comparison site across Canada.
Something to sell ? http://www.pennypinchernewspaper.com
Ghislain
other port that I've needed, but I never had a need for SMTP.
"Geoffrey Welsh" <re...@newsgroup.please> a écrit dans le message de news:
abbef$48f8d849$cf702104$74...@PRIMUS.CA...
Sylvain Robitaille
> I'd like to tell him to switch to TekSavvy's business DSL service with
> static IP, but I'm afraid that TekSavvy's service might be limited by
> Bell at the under-PPPoE level. Can anyone prove that we can solve the
> problem by switching?
I don't use TekSavvy's business DSL service, so my response will be of
only limitted value, but I do use TekSavvy's residential DSL service, with
a static IP address, over which I've never had any trouble running my own
SMTP service. TekSavvy's customer support people are very responsive,
extremely competent, and will work to accomodate any reasonable request
(or so it seems). Mind you, it's been a few years since I needed to
communicate with anyone there at all.
Their residential service just works, and keeps working, and I think
that alone says important things about what you should expect from their
business service.
I hope that helps ...
--
----------------------------------------------------------------------
Sylvain Robitaille s...@alcor.concordia.ca
Network and Systems analyst Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------
Johnny Rebel
<snip>
> Bell *could* be the be all and end all of ISPs: Ghu knows they've got the
> technology and infrastructure. However, the past decade has proven,
> beyond a shadow of a doubt that their people on both the front-line and
> executive level just don't want to cater to anything but the "connect to
> the web and read email from my grand kids" consumer base. (I'm excluding
> the Bell folk who actually work in the switching centres and in the
> field: I've had the pleasure of meeting a great deal of them and nearly
> all of them were competent people who are exemplary of their career
> sector)
Good way of putting it - never heard that before. I don't know why they
spend soooo much time trying to deny everything. It seems like so much
additional cost and effort to not be worth it. I imagine that they are
trying to keep all heavy users / technical types out because they
actually use bandwidth, and grandma doesn't use much, doesn't know what
bittorrent is, and certainly is not well versed in a sendmail.cf
file.... I really wonder if it is worth it in the end. I suppose the
fact that they do it means it is.
>
> Bottom line: If you need anything other than a basic residential internet
> connection, don't choose your telco or cableco.
You got it with that one (oh, and don't choose Primus either... Unless
you know Punjabi).
JR.
>
>
>
--
Bill will have to take Linux from my cold, dead flippers.
-Tux.
Geoffrey Welsh
> I don't use TekSavvy's business DSL service, so my response will be of
> only limitted value, but I do use TekSavvy's residential DSL service,
> with a static IP address, over which I've never had any trouble
> running my own SMTP service.
Actually, that's very valuable. If it works with residential service, it's a
good bet it would work with business service.
Geoffrey Welsh
also sent Rocky a copy of the message but, since it was Friday afternoon and
for all I knew he might have been away on vacation, I counted on this forum
to help me out.
You came though big time.
Rocky did answer pretty quickly and my boss, who spent many hours on the
phone over a two-day period trying to get a hold of someone who could just
understand what we were saying, was astounded. "Let me get this straight,"
he says, "the _CEO_ answered your email in less than two hours?!?"
Now all we need to do is spend a few days convincing Bell to let the customer
out of his contract...
Madonna
> Rocky did answer pretty quickly and my boss, who spent many hours on the
> phone over a two-day period trying to get a hold of someone who could just
> understand what we were saying, was astounded. "Let me get this straight,"
> he says, "the _CEO_ answered your email in less than two hours?!?"
<rhetorical question>
Do you think the Bell CEO gives a rat's ass about HIS customers?
</rhetorical question>
Some Guy
IP) for the past 3 years.
We operate our own SMTP (and http) server. Absolutely no problems for
incoming mail to our domain.
In fact, for the past 2.5 years, I've been running our domain without an
MX record - because all legit SMTP servers know to fall back to a
domain's A record when mx lookup fails. Since we have only a single
static IP, our A record matches what our MX record would be. By not
having a public MX record, our spam load dropped by 75% the day our MX
record went off-line, and it hasn't grown appreciably since. But I
digress.
Initially, our SMTP server was both our in-coming and out-going MTA, but
we quickly found that some recipient MTA's were rejecting our mail
because of the rDNS lookup on our IP (seems they don't like seeing "ppp"
in the rDNS, perhaps among other things). I don't know if in the past 2
years if Bell has blocked port-25 out-bound on their business customers,
but I know that 3 years ago they were allowing it.
Bell/Sympatico doesn't allow you to configure the rDNS of your static IP
- does TekSavvy?
So we simply set the outgoing server IP address setting of the mail
clients of our office PC's to that of Bell's outgoing server.
I would be staying with Bell were it not for the fact that they've been
jacking up the price of the static IP option. Bastards. I think it's
$25 currently. Since we signed a 3 year contract, I think I have a
short window around the time the contract ends to cancel the service or
Bell gets to auto-renew it (yes?).
JF Mezei
> Bell/Sympatico doesn't allow you to configure the rDNS of your static IP
> - does TekSavvy?
Yes. This is one of the big advantages of Teksavvy. It lets you have a
decent SMTP server with the stuff remote SMTP servers expect you to have.
> Since we signed a 3 year contract, I think I have a
> short window around the time the contract ends to cancel the service or
> Bell gets to auto-renew it (yes?).
You can (or should) be able to signal to Bell in advance that you do not
wish the contract to be renewed, and make sure they enter a note in your
account. This way, shoudl Bell forget to not renew it, there will be a
note that you legally regested the contract to not be renewed.
Some Guy
> Some Guy wrote:
>
> > Bell/Sympatico doesn't allow you to configure the rDNS of your
> > static IP - does TekSavvy?
>
> Yes. This is one of the big advantages of Teksavvy. It lets you
> have a decent SMTP server with the stuff remote SMTP servers
> expect you to have.
How does TekSavvy allow you to set / change your rDNS? Web interface?
Phone call to a tech?
Being able to set your rDNS is nice, but NOT necessary to run your own
SMTP server. There is really NO advantage in having your own local
machine be the out-bound MTA vs using your ISP's out-going MTA.
Sid Elbow
>> Since we signed a 3 year contract, I think I have a
>> short window around the time the contract ends to cancel the service or
>> Bell gets to auto-renew it (yes?).
>
> You can (or should) be able to signal to Bell in advance that you do not
> wish the contract to be renewed, and make sure they enter a note in your
> account. This way, shoudl Bell forget to not renew it, there will be a
> note that you legally regested the contract to not be renewed.
Don't know about Bell but that's not how it works with Direct Energy
furnace & A/C maintenance contracts in Ontario. If you want to cancel
you have the small window (3 weeks before contract-end to one week after
if I recall) and they won't even discuss it outside that window.
The whole point seems to be to take advantage of the customer's general
forgetfulness as a way of sucker-ing them into a contract renewal. I
would bet that Bell operates the same way.
I think the operative phrase is "legally requested" ... Bell would claim
that a legal request for cancellation can only take place within the
window as stated in the contract (if indeed such a window is specified).
JF Mezei
> How does TekSavvy allow you to set / change your rDNS? Web interface?
> Phone call to a tech?
Email to their dns administrator with all the details. (username is
dnsadmin, domain is teksavvy.com )
> Being able to set your rDNS is nice, but NOT necessary to run your own
> SMTP server. There is really NO advantage in having your own local
> machine be the out-bound MTA vs using your ISP's out-going MTA.
The advantage of running your own outbound is that you have logs of when
the message was really sent.
This is important when you have domains like hotmail that accept emails
and then never deliver them to recipients (not even their spam folder).
Having a log that shows that the message was formally accepted by hotmail.
Some Guy
> The advantage of running your own outbound is that you have logs
> of when the message was really sent.
Depending on your software, I suppose you could configure your server to
be the out-bound MTA for local users, and then have it hand off all
messages to the ISP's out-bound MTA. You'd have your logs in that case.
> This is important when you have domains like hotmail that accept
> emails and then never deliver them to recipients (not even their
> spam folder). Having a log that shows that the message was
> formally accepted by hotmail.
How does having a log showing that hotmail accepted the mail also mean
the message was delivered?
You just said that hotmail *will* accept a piece of mail and then not
deliver it anywhere. If so, why would you trust a log entry on your own
box saying that hotmail accepted the message? What good is such a log
entry?
Or does your ISP's out-bound MTA not relay error messages back to the
sender?
In any case, I've never seen that sort of behavior. If the address is
non-existant, or over-quota, then we get a message back from hotmail (or
where-ever) saying so.
JF Mezei
> How does having a log showing that hotmail accepted the mail also mean
> the message was delivered?
You can use the log entry to give your correspondant the proof that the
problem is not with you but is with Hotmail.
AKA: I sent the message, Hotmail took official responsability for it
(with the final 2xx message accepting the message) and is is not my
fault if Hotmail canned it.
Madonna
> Don't know about Bell but that's not how it works with Direct Energy
> furnace & A/C maintenance contracts in Ontario. If you want to cancel
> you have the small window (3 weeks before contract-end to one week after
> if I recall) and they won't even discuss it outside that window.
>
> The whole point seems to be to take advantage of the customer's general
> forgetfulness as a way of sucker-ing them into a contract renewal. I
> would bet that Bell operates the same way.
>
> I think the operative phrase is "legally requested" ... Bell would claim
> that a legal request for cancellation can only take place within the
> window as stated in the contract (if indeed such a window is specified).
If you cancel the credit card that they charge to. They quickly cancel
your service even when you are outside the window...
BTW Bell doesn't really respect its contracts. Not even with its retailers:
http://www.radio-canada.ca/nouvelles/Economie-Affaires/2008/10/21/002-bell-guerre-detaillants.shtml
Some Guy
> > How does having a log showing that hotmail accepted the mail
> > also mean the message was delivered?
>
> You can use the log entry to give your correspondant the proof
> that the problem is not with you but is with Hotmail.
A largely useless excercise. The correspondant wouldn't know what
you're talking about, or what to do with that "proof", and hotmail
wouldn't care.
It's still not an important-enough reason against using your ISP's
out-bound MTA (even if your ISP forces you).
Madonna
> JF Mezei wrote:
>
>>> How does having a log showing that hotmail accepted the mail
>>> also mean the message was delivered?
>> You can use the log entry to give your correspondant the proof
>> that the problem is not with you but is with Hotmail.
>
> A largely useless excercise. The correspondant wouldn't know what
> you're talking about, or what to do with that "proof", and hotmail
> wouldn't care.
Of course it's important to know what happens to email. Once the problem
is known the person can switch to GMail or something else for important mail.
Geoffrey Welsh
> We've had Bell (Sympatico) Business internet (6-meg, with single
> static IP) for the past 3 years.
>
> We operate our own SMTP (and http) server. Absolutely no problems for
> incoming mail to our domain.
You know what's funny? For the past week, since our long arguments with
Bell, this customer hasn't had a single glitch! I know because I've set up
our monitoring system to send an email through our mail exchanger (in our
rack at a hosting center) into his mail server (at his site) and POP it back
out every few minutes. Not only has no mail failed to make that loop since I
set up the monitor a week ago, the mail exchanger long hasn't included the
phrase "connection timed out" even once since then! Up until just over a
week ago, it would go into periods of inability to connect multiple times per
day, sometimes within minutes of my changing the sender's IP address or the
TCP listening port.
> Initially, our SMTP server was both our in-coming and out-going MTA,
> but we quickly found that some recipient MTA's were rejecting our mail
> because of the rDNS lookup on our IP (seems they don't like seeing
> "ppp" in the rDNS, perhaps among other things).
I think it more likely that the IP was listed as dynamic in blacklists such
as the PBL (<http://www.spamhaus.org/pbl/index.lasso>)
> Bell/Sympatico doesn't allow you to configure the rDNS of your static
> IP - does TekSavvy?
Another funny thing - the customer's 'static' IP address - which we were told
we couldn't have a reverse DNS name for - already has a custom name
associated with it, apparently from a previous customer!
--
Geoffrey Welsh <Geoffrey [dot] Welsh [at] bigfoot [dot] com>
Some Guy
> > but we quickly found that some recipient MTA's were rejecting our
> > mail because of the rDNS lookup on our IP (seems they don't like
> > seeing "ppp" in the rDNS, perhaps among other things).
>
> I think it more likely that the IP was listed as dynamic in
> blacklists
We actually got message-rejected notices stating that the presence of
"PPP" in the reverse lookup was the reason.
As far as RBL rejections go, we get a few of those per year because
Sympatico's servers are on some lists, and some organizations (like a
handful of European universities) use them.
The most obtuse e-mail system we've encountered is operated by U-Penn.
You get an e-mail notification telling you that an e-mail was sent to
you from one of their users. You then have to log into their web
interface to read it.
> > Bell/Sympatico doesn't allow you to configure the rDNS of
> > your static IP
>
> Another funny thing - the customer's 'static' IP address - which
> we were told we couldn't have a reverse DNS name for - already
> has a custom name associated with it, apparently from a previous
> customer!
Are you sure the customer has a *static* IP, vs a dedicated IP?
What is the /16 IP address of the customer?
Geoffrey Welsh
> Geoffrey Welsh wrote:
>> I think it more likely that the IP was listed as dynamic in
>> blacklists
>
> We actually got message-rejected notices stating that the presence of
> "PPP" in the reverse lookup was the reason.
Lol! I guess it's up to the recipient organization to decide what to base
their blocking on. I have one customer who uses an application developed and
hosted in Germany; I was laughing at the silliness of those who blocked
e-mail from Germany until I saw one SMTP message that said something like
"you're listed in de.countries.nerd.dk; we don't accept mail from Denmark"
I've heard of a U.S. company that bought a Canadian company and pissed off a
customer by rejecting email from an employee (of the customer) named Amir
because it 'sounded Arabic.'
> As far as RBL rejections go, we get a few of those per year because
> Sympatico's servers are on some lists, and some organizations (like a
> handful of European universities) use them.
I strongly discourage people from using user-driven (e.g. SpamCop) or
spamtrap-driven RBLs specifically because it's too easy to get legitimate
outbound gateways listed.
> The most obtuse e-mail system we've encountered is operated by U-Penn.
> You get an e-mail notification telling you that an e-mail was sent to
> you from one of their users. You then have to log into their web
> interface to read it.
Now that's just rude.
But, then again, challenge/response systems are common and they're rude, too.
>> Another funny thing - the customer's 'static' IP address - which
>> we were told we couldn't have a reverse DNS name for - already
>> has a custom name associated with it, apparently from a previous
>> customer!
>
> Are you sure the customer has a *static* IP, vs a dedicated IP?
Bell was very insistent that the customer had a "static dynamic" IP (a
reservation of sorts, from a dynamic pool) and not a dedicated IP (which I
suppose would come with a higher end service that might include a router and
multiple routable IPs.)
> What is the /16 IP address of the customer?