Contact data for outlook.com

Wed Mar 10 08:50:32 UTC 2021

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 at 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 at circlenet.us) client-ip=51.222.96.169; 
>
> Authentication-Results: mx.google.com;
>  dkim=temperror (no key for signature) [email protected] header.s=mail
>  header.b=WCzH8ira; 
>  spf=neutral (google.com: 51.222.96.169 is neither permitted nor denied by
>  domain of sam at circlenet.us) smtp.mailfrom=sam at 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 at 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