On Fri 11/Nov/2022 12:42:26 +0100 Laura Atkins wrote:
On 11 Nov 2022, at 11:33, Alessandro Vesely <ves...@tana.it> wrote:
On Fri 11/Nov/2022 10:23:44 +0100 Laura Atkins wrote:
On 11 Nov 2022, at 05:04, Scott Kitterman <skl...@kitterman.com> wrote:
[...]
For those that have been around for awhile this reminds me of the now long dead
controversy about closing open relays. It's not identical, but I think it
rhymes.
Back in the mists of the early Internet we didn't have submission services
because any client could send email via (most) any MTA, so they weren't needed.
As you can imagine, spamming was incredibly easy and the community gradually
came around to the point that you can't just relay email for anyone, an MTA
should serve authorized users (I oversimplify here). As this consensus was
being developed, a substantial number of MTA operators objected. Eventually,
being an open relay meant no one would take mail from you.
This seems similar.
I was around for the open relay discussions and I don’t see the parallels.
I do.
Going to a mailbox provider (MP[*]), obtain an email address, and send a
message from it is paralleled to going to an open relay and send a message
through it. The only differences are (1) the From: domain is constrained by
the MP, and (2) the MP requires me to interact with their web server in order
to setup an address. They both seem negligible to me.
The MP limits the volume of messages that a user can send out. However, by signing even one message, it takes the responsibility for its content.
This appears to be the disconnect. The MP takes responsibility for the
*MESSAGE* - that message, sent to that user.
Indeed, identifying the message transport is the functionality we're thinking
to retrofit into DKIM.
After all, DKIM was designed to allow discernment based on domain name rather
than IP address. No surprise that someone can abuse a domain name through
different IP addresses. A hasty and imprudent signature could easily cause
risks.
Now, why does the MP take responsibility for unknown content?
They don’t. They take responsibility for the message.
Actually, they do. They might have thought to control message transport, while
in fact their control terminates when the message leaves their premises.
If we extend the open relays parallel, we'd forecast that allowing anonymous
users to freely setup (hundreds of) email addresses has to come to an end. Do
MPs know the people they provide email services to? If they do, they can
afford the risk to put their reputation in their hands.
IOW, the simple solution is that free MPs send messages unsigned except for
people they trust.
Just so I’m clear what you’re suggesting, what I’m hearing you say is that from
Google, Yahoo, and Microsoft should be sent without a DKIM signature in the
absence of some proof of identity for the sender?
Well, I don't dare suggesting it, because I'm unaware of the business model
that free mailbox providers have in mind. I know some (non-free) MPs know
their users personally. For them, signing shouldn't be a problem, because
traitorous users would be expunged and never accepted again. That way, the
user/ provider relationship works both ways. Are there reports of replay
attacks by known users?
Anyway, yes, you understand me right. I'm not suggesting, I'm forecasting.
[*] Previous messages use ESP, which I tend to associate to operators like
Mailchimp, say, rather than Gmail. I had a hard time trying to understand why
ESPs would let folks send a single opt-in message... Is it me?
Why wouldn’t they? I sent myself a test message to make sure it was right
before triggering the send to a larger list (and, BTW, Mailchimp actually
limits the number of tests you can do). It’s basic QA.
Were you really talking about ESPs? I thought ESPs identify their (paying)
customers. If I replay Mailchimp signature they could sue me, couldn't they?
That's one of the reasons I asked for some kind of report. I /imagine/ replay
attacks go through free MPs signatures, because it looks like the easiest way.
Best
Ale
--
_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
