On 2018-01-07 04:32 AM, Peter wrote: > So to put it simply, they're basically saying that their black box > thinks that your IP(s) are sending SPAM.
That's not how I read my conversation with them. My understanding based on their explanations and their advice on how to fix the problem is that their black box thinks that the content of the message sent is spam and has very little to do with the IP(s). Confirmed by their SNDS tools. > I can speculate that this might be a case of your emails somewhat > resembling emails they have seen from scammers that claim to be legal > representatives in order to further some scam or another. This is only > a guess though, I could be completely wrong here as I really don't know > anything more about Microsoft's black box than you do. Indeed we can only speculate about what triggers the blackbox. My email was just a set of boring corporate decisions in a language that I have never seen used in any scam/spam. They are neatly formatted into a PDF saved directly out of LibreOffice with a short text body, composed in Thunderbird. The only minor objectionable issue I find with my email is the GPG signatures: I sign with a key that is not associated with any email address, contrary to RFC_dont_remember_which, and I sign with an expired key (my bad: good enough for my purpose and therefore very low priority to fix). I doubt Microsoft pulls in GPG keys and verifies content signatures anyway. There is a banking resolution, so there is text in the PDF saying that the corporation has decided to open a bank account with bank X. If that triggers the content filter, it is a really picky one and whoever programmed it should be sentenced to manually read out loud Nigerian spam for eight hours straight. >> HTML format? > > Highly unlikely. Then why Microsoft's advice to "brand" and "properly format" the message? Coming from the company that has gifted the world the scourge that is HTML email, and whose view of what represent a properly format has probably been over-represented in the training sample that was fed to the neural network (just guessing) powering the filter? >> FLOSS client software and O/S? > > Also highly unlikely, I do the same and don't have issues. Also it's > all about following the SMTP protocol correctly, which has nothing to do > with whether the software used is FLOSS or proprietary or anything > in-between. On this one I tend to agree with you, for a different reason. I do not think it is about following the SMTP protocol correctly because my MTA received a 250 from their MTA on the messages and because of primary factors mentioned in Microsoft's vague description of SmartScreen's outcome being "primarily due to mail content and recipient interaction with that mail." My very wild guess is that their system mixes up correlation with causality or is skewed against exotic / seldom seen combination of the User-Agent header just because it does not see it so often, but that would be stupid given the overwhelmingly large volume of spam vs ordinary mail. >> sending MTA is dynamic/residential> > This shouldn't be the case, but if your submission server resides on a > dynamic IP address then this could very well be the case. I say > "shouldn't", though, because there have been known cases of anti-spam > appliances in the past that do deep inspection of Received headers and > compare IP addresses found in them against policy blacklists. These > types of blacklists are designed only to be used against the IP address > of the connecting server, not IPs found in headers. That said, I don't > think that Microsoft is doing that. Your argument on this one is convincing. I will probably never know the answer, at least not in my setup. I realized this was a weak spot and fixed it with: /etc/postfix/main.cf mime_header_checks = regexp:/etc/postfix/headers_checks header_checks = regexp:/etc/postfix/headers_checks /etc/postfix/headers_checks /^Received:/ IGNORE /^X-Originating-IP:/ IGNORE /^X-Mailer:/ IGNORE /^Mime-Version 1.0.*:/ REPLACE Mime-Version: 1.0 > I really would not put any malicious intent here. Agree. Negligence is easier to prove and in both cases the outcome is the same and so is the practical fix. Just the punishment is different, but I am not out to punish Microsoft, I just wish it behaved more collaboratively. >> Bottom line, I think the problem is more ethical than technical. > > I certainly think it's technical on their part, but if by ethical you > mean that Microsoft just doesn't care enough about you to want to solve > your problem then you're probably right. By ethical I mean their way of conducting business, which results in their technical decisions. I think it is unethical to make the statement "My MTA received an email from your MTA and it is queued for delivery" when in fact it should be "My MTA has received an email from your MTA and has dropped it into a black hole," or even "My MTA has received an email from your MTA and what will happen next I won't tell you." Even assuming no malicious intent, the first statement is a misrepresentation with serious consequences. The last statement makes email worthless. > I would suggest, as others have, that if you cannot resolve this > directly then you use a relayhost for messages that go out to Microsoft > clients, then you should at least be able to get your mail through. A simpler way for me is to open and operate a mailbox on Microsoft's system and communicate with Microsoft clients through that mailbox. Both solutions are not good enough: who guarantees that Microsoft is not going to drop silently a message coming from their own system? This is why I am still of the opinion that the problem is more ethical than technical. It is akin to a rental car company renting a car that will loose a wheel while driving. Sure the immediate solution is technical, but the overarching solution is ethical: a standard that distinguish between good behavior, where the accidental loss of a wheel in circumstances beyond the control of the service provider vs bad behavior where the accidental loss of a wheel is caused by the negligence of the service provider and could be avoided with a proper standard of care (which in this case would be to put the message identified as spammy in the junk folder; or to let the sending MTA know that the message was dropped). Yuv
