Thanks for the reply! Although this apparently isn't new, I'll consider this a milestone as we just removed spf2.0 records from our settings guidelines.
Smartscreen for email is deprecated on Exchange onPrem ... but isn't it also in O365 and Outlook.com, since those rely on EOP? The copy/pasted answers from the Outlook.com Support still mentions Smartscreen heavily. That being said, the said Support is also named " Hotmail Sender Support ", maybe they didn't get the memo about Outlook.com =) Cheers, -- Benjamin From: mailop <mailop-boun...@mailop.org> On Behalf Of Mihai Costea Sent: jeudi 4 octobre 2018 19:21 To: mailop@mailop.org Subject: Re: [mailop] Is SenderID deprecated? (Udeme Ukutt) Hi There are no reasons to worry about old Exchange onPrem servers spam filters as nobody relies on them anymore. We stopped issuing filter updates two years ago and the filter itself stopped receiving new features well before that. https://blogs.technet.microsoft.com/exchange/2016/09/01/deprecating-support-for-smartscreen-in-outlook-and-exchange/ "no record" never had any impact in the SenderID agent. "Auth fail -> hard fail" was not wise policy to enable due to complex routing false positives. Auth pass was fed into the smartscreen (content filter) in Exchange as a positive email feature, assuming legit senders will auth more than spammers. Which was a bad assumptions as spammers were in fact the earliest adopters. No record never had any impact. Everything is SPF these days in both O365 and Outlook.com. Some headers might mention PRA/PRD as the entity among all the sender related headers that was selected to do the check against, but this selection is done the SPF way. >From any practical pov SenderID is deprecated. For the email historians, Terry had at least a hundred blogs on auth over the years. e.g. https://blogs.msdn.microsoft.com/tzink/2007/07/29/sender-authentication-part-17-hazards-of-senderid-and-spf/ Sender authentication part 17: Hazards of SenderID and SPF ...<https://blogs.msdn.microsoft.com/tzink/2007/07/29/sender-authentication-part-17-hazards-of-senderid-and-spf/> blogs.msdn.microsoft.com Both SenderID and SPF have their critics. I'd like to touch on two potential problems with them: the first is the issue of email forwarding. There's no official standard on how email is to be forwarded (in terms of rewriting the headers). Suppose that Mail Server A sends the message and everything complies with SenderID... > Message: 3 > Date: Thu, 4 Oct 2018 08:45:58 +0000 > From: Benjamin BILLON <bbil...@splio.com <mailto:bbil...@splio.com>> > To: "mailop@mailop.org <mailto:mailop@mailop.org>" <mailop@mailop.org > <mailto:mailop@mailop.org>> > Subject: [mailop] Is SenderID deprecated? > Message-ID: > > <he1pr0602mb3435cb10e9fb9da2ebdcbdcbb4...@he1pr0602mb3435.eurprd06.prod.outlook.com > > <mailto:he1pr0602mb3435cb10e9fb9da2ebdcbdcbb4...@he1pr0602mb3435.eurprd06.prod.outlook.com>> > > Content-Type: text/plain; charset="utf-8" > > The RFC 4406 is not obsolete, only experimental. > > In the past, Hotmail/Live heavily relied on it, but it's not even visible in > Outlook's headers anymore (advantageously replaced by DKIM, and DMARC). So > Hotmail's out. > > Microsoft Exchange servers also used it, but it's not clear it's still the > case. > The article > https://docs.microsoft.com/en-us/exchange/antispam-and-antimalware/antispam-protection/sender-id?view=exchserver-2019 > > <https://docs.microsoft.com/en-us/exchange/antispam-and-antimalware/antispam-protection/sender-id?view=exchserver-2019> > says "basically unchanged from Exchange Server 2010", which kind of scares > me. But the page also says it checked the "RECEIVED SMTP header", so > basically the HELO/EHLO; it mentions the PRA, but it's not the definition I > knew (nor what's in the RFC): "The IP address of the authorized sending > server is referred to as the purported responsible address (PRA).". > In short, I don't understand this article and I'm glad I'm not administrating > an Exchange server right now. > > In my _opinion_, only old (non-updated) Exchange servers might reject or > consider negatively emails with missing SenderID record in their sending > domains, so it _should_ be ok to stop setting up these records. > > Dear Microsoft folks around there, what's the status of it from your > perspective? > > Cheers, > -- > Benjamin >
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
