Hi Kaspar,
On Sun 23/May/2021 15:16:57 +0200 Kaspar Etter wrote:
I wasn’t subscribed to the IETF SMTP mailing list when you wrote
https://mailarchive.ietf.org/arch/msg/ietf-smtp/Lqfwg9DfaxmYAv_S5WGiOPsJFCw/.
Since I’m too lazy to compose this followup message manually, I can’t continue
the conversation on the mailing list, and so I decided to write to you personally.
As the discussion is fully non-personal, I think you don't mind if I CC the
list.
One thing is the definition of /email service provider/. The wikipedia article
you link to is correctly named /Mailbox provider/. A number of people consider
ESPs a different kind of business. Others, especially foreigners, don't grok
that.
I don’t like the term “mailbox provider” because these companies provide much
more than just a mailbox, namely email submission and delivery, spam
prevention, and message filtering with Sieve or some other interface. For me,
email service provider is a suitable equivalent to Internet service provider
(ISP). Do you think of Mailgun, SendGrid, Postmark, etc. when you hear “email
service provider”? I called them SMTP service providers or email delivery
vendors in the box about reputation
(https://explained-from-first-principles.com/email/#reputation).
Hm... /email delivery vendor/ sounds interesting. Unfortunately, ESP is well
established already (among the people who knows what that is).
Mailbox provider was told me by JD Falk when I was caught in the same trap:
https://web.archive.org/web/20100613121358/http://mipassoc.org/pipermail/abuse-feedback-report/2009q3/000360.html
Even if MPs offer many more services, mailboxes are associated with email
addresses, which are the most noteworthy elements of visibility.
An alternative name is MSP (without 'E'), defined in email arch. as:
Transit: Mail Service Providers (MSPs) that offer value-added
capabilities for Edge ADMDs, such as aggregation and
filtering.
I'd note that the author's email address is usually considered more private
than the (temporary) IP address used for submission. Yet, in this respect,
protocols are not clear about what submitters are allowed to put in the
From:/MAIL FROM addresses. Even if the SMTP operator DKIM signs From: and
restricts MAIL FROM by SPF, it is not formally required to check those values.
I’m not sure what you wanted to get at, but I responded to Bron on the mailing
list.
Traditional email software allows to tinker with originator data, in part for
the sake to grant anonymity. Some providers restrict it, but no RFC require
them to be valid.
Did you find clients that execute Javascript?
No. Did I imply this? I tested everything I was interested in with the same few
mail clients.
No, I didn't see the topic of remote code execution in your article. However,
Javascript can be embedded inside html pages, where browsers normally execute
it. I hope email clients don't, but I don't recall feature statements in this
regard.
[CNAMEs in SPF]
OTOH, resolvers can deliver the target without requiring an extra call. And
the number of calls is the only thing an SPF verifier can/should count.
This requires the use of DNSSEC (see
https://explained-from-first-principles.com/email/#name-chaining-attacks,
but many companies use SPF without DNSSEC.
A recursive resolver doesn't have to be DNSSEC aware. A client issues a call
and looks for a TXT RR in the response. A fussy client has to explicitly look
for CNAME records in order to increase the count when it finds them. IMHO, it
makes no sense. Resolving implies additional calls issued by the resolver to
navigate any involved zone cut, and these are certainly not counted.
Neither am I. However, I'd note a couple of points:
* It's not clear who provides web hosting for MTA-STS. Is it a third role?
* Domain owner should prepare new TSLA RRs /before/ the MX operator changes
key/certificate. Failure to sync might entail a few days of blackout.
I’m not sure to whom you addressed these questions. The answer to the first
question is that it doesn’t matter (from the perspective of the standard).
While not important for users, a web server is not necessarily part of an email
hosting contract. In various circumstances, the web site operator is an extra
party, which requires coordination with both the mail operator and the domain
owner.
And the beauty of TLSA records is that the MX operator maintains them. All I
have to do as a domain owner is to deploy/enable DNSSEC on my domain.
You're right. I assumed the TLSA record was not a CNAME. I guess you mean:
_25._tcp.my-domain.example. IN CNAME _25._tcp.MX-operator.example.
Best
Ale
--
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp