[sheikheddy]

Yo I’m not even gonna apologize about this, it would be so wack if we didn’t do that:

a) if a mail sever looks like it’s gonna send spam, then you gotta block it. I personally have philosophical hang ups about this, like it’d be wrong to sentence someone to prison for crimes they didn’t commit just because a system added up some points and made a prediction with high confidence, but in real life, you absolutely need to be proactive. b) there is literally no way to do this that wont immediately get abused. Trust me we’ve tried. We make it nearly impossible to get unlocked on purpose because if it was easy, then it’d be like 1 innocent person using it and 99 attackers due to the adversarial incentive structures.

Now ofc there’s more nuance here, we really do want to get it wrong less often, and you do pay us so it’s not fair to blame it all on the bad guys, so I’m grateful for the feedback but I think you should give me even more detailed feedback since there’s not much I can do except give a vague high level explanation unless you help me by being specific.

[Dunedan]

Thanks for responding, really appreciated.

> made a prediction with high confidence

Do you somehow track the amount of false positives these predictions generate? How do you tune the prediction to not generate too many false positives?

> but in real life, you absolutely need to be proactive

Why is Microsoft the only provider who needs to do such proactive blocking? Why don't you need to do that for email addresses associated with Office 365?

> I think you should give me even more detailed feedback since there’s not much I can do except give a vague high level explanation unless you help me by being specific.

My story is very much the same as for everybody else having the same trouble, including the person whose blog post sparked this discussion: A root server for personal use located in the data center of a mid-sized hoster, running a mail server as part of its duties. In my case the whole mail setup runs on IP-addresses separate from everything else. Mail volume to Microsoft would probably be on average 1-2 emails per month. No issues whatsoever getting emails delivered to other mail providers, only to Microsoft. This whole setup is in place since several years.

[Avamander]

> Why is Microsoft the only provider who needs to do such proactive blocking? Why don't you need to do that for email addresses associated with Office 365?

They're not.

[currysausage]

The way you implement this, low-volume senders (nerdy individuals or small projects that can't use SES/Mailgun/… for GDPR reasons), even if they manage to get off the list once (olcsupport.office.com, escalate), never get the chance to build up reputation in the long term (I'd have to contact olcsupport again in a few months and that's just not sustainable for a small-time postmaster).

I get it, you're afraid that some VPS from a cheap cloud provider suddenly floods the inboxes of thousands of Outlook.com customers. I realize that a fresh IP that sends dozens of emails out of the blue has to be blacklisted.

But why don't you allow my VPS to send, say, 16 emails a day to Outlook.com inboxes? And if ⅛ of the recipients report junk, I get blacklisted. But if all 16 recipients are happy, my IP can now send 16+16=32 emails/day for the next few months (as long as the non-ISP hostname matches; otherwise, it might be a new VPS customer), and so on.

This way, your customers are happy (I don't think spammers rent/hack a fresh VPS in order to send 16 emails, and I don't think they are very good at building up IP reputation), and I'm happy (my personal VPS can send a few emails to my Outlook.com contacts every few weeks/months, and my project VPS can gradually build up and maintain the reputation it needs).

I'm obviously being naive about that approach, but I don't remember having trouble reaching Gmail inboxes or those of local providers, and at least for Gmail, I know that they have pretty effective spam filtering too, so I reckon that they use some approach like the one I described.

For a side project, I have just given up contacting olcsupport and instruct Postfix to send through our @outlook.com address instead, but that is a wobbly workaround at best. For personal email, I now relay through SMTP2GO because GDPR doesn't matter that much, but it makes me sad to have that gaping hole (called Outlook.com) in my decentralized email fantasy, after having spent so much time researching, configuring, diagnosing.

[Avamander]

> I'm obviously being naive about that approach, but I don't remember having trouble reaching Gmail inboxes or those of local providers, and at least for Gmail

There are plenty of those who do have such issues with Gmail.

The simple reason behind all this is that spammers also have near endless patience. If it takes sending 15 emails per day per IP, they'll do it. If it's a criteria you can figure out as a legitimate user, the spammer can as well. They'll "subtract one" and bypass it.

So the end result is that there's intentional fog over the methods. Just things you can try and get right and maybe that's sufficient. Eventually the good side tends to prevail, with some effort. Other than that it's one of the hardest problems out there with insane weight on both sides.