Re: [mailop] Tightening of delivery rules for Exchange Online

[Graeme Fowler via mailop]

On 29 March 2023 13:53:59 "Gellner, Oliver via mailop"  
wrote:

I'm not sure what is meant by EOL


In this context, Exchange Online.

I understand the "eventually", but for now it's only applying to their 
closest customers.


At work I already have some small scoring rules in place that identify 
emails with received headers that hint at decade+ out of date MTA installs 
but take no action on them. They're just one more indicator of the 
trustworthyness of the source of the email.


If an organisation is still using something like Exchange 5.5, then the 
likelihood of the emails coming through it being malware is pretty high.


On the one hand, we as an industry curse and spit at MS for a number of 
things. Let's not do that when they're doing something which is actually 
fairly useful!


Graeme

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Tightening of delivery rules for Exchange Online

[Graeme Fowler via mailop]

On 29 March 2023 13:53:59 "Gellner, Oliver via mailop"  
wrote:

I'm not sure what is meant by EOL


In this context, Exchange Online.

I understand the "eventually", but for now it's only applying to their 
closest customers.


At work I already have some small scoring rules in place that identify 
emails with received headers that hint at decade+ out of date MTA installs 
but take no action on them. They're just one more indicator of the 
trustworthyness of the source of the email.


If an organisation is still using something like Exchange 5.5, then the 
likelihood of the emails coming through it being malware is pretty high.


On the one hand, we as an industry curse and spit at MS for a number of 
things. Let's not do that when they're doing something which is actually 
fairly useful!


Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Tightening of delivery rules for Exchange Online

[Gellner, Oliver via mailop]

On 29.03.2023 at 11:46 Graeme Fowler via mailop wrote:

> On 28 March 2023 16:32:42 Tobias Fiebig via mailop  
> wrote:
>> https://techcommunity.microsoft.com/t5/exchange-team-blog/throttling-and-blocking-email-from-persistently-vulnerable/ba-p/3762078

> This only affects Exchange Online customers with a hybrid setup, i.e. one 
> where they have an on-premises Exchange server tied into their EOL 
> environment.
>
> At $dayjob, that's our current setup. Exim talks to and from the outside 
> world, delivers to local Exchange, delivers to EOL (and the same IV reverse). 
> We are however in the process currently of removing the local Exchange 
> servers from the path. Ultimately the Exim end will disappear too... which 
> means I'll be doing something new!
>
> MS know what version and update level the local servers have because they're 
> in an Exchange Organisation with EOL so share data each way.
>
> So there's nothing nefarious here, just MS enforcing zero trust and best 
> practice on their customers.

I'm not sure what is meant by EOL but Exchange 2007 delivering  emails via an 
inbound connector seems just to be the first step. The article specifically 
mentions:
"The enforcement system will eventually apply to *all* versions of Exchange 
Server and *all* email coming into Exchange Online, but we are starting with a 
very small subset of outdated servers: Exchange 2007 servers that connect to 
Exchange Online over an inbound connector type of OnPremises."

So in the end it doesn't seem to matter whether the email is delivered via a 
hybrid connection, over an anonymous SMTP channel, fetched from an external 
mailbox, etc: If an email contains a Received header with an outdated Exchange 
version it will be throttled and then blocked. This is also the reason why 
Microsoft is limiting this to Exchange servers: Other MTAs usually do not print 
their build number into every outgoing email.

--
BR Oliver


dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Tightening of delivery rules for Exchange Online

[Graeme Fowler via mailop]

On 28 March 2023 16:32:42 Tobias Fiebig via mailop  wrote:

https://techcommunity.microsoft.com/t5/exchange-team-blog/throttling-and-blocking-email-from-persistently-vulnerable/ba-p/3762078


This only affects Exchange Online customers with a hybrid setup, i.e. one 
where they have an on-premises Exchange server tied into their EOL environment.


At $dayjob, that's our current setup. Exim talks to and from the outside 
world, delivers to local Exchange, delivers to EOL (and the same IV 
reverse). We are however in the process currently of removing the local 
Exchange servers from the path. Ultimately the Exim end will disappear 
too... which means I'll be doing something new!


MS know what version and update level the local servers have because 
they're in an Exchange Organisation with EOL so share data each way.


So there's nothing nefarious here, just MS enforcing zero trust and best 
practice on their customers.


Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Unbound configuration for DNSBL ?

[John Levine via mailop]

It appears that Cyril - ImprovMX via mailop  said:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>@John thank you for your input, but I wonder ; If I leave the Unbound
>default configuration, won't it will use my local resolv.conf file to
>access the DNS servers? Or does Unbound uses a specific set of DNS servers
>instead of using the ones recommended by the OS?

Unbound is a DNS cache. It queries the authoritative servers for the
zones its client ask about to get the answers which it sends along to
its clients.

resolv.conf is for application programs.  The usual setup is that it
contains 127.0.0.1 to tell applications to query the cache server on the
same host, which in this case is unbound.

Unbound has its own configuration file but in most cases the defaults
are all you need.

R's,
John


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Unbound configuration for DNSBL ?

[Cyril - ImprovMX via mailop]

@John thank you for your input, but I wonder ; If I leave the Unbound
default configuration, won't it will use my local resolv.conf file to
access the DNS servers? Or does Unbound uses a specific set of DNS servers
instead of using the ones recommended by the OS?

Le mar. 28 mars 2023 à 14:30, John Levine via mailop  a
écrit :

> It appears that Renaud Allard via mailop  said:
> >If you are using a DNS key from spamhaustech, there is no technical
> >problem in using OpenDNS. Although you should probably query the servers
> >yourself ...
>
> If you are running your own unbound, just use the default configuration
> so it queries directly.   An extra level of indirection will just slow
> things down.  OpenDNS is no closer on the network than Spamhaus so
> you won't get answers any faster and often, when it's not in their
> cache, slower.
>
> R's,
> John
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop