On Mon, Oct 7, 2019 at 9:50 AM Jaroslaw Rafa via mailop <mailop@mailop.org> wrote:
> Dnia 7.10.2019 o godz. 10:16:10 Brielle via mailop pisze: > > > > You do realize, some of us have been through lawsuits before because > > people like you thought that your supposed 'right' to send e-mail > > trumped our rights to the equipment/bandwidth/resources we own? > > Well, we all have right to protect ourselves from actual spammer. > But not from "someone who I think might look like a spammer". > > It's similar to self-defense when someone is attacking you on the street. > If > someone is actually attacking you, you have all the right to defend > yourself. But not if you just see someone who looks suspicious to you and > you think "he may attack me, so I attack him first". > > I'm not talking here about blocking actual spams. > I'm talking about blocking messages who are *not* spam, because the > receiving end "thinks" for some reason that the *might* be spam. > > Of course, this can always happen. > But there *should* be always a way for the *sender* to complain to the > admin > on recipient side, and, if the messages are actually mis-classified and the > sender actually isn't a spammer, the admin of the receiving server *should* > correct the configuration. > How does the receiver know you're not a spammer? Because you said so and said pretty please? How does the receiver know your machine won't be compromised tomorrow and send several million spam messages? They do know that happens at your ISP and your ISP doesn't do a great job of fixing it. > "Should" in RFC sense :) - which means it is no obligation, but it this the > best practice that should ;) be followed. > > And Google doesn't follow it. That's the actual problem. There's no way to > complain to them about the issue. The way Google finds out that a sender is valid is people marking it not-spam. We can trust (mostly, sorta, kinda) our receivers more than we can trust the senders. Plus, that's our definition of spam, it's what our receivers don't want. Also, I think if you thought about the scale involved, your opinions on what's possible may change. What level of false positives is acceptable? How many false positive messages would that entail if say you received 1B messages/day? How long would it take an admin to evaluate each fp and make a fix? How many people would that mean you'd need to hire? How many languages would your team need to speak in order to evaluate the false positives? I can say that our system thinks your netblock sends 1 out of 10000 non-spam messages. We likely don't have the accuracy to know that your messages are different enough, and you don't have the volume for us to be able to figure that out... ie, if your mail is going to spam and shouldn't, that means we're off by 0.01. Also, it's hard to optimize for the servers that send us one message a day. I've argued before that we should have better handling for the smallest servers (whitelist the first 5 messages/day for low volume IPs, for example), but the total volume compared to the effort against the major spam campaigns, it's hard to get that high enough on the priority list. We did make some changes for that for smtp time blocking, but it doesn't move any of our numbers because the number of messages affected is tiny... and when you're talking about IPv6, even small numbers like that can result in large enough holes for spam campaigns. Brandon
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
