Re: [Ietf-dkim] Misuse of antiforgery protocols
On Mon, 12 Dec 2022, you wrote: > > Blind-carbon-copy is already a sign of spam. > > Except when it's not, like this very mailing list. Only if you don't whitelist *all* forwarders you set up and mailing lists you have joined first, overriding the Bcc filter on a match. This does mean Bcc-blocking is an anti-spam trick that most ISPs are absolutely incapable of using because they do not know their users well. But it's not the first anti-spam technique to have this problem. DCC also requires mailing list whitelisting. So does a recieverside SPF implementation that actually has an effect on deliverabilty, is correct, and not Baka. (It's Baka to give any attention to a Pass without an explicit whitelist of the sender, it is incorrect to give any attention to a Fail when you don't have a complete forwarder whitelist.) It's easy to sort wanted mail between forwards/mailing-lists and normal narrow-casted mail. Spam can masquerade as either; but if possible a spammer would want to look like narrow-casted mail as that is the only kind that could be expected to arrive from a stranger. To use this exploit, they must give that up. The way I look at it, up to now there have been two main approaches to spamming, and this trick may add a third. 1. First, the old-school chickenboner tactics where you forge everything you can get away with, and often try to exploit systems you don't own to conceal your true ISP. 2. Second, the approach that tries to exploit Baka recieverside deployments by actually buying a domain and pretending to be a newly-minted vanity domain sending narrow-casted mail with perfect SPF/DKIM/alignment credentials. The mail still is broadcast, but in one transaction per victim so it's not obvious to an automated system. 3. Finally, the new trick. It also lets you exploit the Baka, but locks you in to pretending to be a mailing list. All along, it looks to me that #2 is still pareto superior to #3 for the bad guys. Although one thing that might explain the fuss; maybe the point of sealing this hole is that the big e-mail providers would like to agree to whitelist each other in a top-down fashion without user input, rather than bottom-up whitelisting of one email address at a time by user request. If a provider was silly enough to make such an arrangement, then they could be vulnerable to #3 alone, because vanity domains (both friendly and spammer) aren't part of the cartel. Michael Deutschmann ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Rechartering
On 12/24/22 1:08 PM, Scott Kitterman wrote: On December 24, 2022 8:22:45 PM UTC, Michael Thomas wrote: On 12/23/22 10:25 PM, Murray S. Kucherawy wrote: On Fri, Dec 23, 2022 at 1:17 PM Michael Thomas wrote: Shouldn't the problem statement explore whether there is a plausible tractable solution before it moves on to protocol work? That is, if there isn't a tractable solution the wg should go into hibernation again. I'm pretty sure that I brought this quite a while ago. Of if not the problem statement, afterward just evaluating for a go-no go decision before starting any work. A working group is implicitly allowed to admit defeat if it decides it can't solve the problem it thought it was supposed to solve. DBOUND comes to mind; it deadlocked on whether the problem was tractable, or even well enough understood, to advance a consensus protocol solution, and closed without producing anything. I don't think the charter has to say that expressly. It's part of the process. The charter stipulates an ordering, and I think that's sufficient. I think it's worthwhile for the charter to have a step which is to determine whether the problem is 1) tractable and 2) requires IETF to do something. If either of those are false, the charter should say that it is completed. There has been quite a bit of skepticism expressed (and not just by me) about both of those points so it would be good to have a checkpoint before doing something to do something. +1. I think it's a mistake to assume deciding not to make protocol changes by the group is a failure. A reasoned decision that additional protocol changes would not be helpful would be a success, if that's where the facts lead us (I have opinions on this, but have reached no definitive conclusions). and write an informational RFC explaining the outcome. heck, it would probably be worthwhile to keep an ID going during that period to document the various ideas/approaches. Mike ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Rechartering
On December 24, 2022 8:22:45 PM UTC, Michael Thomas wrote: > >On 12/23/22 10:25 PM, Murray S. Kucherawy wrote: >> On Fri, Dec 23, 2022 at 1:17 PM Michael Thomas wrote: >> >> Shouldn't the problem statement explore whether there is a >> plausible tractable solution before it moves on to protocol work? >> That is, if there isn't a tractable solution the wg should go into >> hibernation again. I'm pretty sure that I brought this quite a >> while ago. Of if not the problem statement, afterward just >> evaluating for a go-no go decision before starting any work. >> >> >> A working group is implicitly allowed to admit defeat if it decides it can't >> solve the problem it thought it was supposed to solve. DBOUND comes to >> mind; it deadlocked on whether the problem was tractable, or even well >> enough understood, to advance a consensus protocol solution, and closed >> without producing anything. >> >> I don't think the charter has to say that expressly. It's part of the >> process. The charter stipulates an ordering, and I think that's sufficient. >> >I think it's worthwhile for the charter to have a step which is to determine >whether the problem is 1) tractable and 2) requires IETF to do something. If >either of those are false, the charter should say that it is completed. There >has been quite a bit of skepticism expressed (and not just by me) about both >of those points so it would be good to have a checkpoint before doing >something to do something. +1. I think it's a mistake to assume deciding not to make protocol changes by the group is a failure. A reasoned decision that additional protocol changes would not be helpful would be a success, if that's where the facts lead us (I have opinions on this, but have reached no definitive conclusions). Scott K ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Rechartering
On 12/23/22 10:25 PM, Murray S. Kucherawy wrote: On Fri, Dec 23, 2022 at 1:17 PM Michael Thomas wrote: Shouldn't the problem statement explore whether there is a plausible tractable solution before it moves on to protocol work? That is, if there isn't a tractable solution the wg should go into hibernation again. I'm pretty sure that I brought this quite a while ago. Of if not the problem statement, afterward just evaluating for a go-no go decision before starting any work. A working group is implicitly allowed to admit defeat if it decides it can't solve the problem it thought it was supposed to solve. DBOUND comes to mind; it deadlocked on whether the problem was tractable, or even well enough understood, to advance a consensus protocol solution, and closed without producing anything. I don't think the charter has to say that expressly. It's part of the process. The charter stipulates an ordering, and I think that's sufficient. I think it's worthwhile for the charter to have a step which is to determine whether the problem is 1) tractable and 2) requires IETF to do something. If either of those are false, the charter should say that it is completed. There has been quite a bit of skepticism expressed (and not just by me) about both of those points so it would be good to have a checkpoint before doing something to do something. Mike ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
