Contact data for outlook.com
Good afternoon, So I'm looking for a contact at Microsoft in particular someone on the outlook spam protection/prevention team to assist us with a IP block. I have allready signed up for SNDS and there is no data given . Please feel free to contact me off the list. Best Regards, Daniel Walters
You are not alone sir, for reasons as yet unknown outlook.com has recently started blocking my range as well. If I make progress in contacting someone with clue I will pass that information along privately. Sam Moats On 2021-03-08 16:18, Dan Walters via NANOG wrote:
Good afternoon,
So I'm looking for a contact at Microsoft in particular someone on the outlook spam protection/prevention team to assist us with a IP block. I have allready signed up for SNDS and there is no data given . Please feel free to contact me off the list.
Best Regards,
Daniel Walters
If you haven't done this yet - start with the outlook postmaster troubleshooting documentation and open a support ticket with them. https://sendersupport.olc.protection.outlook.com/pm/troubleshooting.aspx Matt On 2021-03-09 7:07 a.m., sam@circlenet.us wrote:
You are not alone sir, for reasons as yet unknown outlook.com has recently started blocking my range as well. If I make progress in contacting someone with clue I will pass that information along privately.
Sam Moats
On 2021-03-08 16:18, Dan Walters via NANOG wrote:
Good afternoon,
So I'm looking for a contact at Microsoft in particular someone on the outlook spam protection/prevention team to assist us with a IP block. I have allready signed up for SNDS and there is no data given . Please feel free to contact me off the list.
Best Regards,
Daniel Walters
You may also try the mailops list. On Tue, Mar 9, 2021, 12:55 PM Matthew V <zvernhout@gmail.com> wrote:
If you haven't done this yet - start with the outlook postmaster troubleshooting documentation and open a support ticket with them.
https://sendersupport.olc.protection.outlook.com/pm/troubleshooting.aspx
Matt
On 2021-03-09 7:07 a.m., sam@circlenet.us wrote:
You are not alone sir, for reasons as yet unknown outlook.com has recently started blocking my range as well. If I make progress in contacting someone with clue I will pass that information along privately.
Sam Moats
On 2021-03-08 16:18, Dan Walters via NANOG wrote:
Good afternoon,
So I'm looking for a contact at Microsoft in particular someone on the outlook spam protection/prevention team to assist us with a IP block. I have allready signed up for SNDS and there is no data given . Please feel free to contact me off the list.
Best Regards,
Daniel Walters
Here are some suggestions for improvements, for both of you, below... Many postmasters (/networks) out there, are actually very strict on RFC / BCP compliance, where the slightest violation equals potentially severe consequences: Looking at circlenet.us, the domain itself has the caveat of going directly against the Internet's RFC2182 / Best Current Practice #16. ... Are you by any chance using "Mail in a Box", or any of the other packages, where the maintainers do not wish to follow standards / BCP's, but instead suggests their users to ignore those? -> https://discourse.mailinabox.email/t/dnswl-org-recommendations/667 Those "temporary network glitches" the author actually mentions having "from time to time", is the exact consequence of violating the RFC2182 / Best Current Practice #16. I would be very happy to see the whole world reject for such things like that. Or said in another way: if you don't care enough about your own stuff - why should any third party care about it, at all? :) Next, it seems like your mail server DKIM signed your message, however, there is no DKIM record on the relevant "mail._domainkey.circlenet.us." TXT record, it yells DKIM. Literally, for what seems to be against all kind of advice from the whole email community, it seems like your server is actually rewriting the client's original IP address ("Received:" header), to one of your server's IP addresses, perhaps for some privacy reasons:
Received: from authenticated-user (mail.circlenet.us [51.222.96.171]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by mail.circlenet.us (Postfix) with ESMTPSA id 59CE72A001B; Tue, 9 Mar 2021 12:07:56 +0000 (UTC) When Google (MX records of @NANOG.ORG) got your message, it arrived to Google, from another IP address, with a dynamic / generic looking hostname. This IP address was not authorized by your SPF record.
Received: from mail.circlenet.us (ip169.ip-51-222-96.net. [51.222.96.169]) by mx.google.com with ESMTPS id i8si2272841qki.324.2021.03.09.04.07.57 for <nanog@nanog.org> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Mar 2021 04:07:57 -0800 (PST)
Received-SPF: neutral (google.com: 51.222.96.169 is neither permitted nor denied by domain of sam@circlenet.us) client-ip=51.222.96.169;
Authentication-Results: mx.google.com; dkim=temperror (no key for signature) header.i=@circlenet.us header.s=mail header.b=WCzH8ira; spf=neutral (google.com: 51.222.96.169 is neither permitted nor denied by domain of sam@circlenet.us) smtp.mailfrom=sam@circlenet.us
Literally no kind of authentiation (valid SPF, valid DKIM, ...), at all. Rumours goes that Outlook.com is strict at SPF. Ideally, your SMTP HELO/EHLO name should be identical to the PTR, "mail.circlenet.us" is not equal to "ip169.ip-51-222-96.net" above. For both of you, I would actually lean towards cleaning up / maintaining your SPF records a little better: - Always use ip6: ip4: directives for your own (static) mail servers. - Then add the include: or whatever mechanisms that your third parties require you to, for example "include:_spf.google.com", *** if they are really needed, at that specific (sub)domain level ***. - Then end your record, preferably with "-all" (hardfail), but absolutely minimum of softfail. As restrictive as possible. Sam, it sounds like you have at least the IPv4 /30 subnet (adapt it to match your subnet), so a SPF like this, would be what I would do for "circlenet.us":
"v=spf1 ip4:51.222.96.168/30 ip4:23.25.121.0/24 ip4:173.230.144.119/32 -all"
v=spf1 ***mx*** ***a*** ***ip4:13.89.36.13/32*** ip4:13.110.6.214/32 ip4:168.61.173.54/32 ip4:23.99.213.249/32 ip4:207.164.169.226/32 ip4:54.174.52.85/32 ip4:68.185.106.96/28 ip4:63.246.31.7/32 ip4:13.78.237.56/32 ip4:13.108.0.0/14 ***a:smtp01.omnigo.com*** include:aspmx.pardot. com include:spf.protection.outlook.com include:_spf.salesforce.com ***~all*** ***mx***: You are using Office 365 as inbound (MX) records, the bigger ones are separate inbound/outbound servers, so take away this useless one. ***a***: You are proxying your domain over CloudFlare, CloudFlare will never send any emails on your domain's behalf, so take away this useless one. ***ip4:13.89.36.13/32***: See next, but chances are you should leave
Dan, as for yours, on "omnigo.com": this one. ***a:smtp01.omnigo.com***: This one literally duplicates the previous, already authorized IP address, meaning you are authorizing "ip4:13.89.36.13/32" twice, so take away this useless one. ***~all***: I would also here lean towards e.g. -all (hardfail). I have been running "-all" (hardfail) since forever, literally since SPF was created, and motivated everyone around me to do the same, and so far without any issues. As for the classic forwarding issue, you can ask yourself - if the bigger ones like PayPal, Bank of America, and so on, are NOT going to set less restrictive policies due to for example bad forwarders, ... why should you? It's an issue of the postmaster at the forwarding service, and the final destination, and for those two to figure out how to mitigate / override, if necessary, - and not something you should potentially be reducing the "security levels" from your end, to fix their (potentially crappy) implementations. That's just a few things you could look at fixing, which would definitely be improving your *chances* of good deliverability, although they still won't guarantee any deliverability at all. Just my two cents. -- Med venlig hilsen / Kind regards, Arne Jensen Den 09-03-2021 kl. 13:07 skrev sam@circlenet.us:
You are not alone sir, for reasons as yet unknown outlook.com has recently started blocking my range as well. If I make progress in contacting someone with clue I will pass that information along privately.
Sam Moats
On 2021-03-08 16:18, Dan Walters via NANOG wrote:
Good afternoon,
So I'm looking for a contact at Microsoft in particular someone on the outlook spam protection/prevention team to assist us with a IP block. I have allready signed up for SNDS and there is no data given . Please feel free to contact me off the list.
Best Regards,
Daniel Walters
Good news on our front, Microsoft did respond to cCircleNet's request and has cleared the issue. Thanks for all of the feedback. Sam Moats On 2021-03-10 03:50, Arne Jensen wrote:
Here are some suggestions for improvements, for both of you, below...
Many postmasters (/networks) out there, are actually very strict on RFC / BCP compliance, where the slightest violation equals potentially severe consequences:
Looking at circlenet.us, the domain itself has the caveat of going directly against the Internet's RFC2182 / Best Current Practice #16.
... Are you by any chance using "Mail in a Box", or any of the other packages, where the maintainers do not wish to follow standards / BCP's, but instead suggests their users to ignore those?
-> https://discourse.mailinabox.email/t/dnswl-org-recommendations/667
Those "temporary network glitches" the author actually mentions having "from time to time", is the exact consequence of violating the RFC2182 / Best Current Practice #16.
I would be very happy to see the whole world reject for such things like that. Or said in another way: if you don't care enough about your own stuff - why should any third party care about it, at all? :)
Next, it seems like your mail server DKIM signed your message, however, there is no DKIM record on the relevant "mail._domainkey.circlenet.us." TXT record, it yells DKIM.
Literally, for what seems to be against all kind of advice from the whole email community, it seems like your server is actually rewriting the client's original IP address ("Received:" header), to one of your server's IP addresses, perhaps for some privacy reasons:
Received: from authenticated-user (mail.circlenet.us [51.222.96.171]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by mail.circlenet.us (Postfix) with ESMTPSA id 59CE72A001B; Tue, 9 Mar 2021 12:07:56 +0000 (UTC) When Google (MX records of @NANOG.ORG) got your message, it arrived to Google, from another IP address, with a dynamic / generic looking hostname. This IP address was not authorized by your SPF record.
Received: from mail.circlenet.us (ip169.ip-51-222-96.net. [51.222.96.169]) by mx.google.com with ESMTPS id i8si2272841qki.324.2021.03.09.04.07.57 for <nanog@nanog.org> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Mar 2021 04:07:57 -0800 (PST)
Received-SPF: neutral (google.com: 51.222.96.169 is neither permitted nor denied by domain of sam@circlenet.us) client-ip=51.222.96.169;
Authentication-Results: mx.google.com; dkim=temperror (no key for signature) header.i=@circlenet.us header.s=mail header.b=WCzH8ira; spf=neutral (google.com: 51.222.96.169 is neither permitted nor denied by domain of sam@circlenet.us) smtp.mailfrom=sam@circlenet.us
Literally no kind of authentiation (valid SPF, valid DKIM, ...), at all. Rumours goes that Outlook.com is strict at SPF.
Ideally, your SMTP HELO/EHLO name should be identical to the PTR, "mail.circlenet.us" is not equal to "ip169.ip-51-222-96.net" above.
For both of you, I would actually lean towards cleaning up / maintaining your SPF records a little better:
- Always use ip6: ip4: directives for your own (static) mail servers. - Then add the include: or whatever mechanisms that your third parties require you to, for example "include:_spf.google.com", *** if they are really needed, at that specific (sub)domain level ***. - Then end your record, preferably with "-all" (hardfail), but absolutely minimum of softfail. As restrictive as possible.
Sam, it sounds like you have at least the IPv4 /30 subnet (adapt it to match your subnet), so a SPF like this, would be what I would do for "circlenet.us":
"v=spf1 ip4:51.222.96.168/30 ip4:23.25.121.0/24 ip4:173.230.144.119/32 -all"
Dan, as for yours, on "omnigo.com":
v=spf1 ***mx*** ***a*** ***ip4:13.89.36.13/32*** ip4:13.110.6.214/32 ip4:168.61.173.54/32 ip4:23.99.213.249/32 ip4:207.164.169.226/32 ip4:54.174.52.85/32 ip4:68.185.106.96/28 ip4:63.246.31.7/32 ip4:13.78.237.56/32 ip4:13.108.0.0/14 ***a:smtp01.omnigo.com*** include:aspmx.pardot. com include:spf.protection.outlook.com include:_spf.salesforce.com ***~all*** ***mx***: You are using Office 365 as inbound (MX) records, the bigger ones are separate inbound/outbound servers, so take away this useless one. ***a***: You are proxying your domain over CloudFlare, CloudFlare will never send any emails on your domain's behalf, so take away this useless one. ***ip4:13.89.36.13/32***: See next, but chances are you should leave this one. ***a:smtp01.omnigo.com***: This one literally duplicates the previous, already authorized IP address, meaning you are authorizing "ip4:13.89.36.13/32" twice, so take away this useless one. ***~all***: I would also here lean towards e.g. -all (hardfail).
I have been running "-all" (hardfail) since forever, literally since SPF was created, and motivated everyone around me to do the same, and so far without any issues.
As for the classic forwarding issue, you can ask yourself - if the bigger ones like PayPal, Bank of America, and so on, are NOT going to set less restrictive policies due to for example bad forwarders, ... why should you?
It's an issue of the postmaster at the forwarding service, and the final destination, and for those two to figure out how to mitigate / override, if necessary, - and not something you should potentially be reducing the "security levels" from your end, to fix their (potentially crappy) implementations.
That's just a few things you could look at fixing, which would definitely be improving your *chances* of good deliverability, although they still won't guarantee any deliverability at all.
Just my two cents.
-- Med venlig hilsen / Kind regards, Arne Jensen
Den 09-03-2021 kl. 13:07 skrev sam@circlenet.us:
You are not alone sir, for reasons as yet unknown outlook.com has recently started blocking my range as well. If I make progress in contacting someone with clue I will pass that information along privately.
Sam Moats
On 2021-03-08 16:18, Dan Walters via NANOG wrote:
Good afternoon,
So I'm looking for a contact at Microsoft in particular someone on the outlook spam protection/prevention team to assist us with a IP block. I have allready signed up for SNDS and there is no data given . Please feel free to contact me off the list.
Best Regards,
Daniel Walters
participants (5)
-
Arne Jensen -
Dan Walters -
Matthew V -
Ross Tajvar -
sam＠circlenet.us