On 8/7/21 2:11 am, Alessandro Vesely via dmarc-discuss wrote:
> A mailbox provider is only one of the service providers that an organisation
> might contract to send email on its behalf. Other common examples include:
>
> * Marketing automation (list management, sending mailouts, analytics)
> * CRMs, where sellers use the CRM itself to send messages to their customers
> * Subscription management systems that send expiry reminders
> * Helpdesk systems that send responses to user requests
>
> There are dozens or hundreds of less common examples.
I see. I note that the examples you mention, except some kind of marketing,
need to receive mail, besides sending it. Indeed, being bidirectional is a
peculiar email characteristics. So, if a service can be integrated with a mail
system,
There's either no requirement for reception by the service provider (CRM
case, subscription management case), or the level of "integration" is
just an email alias (helpdesk case). Adding an account, maintaining
credentials, etc. is implementation friction which those service
providers avoid wherever they can.
then it should be able to use its incoming as well as outgoing servers.
What someone/something else "should" do is not relevant in a DMARC
discussion. The should-based engineering approaches to this problem of
~15 years ago were difficult, contentious, and ineffective. One of key
realisations in DMARC was that the lower the burden on domain
registrants (i.e. the lower the adoption friction), the more widespread
implementation will be. DMARC succeeds in large part because it avoids
all avoidable friction for the least-engineering-savvy participants: the
domain registrants, no matter how untidy the resulting engineering looks.
While there is some engineering appeal in the argument that you're
making, it's overwhelmed by the importance of widespread adoption. As in
many other contexts, systems that gain adoption are those which address
the world as it is, not as it "should" be.
Otherwise, it deserves using its own subdomain.
"Deserves" is even less relevant than "should". In any event, you're
proposing exposing an implementation artefact to end-users, which is not
even sound engineering.
Most likely, technology-impaired companies don't even host their own DNS. The
DNS providers who do that for them should have an adequate level of expertise,
though.
...
The list of DNS providers seems to have grown quite a bit since the last time I
checked. Freeing customers from SPF pains could be an element of distinction.
This is an interesting idea. If the market for it is real then your
fortune awaits :-)
I would point out that DNS-content services of this type are quite rare.
About the only mass-market examples that I can think of are:
* DNSSEC key rotation, integrated with domain registrar services
* DNS-based delivery optimisation (i.e. not IP anycast), integrated
with CDNs
* CloudFlare's proxying domain-root A records to permit aliasing the
root while not breaking DNS (by putting CNAMEs alongside NSs, which
they did for some time).
It's really quite rare, and generally only arises as an essential part
of the related service. I'd hazard a guess that the amount of additional
revenue that can be obtained through implementing and offering such
services more generally doesn't warrant the effort.
- Roland
_______________________________________________
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss
NOTE: Participating in this list means you agree to the DMARC Note Well terms
(http://www.dmarc.org/note_well.html)
