Subject: Musing on SIP and SPAM

From: Michael Thomas <[email-masked]>
Date: Fri, 24 Apr 2020 15:07:41 -0700

Ok, into the fray. I've written a couple of blog posts on the subject 
which go into more detail of what I've been thinking. Basically, after 
much searching through the STIR/SHAKEN stuff I finally figured out that 
sip:[email-masked] was out of scope. And I mean, it took me a *long* time 
figure that out reading problem statements, requirements, etc. What my 
blog post wonders about is whether STIR/SHAKEN is solving the wrong 
problem. That is, it's trying to solve the e.164 spoofing problem via 
tel: uri and sip: uri's with embedded telephone numbers. This is an 
incredibly complex and fraught problem, so i have to ask whether it's 
even worth it? Telephony is pretty much all SIP these days, even to 
mobile phones with SIPoLTE, there's not much point to stick with e.164 
addresses as identifiers if it's SIP end to end or SIP end to almost the 
end with POTS termination. Since STIR/SHAKEN can't do much of anything 
with actual PSTN onramp/offramp based spam, it makes me wonder why we 
are holding onto mostly dead technology's vestiges. The future seems to 
me that a sip:[email-masked] URI would be the future, but the did not 
solve for that. It's not like people *like* e.164 based identity, and 
mostly it's hidden from you on mobile phones anyway. Being one of the 
authors of DKIM (rfc 4871, etc) it has always occurred to me that 
something DKIM-like could work for SIP and actually hacked a version of 
my DKIM code to prove the point on a SIP stack in about 2005.

https://rip-van-webble.blogspot.com/2020/02/sip-what-about-from-header-no-love.html

Now being the dutiful engineer that I am, I decided to have an argument 
with myself and ask whether we both (STIR/SHAKEN and SIP-DKIM) are 
wrong. That is, is telephony as we know it essentially dying. The Covid 
pandemic has really put that into focus with services like Zoom in the 
limelight which as far as I know doesn't use SIP. Maybe none of them 
have an inter-provider problem like the PSTN does. So maybe the right 
solution is to do nothing, or do just the STIR/SHAKEN stuff because 
"Something Must Be Done".

https://rip-van-webble.blogspot.com/2020/04/on-second-thought-sip-security.html

Mike

PS: hi all, long time! missed y'all and hope you're keeping safe :)

---

From: Keith Moore <[email-masked]>
Date: Fri, 24 Apr 2020 23:18:50 -0400

On 4/24/20 6:07 PM, Michael Thomas wrote:

> Now being the dutiful engineer that I am, I decided to have an 
> argument with myself and ask whether we both (STIR/SHAKEN and 
> SIP-DKIM) are wrong. That is, is telephony as we know it essentially 
> dying. The Covid pandemic has really put that into focus with services 
> like Zoom in the limelight which as far as I know doesn't use SIP. 
> Maybe none of them have an inter-provider problem like the PSTN does.

IMO the fragmentation of video call services is a disaster.   I 
certainly hope that single-provider solutions aren't the future of video 
calling.

Keith

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 25 Apr 2020 17:31:30 +0900

Michael Thomas wrote:

> Telephony is pretty much all SIP these days, even to 
> end with POTS termination.

I abandoned SIP, when it was tried to be used for telephony, which
means already complex protocol will be even more complex trying
to be compatible with PSTN, even though it was obvious that
PSTN was dying.

> The Covid 
> limelight which as far as I know doesn't use SIP.

SIP was complex because it was designed assuming multicast
multiparty multimedia conferencing applications, available
at the time it was first developed, in mind and became even
more complex trying to be compatible with PSTN.

As Zoom does not need most of complications of SIP, should
need its own extensions and should work with http(s), it is
natural that totally new protocol is developed.

Designing a new protocol for your application is not very
difficult, unless you want to standardize it in IETF.

						Masataka Ohta

---

From: Mukund Sivaraman <[email-masked]>
Date: Sat, 25 Apr 2020 14:10:27 +0530

> difficult, unless you want to standardize it in IETF.

:-)

---

From: Michael Thomas <[email-masked]>
Date: Sat, 25 Apr 2020 08:26:23 -0700

On 4/24/20 8:18 PM, Keith Moore wrote:
>> dying. The Covid pandemic has really put that into focus with 
>> services like Zoom in the limelight which as far as I know doesn't 
>> use SIP. Maybe none of them have an inter-provider problem like the 
>> PSTN does.
>
> certainly hope that single-provider solutions aren't the future of 
> video calling.
>
Do the unwashed masses use anything that supports inter-provider like 
xmpp or sip for texting? As far as I can tell that ship sailed ages ago 
with facebook, whatsapp and all of the rest. Video is pretty hopeless 
because if it requires mixing, somebody has to pay for the mixing in the 
backend and there is about zero interest to set up inter-provider 
settlement. Unless this sort of thing is mandated by government, I can't 
imagine what would change that.

Mike

---

From: Keith Moore <[email-masked]>
Date: Sat, 25 Apr 2020 14:24:09 -0400

On 4/25/20 11:26 AM, Michael Thomas wrote:

> xmpp or sip for texting? As far as I can tell that ship sailed ages 
> ago with facebook, whatsapp and all of the rest.

I'm always amused when people insist that the future of the Internet 
will inherently be like the present.  So far, at least, it hasn't worked 
out that way.

Keith

---

From: Michael Thomas <[email-masked]>
Date: Sat, 25 Apr 2020 12:01:32 -0700

On 4/25/20 11:24 AM, Keith Moore wrote:
> will inherently be like the present.  So far, at least, it hasn't 
> worked out that way.
>
>
In fact as I wrote in my blog post, this could easily change if 
governments force it to change  for their own reasons. Thus far it has 
not, and the rumblings are just rumblings. But the desire for 
concentration to build natural monopolies and the rent-seeking that 
enables is just as much now as it ever were.

Mike

---

From: Dave Cridland <[email-masked]>
Date: Mon, 27 Apr 2020 09:32:58 +0100

On Sat, 25 Apr 2020 at 16:26, Michael Thomas <[email-masked]> wrote:

> with facebook, whatsapp and all of the rest.

Well, WhatsApp, Zoom, and various others are either XMPP or a bastard child
of it, but no, few of them choose to enable any kind of inter-provider (ie,
federation). But that's not a technical limitation, it's a business one.

Dave.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 27 Apr 2020 07:25:59 -0700

On 4/27/20 1:32 AM, Dave Cridland wrote:
>
>
> On Sat, 25 Apr 2020 at 16:26, Michael Thomas <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> Well, WhatsApp, Zoom, and various others are either XMPP or a bastard 
> child of it, but no, few of them choose to enable any kind of 
> inter-provider (ie, federation). But that's not a technical 
> limitation, it's a business one.
>
Yeah, I just noticed that Zoom claims to use SIP poking around. The 
question is not whether it's SIP per se, but whether there will be 
inter-carrier anything. If there is inter-carrier, then the problem will 
remain, especially when it traverses an intermediary proxy.

Mike

---

From: Dave Cridland <[email-masked]>
Date: Mon, 27 Apr 2020 15:28:59 +0100

On Mon, 27 Apr 2020 at 15:25, Michael Thomas <[email-masked]> wrote:

> inter-provider (ie, federation). But that's not a technical limitation,
> it's a business one.
>

Zoom interoperate with SIP, I think. But they used to interop via XMPP as
well, and I believe they use XMPP internally. They stopped external interop
with XMPP when Google and Facebook ceased to use it, I think.

Dave.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 27 Apr 2020 07:33:56 -0700

On 4/27/20 7:28 AM, Dave Cridland wrote:
>
>
> On Mon, 27 Apr 2020 at 15:25, Michael Thomas <[email-masked] 
>>     Well, WhatsApp, Zoom, and various others are either XMPP or a
>>     bastard child of it, but no, few of them choose to enable any
>>     kind of inter-provider (ie, federation). But that's not a
>>     technical limitation, it's a business one.
>>
>     Yeah, I just noticed that Zoom claims to use SIP poking around.
>     The question is not whether it's SIP per se, but whether there
>     will be inter-carrier anything. If there is inter-carrier, then
>     the problem will remain, especially when it traverses an
>     intermediary proxy.
>
>
> Zoom interoperate with SIP, I think. But they used to interop via XMPP 
> as well, and I believe they use XMPP internally. They stopped 
> external interop with XMPP when Google and Facebook ceased to use 
> it, I think.
>
Ok, that probably what I was seeing. I wasn't actually setting out to 
see if they used SIP :)

Mike

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 27 Apr 2020 11:13:30 -0400

(Don't have an answer, but a question or three)

On Mon, Apr 27, 2020 at 10:34 AM Michael Thomas <[email-masked]> wrote:
>> Yeah, I just noticed that Zoom claims to use SIP poking around. The question is not whether it's SIP per se, but whether there will be inter-carrier anything. If there is inter-carrier, then the problem will remain, especially when it traverses an intermediary proxy.
>
>
> Zoom interoperate with SIP, I think. But they used to interop via XMPP as well, and I believe they use XMPP internally. They stopped external interop with XMPP when Google and Facebook ceased to use it, I think.
>
> Ok, that probably what I was seeing. I wasn't actually setting out to see if they used SIP :)

So, if you setup a service (zoom, for your example here) and you
'guarantee' to your users that the path is encrypted (for instance),
and you enable federation in the XMPP sense, how do you keep your
guarantee?

repeat with gtalk or facebook-chat or aol-instant-messenger...

For the shaken/stir conversation what's the actual problem trying to be solved?
I thought; "Did the person I see calling me actually make this call?"
or perhaps: "Is the identity I see really the identity that initiated
the call?"

---

From: Michael Thomas <[email-masked]>
Date: Mon, 27 Apr 2020 10:09:00 -0700

> and you enable federation in the XMPP sense, how do you keep your
You can't unless the payload itself is encrypted with keys known by each 
end user. That's what my guess is going on with Whatsapp, but I know 
nothing about it.
> or perhaps: "Is the identity I see really the identity that initiated

It's is exclusively trying to bind an e.164 address(range) -- either 
directly from a tel: uri, or harvested from a sip: uri -- to the carrier 
to whom it is delegated. I haven't read enough of the documents to 
understand exactly how they are doing that, but one trip through SS7 
land breaks any end to end traceability so I'm sort of dubious how well 
this will work in practice. Scammers are not dumb, after all.

Which is why I think it's solving the wrong problem. At least with 
email, DKIM and widespread adoption of SMTP-auth gives you a pretty 
reasonable expectation that if it says that it came from gmail, it 
actually came from a person with access to that gmail account (legit or 
otherwise). It would be nice to have a similar level of confidence for 
non-e.164 address sip: uris were they to become popular for some reason.

Mike

---

From: Dave Cridland <[email-masked]>
Date: Mon, 27 Apr 2020 18:48:52 +0100

On Mon, 27 Apr 2020 at 18:08, Michael Thomas <[email-masked]> wrote:

> as well, and I believe they use XMPP internally. They stopped external
> interop with XMPP when Google and Facebook ceased to use it, I think.
> >>

Well, WhatsApp is bastard-son-of-XMPP, and has end-to-end cryptography
based on the Signal ratchet, with key distribution based on
trust-on-first-use. But it's also single-provider, so the question isn't
really answered.

But normal XMPP works the same way as email, really - I can be assured that
my connection to my server is encrypted. If I trust my provider, I can
accept their assertion that their connection to the other party's server is
also encrypted, and finally if I trust that provider I can accept that the
other party's server session will be encrypted. To get more provable than
that, we need to perform end-to-end encryption of some form (OMEMO -
another Signal variant - or in the future MLS), and then do some kind of
identity key verification to assure the endpoints.

[I accept we may be seeing an alarming amount of topic drift here].

But to get somewhat back on topic, this is only signalling - if you can
establish media, then that can prove the endpoint as well, and that has an
entirely different encryption path - and "all" you need to do there is pass
a signed [derivative of the] [public] key through the [untrusted]
signalling path, I'd have thought. Assuming you can use PKIX to do the
heavy lifting here, that seems like a reasonable start to cryptographically
provable caller identity.

> non-e.164 address sip: uris were they to become popular for some reason.

For identity verification on XMPP, I trust my server and in turn it can
prove the remote domain, and beyond that trust (or not) that domain's
servers not to lie about the user identity within that domain. On SIP, like
email, I understand it to be more complicated, because the path is not
nearly as constrained as it is with XMPP, but fundamentally with DKIM etc
you are proving the provider's identity (ie, the domain) and not that of
the end user. That may well be enough in most cases, but it's somewhat
reliant on having a few providers with much to lose.

But again, what we can do relatively easily is prove the endpoints of the
RTP security - we might be able to do that prior to accepting media, along
the signalling path, but the worst case is that we establish media in order
to get a cryptographically established caller (or responder) identity.

Dave.

---

From: Richard Shockey <[email-masked]>
Date: Mon, 27 Apr 2020 13:53:48 -0400

Actually the US Government is trying to mandate interoperable video calling.

https://www.fcc.gov/fcc-announces-membership-nanc-interoperable-video-calling-working-group

— 
Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP Forum

www.shockey.us

www.sipforum.org

richard<at>shockey.us

Skype-Linkedin-Facebook –Twitter  rshockey101

PSTN +1 703-593-2683

On 4/25/20, 11:26 AM, "ietf on behalf of Michael Thomas" <[email-masked] on behalf of [email-masked]> wrote:

    Mike

---

From: Richard Shockey <[email-masked]>
Date: Mon, 27 Apr 2020 13:57:36 -0400

BTW Apple FaceTime is definitely SIP, however it uses a proprietary REGISTER function.

From: ietf <[email-masked]> on behalf of Michael Thomas <[email-masked]>
Date: Monday, April 27, 2020 at 10:33 AM
To: Dave Cridland <[email-masked]>
Cc: "[email-masked] Discussion" <[email-masked]>
Subject: Re: Musing on SIP and SPAM

 

 

Well, WhatsApp, Zoom, and various others are either XMPP or a bastard child of it, but no, few of them choose to enable any kind of inter-provider (ie, federation). But that's not a technical limitation, it's a business one.

Mike

---

From: Mukund Sivaraman <[email-masked]>
Date: Mon, 27 Apr 2020 23:29:16 +0530

> and you enable federation in the XMPP sense, how do you keep your

XMPP has features such as OTR and OMEMO, that provide end-to-end
encryption, with some effort on the user's part needed to verify.

https://en.wikipedia.org/wiki/Off-the-Record_Messaging
https://en.wikipedia.org/wiki/OMEMO

There were news reports recently that Zoom was not end-to-end
encrypted. And WhatsApp and Signal's end-to-end encryption also need
some effort from users to verify (authenticate) keys.

On the topic, as a long time user of Jabber/XMPP, XMPP support was good
in the instant messaging space soon after it was introduced. Proprietary
messaging apps surpassed it with ease of use and multi-media
messaging. WhatsApp, though late to the IM space, took off due to how it
used mobile phone numbers as identity and provided a way to add pictures
into the conversation. It had a functional minimal interface that just
worked. It is still mostly so now even after it added mandatory
encryption and media calling features.  There's almost nothing to
configure and it just works. XMPP clients (the impementations that
followed the federated protocol) have had to catch up, and they have
stagnanted over the years one way or the other. Google Talk supported
federation and attempted to have voice calling, but it was languished
and killed. It could have developed the XMPP protocol and ecosystem into
something resembling WhatsApp. Today, Conversations is a great client
for Android. Bitlbee is a nice IRC->XMPP proxy for old school
IRC'ers. XMPP can still improve and it will survive over time over the
proprietary protocols, because it is an open protocol that supports
federation.

We still use XMPP and it works fine for us. I can't talk to my friends
and family and communicate with local businesses without using the
walled garden called WhatsApp though.

On SIP, we've had good experiences. It is possible to deploy it such
that the average employee can use it without firewall/NAT issues. The
ability to use a physical dedicated handset that doesn't keep changing
its user-interface cannot be beat. A lot of senior members of my family
dislike the "smartphone", and there's something to be learned from it.
It also doesn't help that they're so fragile and slippery to hold.

We dial numeric IDs to call people, but our company's voice system is
under our control. We use SIP over TLS, SRTP for media. It is not
end-to-end encrypted, but it's under our administration. I've attended
conferences over SIP on an Asterisk PBX for several years and it has
worked fine. Why abandon a good thing?

Zoom works well, but it is also a walled garden. It has screen sharing
which is a big attraction when conferencing with colleagues. Of all the
times I've tried Jitsi Meet as a Zoom alternative, I've not been able to
get it to work well.

I wish XMPP and SIP protocols and implementations keep evolving, add
features that other current communication systems offer, and do
well. They are open protocols, can be federated, and can be run internal
to an organization. I've had good experiences with them.

		Mukund

---

From: Michael Thomas <[email-masked]>
Date: Mon, 27 Apr 2020 11:26:29 -0700

On 4/27/20 10:48 AM, Dave Cridland wrote:
>
> For identity verification on XMPP, I trust my server and in turn it 
> can prove the remote domain, and beyond that trust (or not) that 
> domain's servers not to lie about the user identity within that domain.
One thing that I'm ignorant of is whether XMPP/SIP/SMTP use 
bidirectional authentication when using TLS server to server? But it all 
becomes moot when the signaling traverses an intermediate domain. That's 
when you need something like DKIM which is a domain-level end to end 
solution.

It occurs to me that even doing a DKIM-like solution for SIP with the 
e.164 address problem might be helpful. DKIM's main service is a 
"complain to me" one. If you take off the table anything that passes 
through a PSTN gateway which nobody can solve for, that means that 
domain level authentication would give you somebody to blame. Everybody 
did that willingly for email, but if SIP providers were recalcitrant, 
governmental persuasion could come in handy. The farther you push who to 
blame toward the originating side, the smaller number of degrees of 
freedom the scammers have. At that point, whether they have right to 
claim a given e.164 address is rather beside the point: you know the 
domain who is originating it and you can... complain. Or call the cops 
on them. Or any number of other things. The big thing that's changed in 
the last 15 years is that SIP is pretty much everywhere for legacy 
telephony which definitely wasn't the case when I hacked up a SIP stack 
and put a DKIM signature in an  INVITE.

> On SIP, like email, I understand it to be more complicated, because 
> the path is not nearly as constrained as it is with XMPP, but 
> fundamentally with DKIM etc you are proving the provider's identity 
> (ie, the domain) and not that of the end user. That may well be enough 
> in most cases, but it's somewhat reliant on having a few providers 
> with much to lose.

Yes, but SMTP-Auth closes that circle. Whether you can reliably know 
whether a domain in fact uses it consistently is another matter. In an 
out of band kind of way, you could be very certain, eg subpoenaed server 
logs, etc. I've been waiting for that shoe to drop.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 27 Apr 2020 11:42:56 -0700

> https://www.fcc.gov/fcc-announces-membership-nanc-interoperable-video-calling-working-group

Ah, interesting. Which would be the forcing function to overcome 
monopolists desire for centralization. Does this have any likelihood of 
overcoming the vested interests?

Mike

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 27 Apr 2020 15:24:07 -0400

> overcoming the vested interests?

I assume you still have a picturetel ISDN video conference deployment
in your 'workplace' then? good!
we're all set then!

---

From: Dave Cridland <[email-masked]>
Date: Mon, 27 Apr 2020 21:15:19 +0100

On Mon, 27 Apr 2020 at 19:26, Michael Thomas <[email-masked]> wrote:

> servers not to lie about the user identity within that domain.
>
> One thing that I'm ignorant of is whether XMPP/SIP/SMTP use bidirectional
> authentication when using TLS server to server? But it all becomes moot
> when the signaling traverses an intermediate domain. That's when you need
> something like DKIM which is a domain-level end to end solution.
>

XMPP differs from SMTP and SIP because there are no intermediate domains -
traffic passes from the source domain to the destination domain directly,
and in effect the concepts inherent in DKIM and SPF about authorised
senders are baked into the basic protocol.

Even without TLS, there's a dialback protocol which provides bidirectional
authentication of a server-to-server stream (although we're not allowed to
call it "authentication", and due to Reasons must only ever refer to it as
"weak identity verification").

With SMTP, not so much; we rely instead on DKIM for the weird traversal
cases.

> e.164 address problem might be helpful. DKIM's main service is a "complain
> to me" one. If you take off the table anything that passes through a PSTN
> gateway which nobody can solve for, that means that domain level
> authentication would give you somebody to blame. Everybody did that
> willingly for email, but if SIP providers were recalcitrant, governmental
> persuasion could come in handy. The farther you push who to blame toward
> the originating side, the smaller number of degrees of freedom the scammers
> have. At that point, whether they have right to claim a given e.164 address
> is rather beside the point: you know the domain who is originating it and
> you can... complain. Or call the cops on them. Or any number of other
> things. The big thing that's changed in the last 15 years is that SIP is
> pretty much everywhere for legacy telephony which definitely wasn't the
> case when I hacked up a SIP stack and put a DKIM signature in an INVITE.
>
I don't know enough SIP to be sure but it sounds convincing to me.

>
> On SIP, like email, I understand it to be more complicated, because the
> path is not nearly as constrained as it is with XMPP, but fundamentally
> with DKIM etc you are proving the provider's identity (ie, the domain) and
> not that of the end user. That may well be enough in most cases, but it's
> somewhat reliant on having a few providers with much to lose.
>
> whether a domain in fact uses it consistently is another matter. In an out
> of band kind of way, you could be very certain, eg subpoenaed server logs,
> etc. I've been waiting for that shoe to drop.
>
Yes, from a legal standpoint you can get some assurance, though that has
less effect anywhere between very small personal services and quite large
ones.

But in some technically provable manner, you really need some cryptography
to run end-to-end.

Dave.

---

From: Dave Cridland <[email-masked]>
Date: Mon, 27 Apr 2020 21:30:31 +0100

> https://en.wikipedia.org/wiki/OMEMO
For completeness:

https://xmpp.org/extensions/xep-0364.html (OTR)
https://xmpp.org/extensions/xep-0384.html (OMEMO, essentially
Signal-for-XMPP)

> messaging.
XMPP is also used very heavily in critical messaging - military tactical
chat, for example, as well as currently being used for the largest
messaging system in use in the NHS in the UK. And of course lots of games
and game systems. But none of these use "stock" clients of course, which
would be used by individuals or within companies. There's a few clients
driving consumer re-adoption (you noted Conversations, but there are a few
others), and these are in turn driving new specifications to support that
space.

If you're interested in helping XMPP in the enterprise and consumer spaces,
where it's certainly still behind proprietary solutions, then please come
and join the party at https://xmpp.org/ - the XMPP Standards Foundation is
a developer-led group of standards people, and all are very welcome.

Dave.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 27 Apr 2020 13:43:59 -0700

On 4/27/20 1:15 PM, Dave Cridland wrote:
>
> XMPP differs from SMTP and SIP because there are no intermediate 
> domains - traffic passes from the source domain to the 
> destination domain directly, and in effect the concepts inherent in 
> DKIM and SPF about authorised senders are baked into the basic protocol.

Ah, ok. Most likely the vast majority of email probably has that 
property too, but not all of it.

>     Yes, but SMTP-Auth closes that circle. Whether you can reliably
>     know whether a domain in fact uses it consistently is another
>     matter. In an out of band kind of way, you could be very certain,
>     eg subpoenaed server logs, etc. I've been waiting for that shoe to
>     drop.
>
> Yes, from a legal standpoint you can get some assurance, though that 
> has less effect anywhere between very small personal services and 
> quite large ones.
>
> But in some technically provable manner, you really need some 
> cryptography to run end-to-end.
>
>
Legal of course doesn't need to be technically provable, especially for 
civil matters where a preponderance of evidence is sufficient -- at 
least in America.

But for the average SIP spam/phishing case the user part probably 
doesn't mean much. I really have no clue who [email-masked] is, but I 
sure do want to know if irs.gov claims she's one of theirs. I definitely 
have no clue what [email-masked] is. If it's legit from irs.gov, 
I'd be very inclined to pick up the phone (although they say they never 
make unsolicited phone calls). Likewise, since I know that gphone.com 
requires authentication and signs its signalling, I can legitimately 
infer that it's at least coming from gphone and if I get spammed, I can 
complain. I doubt that spam actually originating from gmail is a very 
serious problem these days.

Mike

---

From: Adam Roach <[email-masked]>
Date: Mon, 27 Apr 2020 15:53:28 -0500

On 4/27/2020 12:09 PM, Michael Thomas wrote:
> but one trip through SS7 land breaks any end to end traceability so 
> I'm sort of dubious how well this will work in practice. Scammers are 
> not dumb, after all. 

Although the actual mechanisms aren't yet defined to a level that allows 
interoperable implementation, there's an architectural sketch of how 
this can be done in the RFC Editor's Queue: 
https://datatracker.ietf.org/doc/draft-ietf-stir-oob/

Some vendors who provide STIR/SHAKEN solutions have filled in the 
protocol gaps with their own designs, and are already offering 
implementations based on that architecture to customers [1].   The 
technique is on the FCC's radar, although they consider it too early to 
mandate solutions based on it [2].

/a

____
[1] See, for example, 
https://transnexus.com/blog/2019/fcc-filings-support-oob-stir/
[2] See bullet 7 on page 5 of 
https://docs.fcc.gov/public/attachments/DOC-362932A1.pdf

---

From: Richard Shockey <[email-masked]>
Date: Mon, 27 Apr 2020 17:04:02 -0400

On 4/27/20, 2:42 PM, "Michael Thomas" <[email-masked]> wrote:

RS>  Which set of vested interests are you talking about <snicker hurrumph>?  If it’s the service providers they really don’t care.  Believe me I've spoken to all of them about this over the years.  "There is no money in this." "It’s a pain in the <fill in the blank>" "How do I monetize this?"   The USG has several interests here and the gigantic sticking point is the Telephone Number to URI translation.  It's now a constant issue.  Not only in implementing STIR/SHAKEN but a bunch of other stuff as well.  A subject I'm intimately familiar as the former co-chair of the IETF ENUM WG that produced RFC 6116.  I've had calls.  "So Shockey do you think its time to revive the ENUM WG to add DoH to 6116?"  A: "Well you know my consulting fees." 

I'm on the FCC North Americian Numbering Counsil and have been for over 9 years.  The FCC wants video calling to assist the disabled but also to foster its initiatives in Telemedicine.  I get it. I've used it and once US Health and Human Services would allow reimbursement under Medicare  the market exploded.  Everyone is on a ZOOM kick right now, JItsi and dominance of  of Gotomeeting and Webex.  I understand the problem which is why I find this thread so amusing.  Don’t get me started on the issues with WEBRTC and the APP vs browser dominance. 

 That said the biggest proponent of video calling is actually the US Dept of Defense.  Those folks just LOVE video calling and Telepresence but when it comes forking out the bucks they would rather buy a new multi-billion dollar sub or something like that than deal with the infrastructure issues they would have to cover in both their red and black networks. 

There is some progress here. The odd thing is US efforts to kill off robocalls may actually enable ubiquitous an interoperable video calling. 

Shockey Consulting LLC

www.shockey.us

www.sipforum.org

richard<at>shockey.us

PSTN +1 703-593-2683

    Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 27 Apr 2020 14:24:10 -0700

> RS>  Which set of vested interests are you talking about <snicker hurrumph>?  If it’s the service providers they really don’t care.  Believe me I've spoken to all of them about this over the years.…
Service providers, like say Zoom? Or like Telephants? Sorry it's not 
clear from the context here to me. Obviously Zoom and Facebook couldn't 
care less about telephone numbers, so they would be the vested interests 
to not wanting to do federation, right? So maybe you're talking about 
Telephants. Are you trying to tell me that they have finally wised up to 
their fever dreams about being something other than bit providers?? If 
so, will wonders never cease.
> There is some progress here. The odd thing is US efforts to kill off robocalls may actually enable ubiquitous an interoperable video calling.
Well, but STIR/SHAKEN doesn't solve the spoofed identity for 
non-telephone sip: uri's problem (and it took me an inordinate amount of 
time to understand that). If you wanted to solve for federated video 
calling, it would be a lot better to steer well clear of old PSTN'isms 
IMO. I mean, what value does old PSTN stuff bringing to the table? 
Everything is just an IP endpoint these days. That is why I've been 
poking around with this space. It's definitely good to know that 
federation is not a dead letter. Maybe mostly dead, but that's not the 
same as all dead.  :)

Mike, channeling Miracle Max

---

From: Adam Roach <[email-masked]>
Date: Mon, 27 Apr 2020 16:45:29 -0500

On 4/27/2020 4:04 PM, Richard Shockey wrote:
> The FCC wants video calling to assist the disabled

Anyone interested in this part of the equation should take a look at the 
work the RUM working group is doing. I think the basic shape of their 
spec is pretty solid nowadays: 
https://datatracker.ietf.org/doc/draft-ietf-rum-rue/

/a

---

From: Adam Roach <[email-masked]>
Date: Mon, 27 Apr 2020 16:50:03 -0500

On 4/27/2020 4:24 PM, Michael Thomas wrote:
> non-telephone sip: uri's problem (and it took me an inordinate amount 
> of time to understand that).

I mean, the SHAKEN part is PSTN-focused, but RFC 8224 is squarely aimed 
at both non-telephone-number identities as well as telephone numbers. 
One of the key differences between it and RFC 4474 is that it very 
practically makes a distinction between the two different kind of 
identifiers.

/a

---

From: Brian Rosen <[email-masked]>
Date: Mon, 27 Apr 2020 19:11:17 -0400

Telephone numbers are actually very interesting, useful, and resilient identifiers.  Try taking your email address to a different provider.  Or your sip URI.  
Try verbalizing your sip URI so you can give it to someone without first getting something from them (and how did you get that?).  Unlikely that SIP URIs will replace telephone numbers in my lifetime.

The stir part of STIR/SHAKEN works fine on sip uris.  The SHAKEN part doesn’t, but could be extended to pretty easily.  I’m sorry you found it hard to understand.  We have a heck of a lot of deployment underway, and the dev teams don’t seem to need a lot of help, so the documents are fairly good.  I’m not close to the implementation work any more, but I think interoperability continues to be excellent.

I am heavily involved in the NANC IVC interoperable video conferencing work.  It’s very interesting, but right now it’s voluntary.  Many of the big players are participating, but there are zero commitments to deploy as yet.  We’re heading towards using new routing protocols (so Shockey doesn’t need to be “convinced” to resurrect enum).  Probably something along the lines of modern.  No one wants a new monopoly player.  There will be new IETF work coming out of IVC I think.  It has features to support all sorts of assistive devices that need some form of interpreter, but NANC won’t do any signaling work — they are the telephone number routing experts.

Brian

> On Apr 27, 2020, at 5:24 PM, Michael Thomas <[email-masked]> wrote:
> 
> 
> Service providers, like say Zoom? Or like Telephants? Sorry it's not clear from the context here to me. Obviously Zoom and Facebook couldn't care less about telephone numbers, so they would be the vested interests to not wanting to do federation, right? So maybe you're talking about Telephants. Are you trying to tell me that they have finally wised up to their fever dreams about being something other than bit providers?? If so, will wonders never cease.
>> 
> Well, but STIR/SHAKEN doesn't solve the spoofed identity for non-telephone sip: uri's problem (and it took me an inordinate amount of time to understand that). If you wanted to solve for federated video calling, it would be a lot better to steer well clear of old PSTN'isms IMO. I mean, what value does old PSTN stuff bringing to the table? Everything is just an IP endpoint these days. That is why I've been poking around with this space. It's definitely good to know that federation is not a dead letter. Maybe mostly dead, but that's not the same as all dead.  :)
>

---

From: Michael Thomas <[email-masked]>
Date: Mon, 27 Apr 2020 16:46:53 -0700

On 4/27/20 4:11 PM, Brian Rosen wrote:
> Telephone numbers are actually very interesting, useful, and resilient 
> identifiers.  Try taking your email address to a different provider. 
>  Or your sip URI.
> Try verbalizing your sip URI so you can give it to someone without 
> first getting something from them (and how did you get that?). 
>  Unlikely that SIP URIs will replace telephone numbers in my lifetime.

This doesn't seem to be a problem anywhere else. My devices hide all of 
that from me these days. Seems like a very marginal benefit.

>
> The stir part of STIR/SHAKEN works fine on sip uris.  The SHAKEN part 
> doesn’t, but could be extended to pretty easily.  I’m sorry you found 
> it hard to understand.  We have a heck of a lot of deployment 
> underway, and the dev teams don’t seem to need a lot of help, so the 
> documents are fairly good.  I’m not close to the implementation work 
> any more, but I think interoperability continues to be excellent.
We had interoperablity before we even had a working group for DKIM. 
Iirc, we had multiple interoperable versions before the working group, 
but then again it took forever to get the wg spun up.
>
> I am heavily involved in the NANC IVC interoperable video conferencing 
> work.  It’s very interesting, but right now it’s voluntary.  Many of 
> the big players are participating, but there are zero commitments to 
> deploy as yet.  We’re heading towards using new routing protocols (so 
> Shockey doesn’t need to be “convinced” to resurrect enum).  Probably 
> something along the lines of modern.  No one wants a new monopoly 
> player.  There will be new IETF work coming out of IVC I think.  It 
> has features to support all sorts of assistive devices that need some 
> form of interpreter, but NANC won’t do any signaling work — they are 
> the telephone number routing experts.
>
I'm reading rfc 8824 and I am aghast at the number of things that are 
just flat out wrong. I haven't compared notes with Crocker's last call 
comments, but I have no doubt that we share a lot of the same concerns. 
Which, manifestly, were ignored since they are still there. Some of them 
are actually pretty dangerous because they make claims that cannot work 
in reality, and where the confusion can be can be exploited.

Monopolies are a layer 8 problem. The only question is whether SIP 
conferencing will be used in the same way that email is used going 
forward completely ignoring all of the legacy bellheaded stuff. If this 
is SIP's answer to DKIM, then it missed a lot of DKIM's lessons learned.

Mike

PS: I was rather amused to see the word Bellhead used in an article in 
the Economist a couple of weeks again.

---

From: "John Levine" <[email-masked]>
Date: 28 Apr 2020 03:07:26 -0000

In article <[email-masked]>,
>property too, but not all of it.

By volume I believe that the majority of non-spam mail is sent by
third party service bureaus on behalf of clients.  They generally have
an arrangement so the bureau can put the client's DKIM signature on
the mail.

>>     Yes, but SMTP-Auth closes that circle.

Sorry, I don't know what you're referring to by SMTP-Auth.  Do you
mean authentication when connecting to a submission server?  That's
useful but there's no necessary link between the submission-time
authentication identity and anything in the mail, and an awful lot of
mail is sent in ways that don't involve a submission server.

>sure do want to know if irs.gov claims she's one of theirs. ...

Talking to some people at big telcos I get the impression that they
plan to use STIR/SHAKEN more or less the way mail systems use DKIM,
not to try to identify individuals sending message, but to develop
a repuation for inccoming message streams and to handle streams with
a lot of crud differently from streams without.

-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Mary B <[email-masked]>
Date: Tue, 28 Apr 2020 08:16:45 -0500

One comment below [MB].

Mary

> a lot of crud differently from streams without.
[MB] That's actually not the purpose of STIR/SHAKEN. STIR/SHAKEN is the
signaling with some specific semantics about the originator that gives you
more information you can use for traceback and as input to analytics.  And,
STIR/SHAKEN does identify individual telephone numbers. The processing
you're talking is the analytics post STIR/SHAKEN and STIR/SHAKEN does
identify individual telephone numbers.  Personally, I think the traceback
is of more importance so that the bad actors stop doing this.  You have to
look at the merits of STIR/SHAKEN in the context of the legislation in this
space.  And, SHAKEN is designed to ensure that only those that are valid
telephony Service Providers can be part of the ecosystem - i.e., you cannot
get a certificate unless you're registered with a central authority.
 [/MB]

---

From: Michael Thomas <[email-masked]>
Date: Tue, 28 Apr 2020 07:05:03 -0700

[for the 10th time, do not send me things privately that you don't allow 
me to reply to. as i've repeatedly warned you, i will do this every time.]

On 4/27/20 8:07 PM, John Levine wrote:
>>> destinationÂ domain directly, and in effect the concepts inherent in
Which is consistent with what I said, even if true. And this is one of 
the use cases that Jim and I wanted addressed.
> mail is sent in ways that don't involve a submission server.

Thank you for being your normal obtuse self; you know perfectly well 
what I mean.  The huge problem with RFC 8224 is that it claims that the 
receiver should be able to trust the user part of the sip: uri. That is 
not only wrong, but dangerous if the receiver actually takes that claim 
as valid and acts on it. DKIM never made any such claim and for good 
reason: it can't.

On the other hand, the use of SMTP-Auth was not especially prevalent 
back when RFC 4871 was being worked on. Who knows whether it was a 
coincidence or not, but the major email providers clamped down on user 
part spoofing around the same time by requiring SMTP-Auth. As an out of 
band thing, knowing that gmail requires SMTP-Auth for their users means 
that I could trust the user part, but it is a claim that cannot be 
asserted by gmail itself. It would have to come from a third party 
vouching for them who have the means to audit their practices or me just 
whitelisting them. To my knowledge, no such third party service exists, 
and I have never heard any clamor for such a service. That entire part 
of RFC  8224 should just be junked, along with anything that is derived 
from it.

> a lot of crud differently from streams without.
RFC 8224 goes to great lengths to provide guarantees that are either 
wrong (user part of sip: uri is authorized), or pretty close to useless 
(whether somebody has the right to assert a given e.164 address). I 
really don't much care about the latter because at worst all it is doing 
is wasting people's time. The former shows that they clearly did not pay 
any attention to the lessons of DKIM and made dumb mistakes.

The main part of enlightenment I've had is how hard it was been to get 
to the bottom of the unspoken assumptions of STIR/SHAKEN. People can 
poo-poo me all they like, but I had no involvement, but have a good 
understanding of the problem space. That it has taken me this long to 
know what was in and out of scope -- with lots of other people confused 
as well -- is not a good look. Working groups are insular things, and it 
is a constant battle to keep that in mind.

Mike

---

From: Richard Shockey <[email-masked]>
Date: Tue, 28 Apr 2020 12:37:27 -0400

Indeed it is.  

— 
Richard Shockey

Shockey Consulting LLC

www.shockey.us

www.sipforum.org

richard<at>shockey.us

PSTN +1 703-593-2683

On 4/27/20, 5:45 PM, "Adam Roach" <[email-masked]> wrote:

    /a

---

From: Richard Shockey <[email-masked]>
Date: Tue, 28 Apr 2020 13:47:03 -0400

Oh Adam please don’t encourage him.  To some of us OOB STIR is the work of the Devil.  It only prolongs the agony that service providers have to convert to all IP Interconnection.   The discussion that some of us have had with the regulators is that we want them to remove the current incentives in the system for TDM/SS7 interconnection via the Intercarrier Compensation regime and positively incent service providers to move to all SIP. Of course that means there has to be some decision on the TN to URI database(s) . I'm certainly open minded on options like MODERN but in the given the time frames it narrows down to either 6116 or some hub and spoke DB like the NPAC and either of those have serious issues.  Oh and there are some <fill in the blank> that have actually suggested Hyperledger as a option. 

https://ecfsapi.fcc.gov/file/10310233413417/USTelecom%20Non-Standards%20Based%20SS%20Implementation%20Ex%20Parte%203.04.20%20-%20FINAL.pdf

— 
Richard Shockey

Shockey Consulting LLC

www.shockey.us

www.sipforum.org

richard<at>shockey.us

PSTN +1 703-593-2683

On 4/27/20, 4:53 PM, "ietf on behalf of Adam Roach" <[email-masked] on behalf of [email-masked]> wrote:

    /a

    ____
    [1] See, for example,

---

From: "John Levine" <[email-masked]>
Date: 28 Apr 2020 14:40:40 -0400

In article <[email-masked]> you write:
>what I mean. 

Thanks for your vote of confidence, but I still have no idea what you
mean by SMTP-auth.  If the client auth's on an SMTP connection it's
submission, not SMTP.

The only reputatation of SMTP clients is by IP address, generally
queried through DNSBLs.  In the other direction, clients can
authenticate SMTP servers via TLSA or MTA-STS to be sure they're
talking to the intended MX, not a middlebox.

Don't see what this has to do with SIP, other than agreeing with you
that DKIM for SIP would give us everything important that STIR/SHAKEN
do with a lot less mechanism.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 28 Apr 2020 11:47:23 -0700

> mean by SMTP-auth.  If the client auth's on an SMTP connection it's

Wikipedia doesn't seem to have a problem.

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

Mike

---

From: "John R Levine" <[email-masked]>
Date: 28 Apr 2020 14:53:22 -0400

> https://en.wikipedia.org/wiki/SMTP_Authentication

It also confirms that it's used for submission, not SMTP, so I remain 
baffled about what if any point you are trying to make.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Michael Thomas <[email-masked]>
Date: Tue, 28 Apr 2020 11:56:39 -0700

> baffled about what if any point you are trying to make.
I made no mention of what port I was referring to. It's not exactly news 
that SMTP-AUTH is gernerally used on the submission port, so likewise I 
have no idea what if any point you are trying to make.

Mike

---

From: "John R Levine" <[email-masked]>
Date: 28 Apr 2020 14:59:54 -0400

On Tue, 28 Apr 2020, Michael Thomas wrote:
> I made no mention of what port I was referring to. It's not exactly news that 
> SMTP-AUTH is gernerally used on the submission port, so likewise I have no 
> idea what if any point you are trying to make.

IF a client connects to a server on port 25, that's SMTP.  EXCEPT that if 
the client then authorizes, it turns into submission, even though it's not 
on port 587.

So-called SMTP-auth has nothing to do with identifying who might be 
responsible for an incoming SMTP message.  It's only useful for keeping 
your own users in line.

Regards,

---

From: Michael Thomas <[email-masked]>
Date: Tue, 28 Apr 2020 12:06:51 -0700

On 4/28/20 11:59 AM, John R Levine wrote:
>>> It also confirms that it's used for submission, not SMTP, so I 
>>> remain baffled about what if any point you are trying to make.
>>>
>> I made no mention of what port I was referring to. It's not exactly 
>> news that SMTP-AUTH is gernerally used on the submission port, so 
>> likewise I have no idea what if any point you are trying to make.
>
> IF a client connects to a server on port 25, that's SMTP.  EXCEPT that 
> if the client then authorizes, it turns into submission, even though 
> it's not on port 587.
>
> responsible for an incoming SMTP message.  It's only useful for 
> keeping your own users in line.
>

Which is exactly what I said. Providers policing their users was not 
widely done until around the time of DKIM. I'm dubious about any cause 
and effect, providers started to clamp down around then after years of 
doing exactly nothing.

Mike

---

From: "John R Levine" <[email-masked]>
Date: 28 Apr 2020 15:16:52 -0400

>> It's only useful for keeping your own users in line.
>
> Which is exactly what I said. Providers policing their users was not widely 
> done until around the time of DKIM. I'm dubious about any cause and effect, 
> providers started to clamp down around then after years of doing exactly 
> nothing.

Actually, the main reason SMTP AUTH is used to allow your users to send 
mail from computers off your own network without making your mail server 
an nuisance open relay.  I agree that DKIM has nothing to do with this, 
nor with tracking individual mail senders.  On my system the identity of 
the sending user is in a Received header, not the DKIM signature which I 
think is typical.

Regards,

---

From: Dave Cridland <[email-masked]>
Date: Tue, 28 Apr 2020 21:11:05 +0100

On Tue, 28 Apr 2020 at 20:00, John R Levine <[email-masked]> wrote:

> that
RFC 4954 says that it defines a service extension for SMTP, not Submission.
It does say the extension is appropriate for Submission, but makes no
suggestion that this is any kind of defining factor. Equally, RFC 6409 does
not mandate SMTP-AUTH, but does refer to it as exactly that name.

Dave.

---

From: "John R Levine" <[email-masked]>
Date: 28 Apr 2020 16:17:14 -0400

> not mandate SMTP-AUTH, but does refer to it as exactly that name.

That's what it's called, but I can promise you that in 100% of the many 
mail sytems I have looked at, if you authorize, you're doing submission.

Regards,

---

From: John C Klensin <[email-masked]>
Date: Tue, 28 Apr 2020 16:42:00 -0400

--On Tuesday, April 28, 2020 14:40 -0400 John Levine
<[email-masked]> wrote:

>...
> The only reputatation of SMTP clients is by IP address,
> generally queried through DNSBLs.  In the other direction,
> clients can authenticate SMTP servers via TLSA or MTA-STS to
> be sure they're talking to the intended MX, not a middlebox.

John,

I haven't found anything we disagree about other than what the
value is of splitting these hairs.   However, in the interest of
splitting them even further:

While I don't think it would be useful in any realistic case I
can think of, I don't think anything in RFC 4954 would prevent a
delivery-end server from advertising the extension and an
intermediate MTA relay from using it.  That would provide some
validation of (or independent of) the argument to the EHLO
command that did not depend on IP addresses.  Useful, probably
not (at least for other than intra-ADMD operations at the
receiving end) but not prohibited and certainly not restricted
to submission servers as the sending end.  On the other hand,
possibly useful for authenticating a designated lower-priority
MX server the next higher-priority one to which it is connecting
if one needed to do that.  As a possible use case, remember that
we have a very long (and important and successful) history of
associating MX records with national or enterprise gateways.
One can define those as within an ADMD by sufficient handwaving,
but for at least some cases that would imply sub-ADMDs and/or
some ADMDs being more equal than others and, in any of those
cases, present some desirability of being able to authenticate
those gateways.

An appropriately-narrow definition of "reputation of the client"
or a careful distinction between the client (MUA? Submission
server?) and the user who originated the message probably makes
"The only" in the statement above true, but it is worth
remembering that, if those distinctions are dropped, we have
mechanisms for identifying and authenticating sending users
that, btw, survive relaying (no matter what hair-splitting is
done about ADMDs).  At least AFAIK, the IETF has not yet
deprecated either OpenPGP or S/MIME.

best,
   john

---

From: "John R Levine" <[email-masked]>
Date: 28 Apr 2020 17:10:21 -0400

On Tue, 28 Apr 2020, John C Klensin wrote:
> command that did not depend on IP addresses. ...

Sure, it's easy to imagine ways one might make arrangements like that. 
Since SMTP AUTH uses SASL you're mostly limited to shared secrets with 
counterparties you already know.  (I say mostly since in principle SASL 
can use OpenID although I don't know anyone who does.)

On the third hand, in STARTTLS both sides can offer a certificate. 
Somewhere I have lying around old submission server patches that let 
clients authenticate doing STARTTLS with a cert that is signed by a 
particular CA.  It has the same problem as any other certificate, key 
distribution and management is painful, after which it works fine.  I hear 
that people do that although I don't know any directly.  Maybe Ned does.

Any SMTP client can present a certificate during STARTTLS, either signed 
by a CA or using DNSSEC and TLSA, and the server can do what it wants with 
it.  I suppose it might be useful for senders with large farms of outgoing 
mail hosts to use a shared certificate so when they switch IPs, the 
reputation stays with them.

Regards,

---

From: [email-masked]
Date: Tue, 28 Apr 2020 18:00:31 -0700 (PDT)

> mail sytems I have looked at, if you authorize, you're doing submission.

Then you haven't looked at a bunch of ours. Authenticated relay isn't routinely
done, but it's by no means unheard of, and we fully support it.

				Ned

---

From: Michael Thomas <[email-masked]>
Date: Tue, 28 Apr 2020 18:08:23 -0700

> done, but it's by no means unheard of, and we fully support it.
In other words, exonerated for moi. This entire thing was silly.

Mike

---

From: S Moonesamy <[email-masked]>
Date: Wed, 29 Apr 2020 03:03:51 -0700

Hi Dave,
At 01:11 PM 28-04-2020, Dave Cridland wrote:
>RFC 4954 says that it defines a service extension for SMTP, not 
>Submission. It does say the extension is appropriate for Submission, 
>but makes no suggestion that this is any kind of defining factor. 
>Equally, RFC 6409 does not mandate SMTP-AUTH, but does refer to it 
>as exactly that name.

The specification for SMTP AUTH is from 1999.  Section 3, Item 6 of 
the specification states that the extension is appropriate for 
SUBMIT.  RFC 6409 discusses authorized submission.  It requires 
authentication.  Given that it is an IETF specification, you probably 
know how those things get written. :-)

As DKIM was mentioned on this thread, I'll mention that it was 
introduced several years after the above occurred.  DKIM is used in 
email for "domain-level authentication".  As an example, the server 
at my end determined that your message was ietf.org.  That domain 
stated, after verification, that it received the message from cridland.net.

Last year, I attended a session in which regulators and ISPs 
discussed what is known as the spam problem.  There was a question 
about the government requesting information about the identity of the 
(message) sender.  It was being done by tracking down the IP 
address.    I had a side discussion as I was a bit puzzled about why 
it was not based on SUBMIT.

There was a comment on this thread about policing users [1].  I doubt 
that it is being done in a rigorous manner or else we would not be 
discussing spam or federation.

Regards,
S. Moonesamy

1. https://mailarchive.ietf.org/arch/msg/ietf/SIbWiyEM8q8NxQAzhkby2ZHFwJg

---

From: "John Levine" <[email-masked]>
Date: 29 Apr 2020 17:51:16 -0400

>done, but it's by no means unheard of, and we fully support it.

Yeah, I should have known I should ask you first.

Do you do it for abuse management, or just to keep private channels private?

R's,
John

---

From: [email-masked]
Date: Wed, 29 Apr 2020 15:22:12 -0700 (PDT)

> Do you do it for abuse management, or just to keep private channels private?

Mostly links between data centers across the open Internet. Nothing fancy
AFAIK: SASL PLAIN over TLS with specific certs.

But some people insist on it even inside their data centers. I wasn't even
aware of this usage until I botched a change to our configuration metafile.
Nothing like a introducing bug to tell you wnat people are actually doing with
your stuff.

			Ned