[gerdesj]

It doesn't actually verify it, all it can do is read it. Just like email. When the PBX is told that the caller is say 01460223344 (I'm in the UK) then it would infer that the caller is from Crewkerne in Somerset due to the 01460 which is a designated area code. It may also be able to look up the whole number and infer a source.

However, just like email the CLID can be trivially faked and just like email, the lookup in your contacts is then wrong and potentially dangerous. In the case of telephony, if you subscribe to the BT service (I presume it still exists) that will return a name given a CLID (just like DNS for a price!) then you may end up with completely the wrong thing on your display.

Just to re-iterate the point: a PBX/phone/whatever cannot ... CANNOT ... verify CLID (Calling Line IDentification) it can only show what is presented to it.

Remember this, please: CLID is nominally under the control of the caller and could also be changed in transit. It should absolutely NOT be considered authoritative in any way.

[wlesieutre]

It's not quite "Just like email" because email has systems in place to authenticate this, while phone systems do not.

https://en.wikipedia.org/wiki/DMARC

[gerdesj]

Have you ever tried to implement DMARC? DKIM and SPF are OK but DMARC breaks mail lists. Yes there are ways to mitigate but it might not be worth it unless you also do DNSSEC as well. Well actually I believe that every little helps and use every weapon available.

I do think that the analogy works really well. PBXs can have quite a few weapons of their own to attempt to authenticate callers. For example you can pass "anonymous" calls to a dialplan that gets the caller to identify themselves and then play that to the recipient who then gets to allow/disallow the call - basically make the (human) recipient part of the firewall. Also, PBXs that deal with VoIP can use IP rules just like a firewall to make decisions on what to do.

Traditionally, "telephony" and "systems" have been considered separate. Personally I'm a sysadmin AND telephony bod with around 25/15 (respectively) years experience. My PBXs (generally Asterisk with FreePBX) have quite a few sources of intelligence about what is inbound, beyond CLID. I also look after quite a few email systems, often fronted by an Exim MTA with an attendant rspamd or spamassassin (int al).

[GangcaiLin]

There is a new standard called Authenticated Received Chain (ARC) designed specifically to address the DMARC authentication failure issue caused by mailing lists. Basically what ARC does is to preserve SPF/DKIM authentication results, and use them to override DMARC authentication result when deemed appropriate. There is a Quora post here for a more detailed explanation: https://www.quora.com/What-is-Authenticated-Received-Chain-A....

[wlesieutre]

I haven't set it up, but how does it break mail lists? Do you mean like using third party providers to send emails with your own domain in the From address?

[toast0]

It is (or was) common for mailing lists to keep the From header when forwarding mail to a list. The envelope sender is commonly changed to refer to the mailing list for bounce processing, and often a mailing list footer is added, sometimes the subject is adjusted and other administrative headers are added.

Changing the subject or adding a footer will almost always break the DKIM signature, and DMARC won't like it anyway, because the From address and the envelope sender don't have the same domain (alignment). This makes it pretty hard to use DMARC for a public domain.

It's not so bad to use it for a corporate domain, and it helps a bunch if your domain is being used to source phishing; except that people still think you sent it when it comes from [e-mail] which is clearly some ancient web mailer script that was compromised 20 years ago, but still remains online. (I'm totally not bitter!)

[technion]

My domain, lolware.net, has a total of three email accounts. I'm usually happy to move and break things because it's largely a personal playground. For example, my website's SSL ciphers have frequently veered into the "not many browsers support" solutions.

I cannot properly enable DMARC. I have working SPF and DKIM on everything I send, but as soon as I enforce it, people stop getting my email. The sticking points are mailing lists, and anyone with a forwarder. I've been on this merry go round a few times. If it's this bad on this personal domain, I'm a long way from considering it in a business.