On Friday, November 11, 2022 12:27:38 PM EST Scott Kitterman wrote: > 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: ... > > > 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.
OK. I've re-read the drafts with an eye to what we might want to consider for the charter (I have comments/feedback on all of them, but I'll save that for later). Three of the four proposed solutions (as I read them) require capturing the contents of SMTP comments in some variant of a DKIM like signature. As I've mentioned before, I think this class of solution is architecturally challenging at best. Since MTAs may have their own rules about address rewriting, I don't think a 5322 oriented process such as DKIM signing can be assumed to know specifics of 5321 identities. As a result, you would have to defer these new signature types and do them between RCPT TO and DATA. As I read the proposed charter, this is fine since the only backwards compatibility that's required is with DKIM: > Because of DKIM’s broad deployment, compatibility with existing > deployments will be a critical factor, and it is unlikely that proposals > that lack compatibility will proceed to publication. Is compatibility with DKIM sufficient for the charter or should there be broader language about compatibility with existing email architecture? I'm inclined to say "Yes", but I'm unsure about wording. Similarly, at least one of them could lead to normal indirect mail flows being identified as replay attacks. Is something specific needed about being compatible with existing email deployments more generally (beyond DKIM deployment compatibility) needed? Once agian, I'd say "Yes", but am not sure how to word it. Do these make sense? Does anyone have specific suggestions? Scott K _______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
