Snipping a bunch. > On 11 Nov 2022, at 05:04, Scott Kitterman <skl...@kitterman.com> wrote: > >>> >>> >>> 2) The messages often have two different To: lines >>> >>> This violates RFC 5322, so it would be easy to filter these out, except >>> that we would need to know how common and tolerated this is today among >>> legitimate messages. >> The other (more common?) case is that the original recipient is in the >> signed 822.To, while the new recipient is not in the To: or Cc: headers at >> all. While that’s just the same as old-school alias forwarding, and you >> might not be able to spot that on any given single email I’d bet that it’s >> easy to spot and block at a mailbox provider of any size. >> >> A heuristic I’ve suggested previously is “If the recipient’s email address >> is not in the To: or Cc: header then treat the mail as unsigned”. > > Which is a fancy way of making DKIM only work for direct mail flows.
I don’t understand this. > I've been thinking some more about this and mentally I'm swinging back more > towards the system is working as designed, don't mess with it. > > If an ESP is willing to take on a trial customer they know nothing about and > let them send email leveraging the reputation of the ESP's domain, why is it > wrong that it suffers when that does not end well. It’s One Message - sent to an address that has given permission to receive that message. What I hear you saying is tha ESPs that allow single messages sent to opt-in addresses deserve to have their domain reputation abused. Is this a correct summary of your argument? If it is, I guess we are at a standoff because I don’t think ESPs who are mostly doing the right thing (ie, letting folks send opt-in messages) deserve to have their reputation trashed by senders who are actually unwelcome (and know they’re unwelcome) on the ESPs platform. > It is a fundamental precept of DKIM that when a domain signs an email, they > are taking responsibility for it (See the RFC 6376 introduction and more > specifically 2.5 and 2.6). It's further reinforced by a note in 5.1 that > begins: > >> INFORMATIVE NOTE: A Signer can be implemented as part of any >> portion of the mail system as deemed appropriate, including an >> MUA, a SUBMISSION server, or an MTA. Wherever implemented, >> Signers should beware of signing (and thereby asserting >> responsibility for) messages that may be problematic. > > I've yet to see any proposed problem that can be resolved without disrupting > legitimate mail flows or standing the 5321/5322 architectural division on its > head. I know it when I see it isn't a sufficient definition. Isn’t that what the whole working group is exploring? Can we address this in any meaningful manner? You seem to want to have the discussion before we charter it, rather thn > My more cynical side sees this issue as senders trying to offload more work > on > receivers even though it's work that the sender is explicitly responsible for. The senders are doing their work. They are not permitting the mail to go through their systems. They’re only sending opt-in mail through their systems. T > 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 can imagine the market solving this. If there are two ESPs and one is > careful about who is allowed to send mail signed by their domain and the > other > is not, I suspect that eventually superior reputation will result in superior > deliverability, which should result in being able to charge more for a > premium > service. What abuse problem has “the market” ever solved? Abuse (and other community problems) are solved by people taking action. Not by some magic wand of capitalism choosing ’the right’ answer. > As a receiver, if I have access to a quantitative reputation scoring system > for IP addresses and domains, I might counter this, in the meantime, by > looking for mail from IP addresses with statistically significantly worse > reputation than the reputation of the domain and treat those messages more > suspiciously. I don't know that I would spend effort on special signature > decoding mechanisms that are inherently risky for false positives. But are you representative? > Although not in scope for this discussion, SPF can have similar issues when > ESPs are not sufficiently careful about what email they let out from their > servers with their domain in Mail From, so this isn't a DKIM unique issue. This is what makes me think you’re not understanding the actual issue here. It is a DKIM unique issue. The ESPs can see, control and manage the mail using their servers. They will block, shut off and otherwise disrupt the flow of spam coming out of their system. In the case we’re discussing here, the message isn’t going out through their system, so they have no control. > Ultimately, I don't think senders should DKIM sign mail they aren't willing > to > take responsibility for, since that's exactly what a DKIM signature is > supposed to signify. They took responsibility for the single opt-in message that was sent through their system. I’m not sure they have any responsibility for the million copies of the message the recipient sends through a different infrastructure. Unless you’re saying that DKIM signatures should only be assigned to mail that has been manually reviewed by the infrastructure host? laura -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog
_______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
