On Friday, November 11, 2022 10:09:52 AM EST Murray S. Kucherawy wrote: > On Fri, Nov 11, 2022 at 5:05 AM Scott Kitterman <skl...@kitterman.com> > > wrote: > > > 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. > > That's part of at least one of the proposals on deck. But that same > proposal talks about adding to the signal available to the receiver, not > changing or removing it. > > > 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 not always a commercial ESP. The identified attack works today if you > are a private user using a public mailbox service provider. > > > 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. > > Repeating what I said above, I think there are some ideas on the table that > seek to provide incremental information for receivers to use in these > cases. The disruption should be minimal, unless the receivers broadly get > it wrong.
The challenge is if that added information also applies equally to legitimate mail, it's merely an attractive nuisance we'd be better off not creating. > > 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. > > I think that clearly this approach could work. It's not a massive leap to > conclude that senders shouldn't sign spam, but it's also well established > that spam filters are not perfect. All an attacker needs to do is identify > some pattern the filters don't detect, and get that signed, and this attack > works despite the best efforts of the sender. > > More concerning to me: The IETF has previously taken the position that the > market will figure out spam and phishing, and therefore consideration of > protocol solutions should be deflected. DMARC was the result. I feel > that we leave this to the market, and that industry, at our own peril. I > think we should give this a serious look before rejecting it outright. I agree with this. The challenge is finding a technically tractable way to distinguish this problematic case from normal usage. I still owe the authors of the proposed solutions a more detailed study of the proposals, which I won't have bandwidth to do until at least Sunday. Scott K _______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
