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. > 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. -MSK
_______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
