Skype-in Telephone Numbers no longer accept Toll Free SIP "From" or P-Asserted-Identity - sip

FACTS
For the past seven years, I've made outbound calls via SIP. Calls have a SIP From header with a standard (non-toll) telephone number, and a P-Asserted-Identity header (PAI) with a name and a toll-free number. The caller ID display at the destination shows the name and toll-free number (if supported by the phone and service provider, of course).
In recent days this scheme has stopped working for Skype-in numbers.
DISCUSSION
Starting approximately 2018-01-22, I've seen a jump in calls rejected with SIP 408 messages.
My SIP termination provider says that most of the calls were rejected upstream of Level 3. Our internal checks of the problem lead us to believe that the rejected calls are for the most part to Skype-in telephone numbers.
I've tried multiple tests with various formats of the PAI and the From. Using the abbreviations TFN for "toll-free number," here's a list of what I've tried:
From with non-TFN, PAI with sip: TFN and name (which has worked for seven years)
From with TFN and name, PAI with sip: TFN and name
From with non-TFN and name, PAI with sip: TFN and name
From with non-TFN and name, PAI with sip: TFN and no name
From TFN with name, no PAI
From non-TFN and name, tel: PAI TFN with no name
From TFN and name; tel: PAI TFN with name
and a few more besides. Regards of the format of the PAI (TFN, non-TFN, name or not, tel: or sip: format) and regardless of the format of the From (with or without name, TFN or non-TFN) -- if either From or PAI contain a toll-free number, the call is rejected with a SIP 408 or an occasional SIP 403.
My SIP termination provider does not know how to solve the problem. Questions from my SIP termination provider to upstream carriers have not yielded a solution.
I speculate that Skype is deliberately blocking TFNs from calling Skype-in numbers for reasons I don't understand. At present (2018-01-31) Skype-in will cheerfully display any non-TFN number I send in the PAI without checking to see if I own it or not, which implies that this not a general security measure (e.g., an anti-swatting measure).
ACTION
My questions are:
Is this a well-known, recent problem?
What is the solution to terminating at Skype-in numbers while sending a name and a toll-free number?

The solution to this problem turns out to be quite straightforward: somewhere past my SIP provider and past Level 3, there's a deliberate block of the specific toll-free number ("non-toll DID") we have been using.
At a colleague's suggestion, I tried different toll-free numbers under our control in the PAI, and they all worked. As a sanity check, and since PAI's are never (in my experience) checked for validity, I found I was able to successfully call using invalid numbers, e.g., 1 800 111 2222.
I therefore conclude that the problem is the specific number we're sending in the PAI. I'm in touch with my SIP provider; now the hunt is on to find out who is blocking that number.
EDIT
After a conversation with Skype, our number did start working again... but while I did get "This is an issue were [sic] working to fix," I was never able to find out the scope of the problem: our number specifically, groups of numbers, and which Skype-in numbers were blocked.
Regardless, Skype support, reached via answers.microsoft.com, did resolve the problem.

Related

Why is the DATA in SMTP not null terminated?

I was reading the original RPC about the SMTP Protocol and came across this section:
SMTP indicates the end of the
mail data by sending a line containing only a period.
Why did Postel decide to use the period as the terminator? Would it not be easier to use the already existing null terminator?
I see, that he would not want the users content to interfere with the protocol, but I would naively assume, that a user is more likely to use a period in one line than a null terminator?
Added to that, would the implementation of the mail client not just cut of the text if the user came to use the null terminator his mail contents?
IMHO: SMTP has be designed long time ago to be human readable/writable.
It is pretty simple to test (send simple SMTP messages) typing them by hand via telnet program.
"Human readable" makes null terminator a suboptimal choice.
EMSMTP design is a fossil of pre-spam era. It is bad (by current standards) but it is so widely implemented and sufficiently good (after fixes) to make any quick revolution "not sufficiently urgent".
Extra info: Seen RFC 3030 for BDAT alternative to DATA command.

What does X-Sender-Id mean in email raw source (Found in phishing email)?

Somebody in my company is being subject to phishing. My first suggestion was just to change the password. However after awhile I received a fake mail from her address again.
Looking at the raw source of the email I found that there is another person's email in X-Sender-ID and I'm wondering who that might be. Is that the person who sent the email or can it be an account that has been hijacked? (I replaced the email with "somebody#host.com")
X-Virus-Scanned: OK
Received: by smtp5.relay.iad3a.emailsrvr.com (Authenticated sender: somebody-AT-host.com) with ESMTPA id DF2788019C;
Fri, 21 Nov 2014 07:54:42 -0500 (EST)
X-Sender-Id: somebody#host.com
Received: from smtp.emailsrvr.com ([UNAVAILABLE]. [2.133.148.211])
by 0.0.0.0:587 (trex/5.3.2);
Fri, 21 Nov 2014 12:54:46 GMT
What is X-Sender-ID? And what is the email it contains?
My deliberations are based on this RFC which describes the Privacy Enhancement for Emails which you are obviously using.
Basically it says about the X-Sender-ID:
[...] encapsulated header field, required for all
privacy-enhanced messages, identifies a message's sender and provides
the sender's IK identification component.
What does this mean?
First of all you have to check if the mail is properly signed. If thats the case you can be sure that somebody#host.com has a certificate. And you can be sure that the mail you received has been sent from this mail address.
I can't tell you the consequences which result out of this fact as I don't know how your company is deploying the certificates etc. ... the mail address/certificate could also have been hacked and thereby abused.
I hope this helps you for your further research.
While #LMF's answer is useful technical information, I'd like to offer a possible alternative explanation.
Spammers who are not familiar with e-mail (and PHP programmers with no other malicious intent) tend to succumb to cargo cult programming when it comes to email headers. In other words, if there is something they don't understand, they might think it does something useful, and include it in their message template.
Without knowledge about your email infrastructure, or other messages of yours to compare to, I would simply assume everything below the top-most Received: header is forged, and basically without meaning.
If you have a system which runs something called trex (maybe this one?) and it really manages to write a Received: header like that, I might be wrong. The format needlessly deviates from the de-facto standard Sendmail template in a few places, but it's not technically wrong (the format is basically free-form, but introducing ad-hoc syntax makes it harder to guess what the fields mean).
Again, more information about what your typical email (and your correspondent's typical mail) looks like, this is heavy on speculation.
The x-sender-id, along with the x-recipient-id are used to specify which interchange key was used in the broadcast of the message.
X-Sender-ID entity_id : issuing_authority : version
X-Recipient-ID entity_id : issuing_authority : version
The first field contains the identity of the sender or receiver. The first field is mandatory, must be unique, and must be formatted as user#host whereas the host is a fully qualified host address.
The second identifies the name of the authority which issued the interchange key.
The third field specifies the specific type of interchange key which was used. This is represented by an alphanumeric string defined by the issuing authority to label and organize the numerous interchange keys issued by that authority. It is recommmended that they use a timestamp but is not always the case.
If the field values of the x-sender-id second and third field are identical to that of the x-recipient-id they may be only listed in the field which is defined last.
Further Reading
"Distributed Computing & Cryptography: Proceedings of a DIMACS Workshop"

How can I be sure an email address is unique?

There's a pub in my town whereby, if you sign up to their newsletter using their website and provide a "unique" email address, you get a free drink. On a whim, I decided to sign up a second time using myemail+one#gmail.com. It let me. I'm now sitting on a nice comfy pile of free drink vouchers.
This got me thinking about a system we have here, where the email address is considered the unique identifier. Checking the code, sure enough, if we were offering vouchers in our business, someone else would be sitting pretty.
The basic, stab-in-the-dark, fix is to check for the "+" character and ignore everything after it (up to the #), and compare using that. But I am unsure if this was the intent for the + character. Would that work?
Secondly, are there any other caveats that would allow a user to sign up multiple times with a seemingly different email address, but which actually would always end up in the same mailbox?
This question is language-agnostic.
While using a plus sign as an e-mail address alias is a known feature of gmail, other mailers do either not allow it or use a minus sign instead. '+' is a legitimate character to be used as part of an email address according to the RFC.
The use of '.' is also a gray area. john.doe#gmail.com and johndoe#gmail.com send also both to the same email address and look different.
In order to validate the uniqueness of an email address you will have to prepare a rule base for your application, keep it up to date and still expect surprises...

P-Asserted-Identity vs history info

I'm newbie in SIP field. So, please forgive if there is old/easy questions.
Please take a basic call-flow as below to analysis.
phone A -- calls -- phone B -- (transfer to ) -- phone C
A, B, C are extension on same PBX.
Question 1. So, in INVITE message, the History-info will contain:
At B
`History-info : <sip: user A #domain.com>`
At C:
`History-info : <sip: user A #domain.com>`
`History-info : <sip: user B #domain.com>`
`History-info : <sip: user C #domain.com>`
Question 2. And, the PAI header will generate in INVITE message of C
and the format is :
P-Asserted-Identity: <sip:user A #domain;user=phone>.
Question 3. I just want to know when does 2 SIP headers: History-info and P-Asserted-Identity (PAI) occur in SIP message ? and which case ?
Question 4. The difference between 2 SIP headers above and the purpose of them. Are they generated on INVITE message or others ?
Please help me make these concerns clearly.
Q1: Not sure what the question is, but if all UAs (extensions) are sending the calls through the PBX, the PBX may add the History-info fields in any request not associated with an established dialog (INVITE, REGISTER, MESSAGE, REFER and OPTIONS, PUBLISH, SUBSCRIBE, ..)
Q2: The PAI field should be set with the identity of the calling party, which is still extension A for internal calls. In another scenario, like A is calling B and B is redirected to an outside line, the PAI might be overwritten by the PBX with B's outbound number before the call is sent through the external SIP trunk.
Q3: History-info (RFC4244) is an application specific header field, not always present and most commonly injected by your PBX for internal reasons (checking routing, detecting redirect loops, charging, etc). Being an optional field, its availability and purpose in extensions may vary.
PAI field (RFC3325) contains the identity of the caller.
Q4: Q3 explains the difference between them, PAI holds the identity while histinfo fields are holding the indexed tracking of SIP URIs through which the message passed and any additional info.
PAI can appear in INVITE/OPTIONS/SUBSCRIBE/NOTIFY, for histinfo see Q1.

Is it possible to include comments inside a non email host name?

I am working on a more complete email validator in java and came across an interesting ability to embed comments within an email both in the "username" and "address" portions.
The following snippet from http://www.dominicsayers.com/isemail/ has this to say about comments within an email.
Comments are text surrounded by parentheses (like these). These are OK but don't form part of the address. In other words mail sent to first.last#example.com will go to the same place as first(a).last(b)#example(c).com(d). Strange but true.
Do emails like this really exist ?
Is it possible to form hosts like this ?
I tried entering an url such as "google(ignore).com" but firefox and some other browsers failed and i was wondering is this because its it wrong or is it because they dont know about host name comments ?
That syntax -- comments within an addr-spec -- was indeed permissible by the original email RFC, RFC 822. However, the placement of comments like you'd like to use them was deprecated when that RFC was revised by RFC 2822... 10 years ago. It's still marked as obsolete in the current version, RFC 5322. There's no good excuse for emitting anything using that syntax.
Address parsers are supposed to be backwards-compatible in order to cover all conceivable cases, including 10-years-deprecated bits like the one you're trying to take advantage of here. But I'll bet that many, many receiving mail agents will fail to properly parse out those comments. So even though you may have technically found a loophole via the "obsolete addressing" section of the RFC, it's not likely to do you much good in practice.
As for HTTP, the syntax rules aren't the same as email syntax rules. As you're seeing, the comment section from RFC 822 isn't applicable.
Just because you can do it in the spec, doesn't mean that you should. For example, Gmail will not accept that comment format for address.
Second, (to your last point), paren-comments being allowed in email addresses doesn't mean that they work for URLs.
Finally, my advice: I'd tailor the completeness of your validator to your requirements. If you're writing a new MTA (mail transfer agent), you'll probably have to do it all. If you're writing a validator for a user input, keep it simple:
look for one #,
make sure you have stuff before (username) and after (domain name),
make sure you have a "dot" in the hostname string,
[extra credit] do a DNS lookup of the hostname to make sure it resolves.