[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:
In article <d020e8d0-f7ab-6bfc-b65f-250f7bf9e75e@xxxxxxxx>,
Michael Thomas <mike@xxxxxxxx> 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.
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.
Which is consistent with what I said, even if true. And this is one of
the use cases that Jim and I wanted addressed.
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.
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.
But for the average SIP spam/phishing case the user part probably
doesn't mean much. I really have no clue who gladys@xxxxxxx is, but I
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.
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
