This Blog Is Not For Reading

A blog, just like any blog, only more so

  • Subscribe

  • Categories

  • RSS Bob Jonkman’s Microblog

    • New comment by bobjonkman 29 November 2022
      @clacke Our #KWNPSA user group chatted with the #GetTogether developer a few months ago. He said demand for self-hosted G2G instances was minimal, and event interchange even more minimal. So #ActivityPub support on G2G has stalled, and he considers G2G more or less stable and mature.
    • New comment by bobjonkman 28 November 2022
      @lnxw48a1 ...then to Debian with a MATE desktop in 2020. Far less faffing about, finally being productive. Sometimes...
    • Delete 28 November 2022
      Bob Jonkman deleted notice {{tag:gs.jonkman.ca,2022-11-28:noticeId=1106500:objectType=comment}}.
    • New comment by bobjonkman 28 November 2022
      @lnxw48a1 I switched to Ubuntu-MATE when they insisted in the Unity desktop, then to Debiab
    • New comment by bobjonkman 28 November 2022
      @lnxw48a1 Ubuntu 22.04 has way too much reliance on snaps. Can't even get a regular install of Firefox, f'rinstance, only a snap.
    • Delete 28 November 2022
      Bob Jonkman deleted notice {{tag:gs.jonkman.ca,2022-11-28:noticeId=1106496:objectType=comment}}.
    • Favorite 12 November 2022
      bobjonkman favorited something by lnxw48a1: Oh, look! Evan has his own #Mastodon server now. https://prodromou.pub/@evan
    • bobjonkman repeated a notice by lnxw48a1 12 November 2022
      RT @lnxw48a1 Oh, look! Evan has his own #Mastodon server now. https://prodromou.pub/@evan
    • New note by bobjonkman 30 September 2022
      That "aura" around bright objects is what I saw when I first got a cataract (clouding of the lens). It wasn't bad at first, and only in one eye, so I let it go until my vision was totally obscured in that eye. Don't do that. Get your eyes checked, and maybe a referral to […]
    • Favorite 30 September 2022
      bobjonkman favorited something by hypolite: Ok, that’s what I thought, thank you for the explanations. When I wear the new glasses, anything beyond a couple of feet is doubled until my eyes adjust which takes more time than with my current glasses, and then it still is almost imperceptibly blurry, although the comparison between the […]

Archive for the 'smtp' Category

Telephone Number Format Standards

Posted by Bob Jonkman on 20th March 2010

Telephone Dial

Standardized Telephone Number formats work even on old phones!

There are many different address books and directories online, and there are almost just as many different ways they store telephone numbers. I guess most people don’t realize that there are actually standards for representing phone numbers. A little bit of standardization would go a long way towards interoperability.

The standard for phone number formatting is set by the International Telecommunication Union in [E.123] and [E.164] (see the references below). The standards documents are available for a fee from the ITU [available at no charge since 2010 –Bob.] . A summary is available in the Google (UseNet) discussion group, titled Need ITU-T E.123 summary.

In short, a North American telephone number should look like:

+C-AAA-PPP-NNNN;ext=xxxx

  • “+” shows where the dialing prefix goes. This is one of either the International Direct Dialing (IDD) prefix (for Canada this is “011” for overseas dialing) or the National Direct Dialing (NDD) prefix (“1” for calls within North America, omitted for toll-free calls),
  • “C” is the Country Code (North America’s CC is “1”, and it is omitted for dialing within North America),
  • “AAA” is the area code (always required for dialing in Kitchener, Toronto, and other jurisdictions),
  • “PPP” is the Exchange (or Private Branch Exchange “PBX”; look in the phone book to see which exchanges are supported),
  • “NNNN” is the local portion of the number,
  • “;ext=” optionally identifies the next portion as an extension and “xxxx” are the digits for that extension. This syntax is usable in URIs and e-mail.

Note that the sequence “AAA-PPP-NNNN” is called a “local number” and “+C-AAA-PPP-NNNN” is called a “global number”. The “-” (hyphen) is a visual separator, as are “.” (period) , “(” (left bracket) and “)” (right bracket), which dialing applications should ignore.

I’m mostly interested in making phone number formats in e-mail addressbooks compliant with e-mail standards. The document that covers this is the IETF’s [RFC3191], "Minimal GSTN address format in Internet Mail" . The requirement is that GSTN (Global Switched Telephone Network) numbers use the global-number syntax (“+C-AAA-PPP-NNNN”).

Global-number GSTN numbers can be used for other purposes as well, such as Web page URIs. See [RFC3966], "The tel URI for Telephone Numbers". This document re-iterates that:

5.1.4.
Global Numbers Globally unique numbers are identified by the leading “+” character. Global numbers MUST be composed with the country (CC) and national (NSN) numbers as specified in E.123 [E.123] and E.164 [E.164]. Globally unique numbers are unambiguous everywhere in the world and SHOULD be used.
5.1.5.

Local Numbers Local numbers are unique only within a certain geographical area or a certain part of the telephone network, e.g., a private branch exchange (PBX), a state or province, a particular local exchange carrier, or a particular country. URIs with local phone numbers should only appear in environments where all local entities can successfully set up the call by passing the number to the dialling software. Digits needed for accessing an outside line, for example, are not included in local numbers. Local numbers SHOULD NOT be used unless there is no way to represent the number as a global number.

Local numbers SHOULD NOT be used for several reasons. Local numbers require that the originator and recipient are configured appropriately so that they can insert and recognize the correct context descriptors. Since there is no algorithm to pick the same descriptor independently, labelling numbers with their context increases the chances of misconfiguration so that valid identifiers are rejected by mistake. The algorithm to select descriptors was chosen so that accidental collisions would be rare, but they cannot be ruled out.

If you work at a company that does work with organizations and staff members outside of the context of your area code (ie. internationally) be sure to standardize your directory on global-number syntax.

–Bob.

Need a consultant? Bob Jonkman can be reached by telephone at +1-519-635-9413

References:

Image: Telephone Dial by Leo Reynolds, used under Creative Commons v2.0 BY-NC-SA.

Posted in code, smtp, telephone, valid html | 4 Comments »

Blocking port 25 considered harmful

Posted by Bob Jonkman on 10th December 2008

Coffee cup with a broken handle on a cluttered desk

Coffeine abuse by maciekbor

Over in the Teksavvy Forum at DSLReports Rocky Gaudrault, the owner of my ISP, Teksavvy, started a discussion on blocking port 25 entitled “Argg…. UCEPROTECT… very frustrating!“. This is my reply:

Two cents I’d like to contribute:

The UCEPROTECT service isn’t blocking e-mail, it merely provides an opinion on an IP’s reputation as a mail server. Technically, this opinion is expressed with a DNSBL.

When mail doesn’t get delivered, it’s the receiving mail server that blocks it, not UCEPROTECT. The recipient may reject the mail based on the opinion of the DNSBL, but if that DNSBL gives bogus information then the recipient will be blocking legitimate mail. The fault is with the mail recipient for choosing a poor DNSBL. It’s not Teksavvy customers who can’t send e-mail, it’s the recipients who are refusing to accept it.

Even if Teksavvy did block port 25, there’s no guarantee that poor DNSBL services would whitelist Teksavvy’s servers. DNSBLs are run at the whim of their operators, and they can blacklist anything they like. The people who use these services need to understand that they’re letting someone else decide what mail they can receive, completely out of their control.

Port blocking is ineffective as a spam fighting technique — ISPs started port blocking in 2001, but if port blocking is so good, why is there still spam? Most spam still comes from disreputable bulk mailers running large-scale operations. Remember the McColo servers from a few weeks ago? When that one operation was shut down there were reports that spam volumes dropped by 30%. To fight spam, concentrate on the large-scale spammers.

There are lots of spambots running on poorly protected home computers, but that’s a symptom of poor security. Blocking port 25 won’t fix the security problem. To fight poor security it’s far better to identify the compromised computers, and provide them with tech support to fix the problem. Teksavvy is in a better position to do that than any other service provider I know.

There is no benefit to Teksavvy customers in blocking port 25 — It doesn’t protect Teksavvy customers from spam. It might protect other ISP’s customers from Teksavvy spammers, but it also denies Teksavvy customers full access to the Internet. Full, unblocked access is one of the main differentiators that Teksavvy brings to the market. Don’t give that up, Rocky.

Blocking ports also prevents legitimate services. ESMTP extensions like DSN rely on a direct connection to transfer Delivery Status Notifications. If a relay server doesn’t implement DSN then status notifications don’t get through. If port blocking is turned on, the smart host providing the relay service had better implement every ESMTP extension that exists. And that could still block other services that rely on unfettered access to port 25 (iMIP anyone?)

Blocking one port today is the thin edge of the wedge to blocking other services. Already I’ve seen requests for blocking ports 137 and other Netbios ports. If Teksavvy starts port blocking then every time there’s a new vulnerability the Teksavvy execs will need to agonize over whether to block or not. DNS is broken? Block port 53. There’s child porn on Usenet? Block port 119. CRIA threatens to shut down encrypted filesharing? Block port 443. If Teksavvy has a policy of no port blocking, all these decisions are moot.

I left Rogers because of port blocking, and came to Teksavvy because of unfettered access. Please don’t take that away.

–Bob.


Coffeine Abuse by maciekbor is used under a CC-BYCreative Commons Attribution license.

Posted in considered harmful, dnsbl, dslreports, port blocking, smtp, teksavvy | 7 Comments »

 
Better Tag Cloud