Re: [mailop] salesforce phishing emails

[Giovanni Bechis via mailop]

On Sun, Dec 03, 2023 at 07:26:14AM +0100, Arne Jensen via mailop wrote:
> Den 30-11-2023 kl. 09:36 skrev Giovanni Bechis via mailop:
> > I maintain an ESP rbl
> 
> Thank you for maintaining and providing that!
> 
> I looked around and didn't find much information about the operation of 
> the RBL though.
> 
> So that raises a few questions from my end, such as:
> 
> - Is there any sort of usage / query restrictions on that RBL?
> 
no restrictions atm

> - Is it possible to download the data, either for a local mirror or even 
> in order to assist with raising the quality of the public mirrors?
> 
not atm

> - Can you submit spam samples, or otherwise provide suggestions for 
> inclusion?
> 
> - Are you the only person one adding "bad senders" to these RBL lists?
> 
> - What data is the "bad senders" based on? Spam sent to spam traps? Spam 
> sent to your personal mailbox? ...?
> 
> - If you're under the impression there is one or more false positives, 
> ... is there any way, you can report that?
> 
Atm data are based on spamtraps and spam delivered to mailbox of some
selected customers that reports FPs and FNs to my company.
I am in contact with another company which is going to provide me more
data.
If there is interest in this rbl I can provide more info and a way to
report FNs and FPs.

 Regards
  Giovanni

> -- 
> Med venlig hilsen / Kind regards,
> Arne Jensen
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop


signature.asc
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] New Google DNS Servers? 192.178.65.0/28 NO PTR records.. anyone? Brandon?

[Graeme Slogrove via mailop]

Correct, 1.1.1.1 is the anycast address that clients use. The resolvers behind 
that anycast address will be part of the listed IP addresses.

Servers will not see the query coming from 1.1.1.1.

Regards,
Graeme Slogrove

-Original Message-
From: mailop  On Behalf Of Jose Morales Velazquez 
via mailop
Sent: Tuesday, December 5, 2023 9:12 AM
To: mailop@mailop.org
Subject: Re: [mailop] New Google DNS Servers? 192.178.65.0/28 NO PTR records.. 
anyone? Brandon?


-
CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.
-

I believe they do not add the DNS IP 1.1.1.1 or any other to the list of IPs 
because the list is of access IP addresses used make requests to servers from 
their proxies backends.

Like, on the Cloudflare DNS for your domain you add a hostname record pointing 
to one of your server's IP addresses and enable Cloudflare's proxy on it, then 
Cloudflare will mask your IP address to external queries on their 1.1.1.1 DNS 
server or your domain's assigned DNS server from Cloudflare with one of the 
proxy server they assigned to your record. Now when someone requests that 
hostname they will see the Cloudflare Proxy IP assigned to the hostname and in 
the backend, cloudflare will route the communication thru one of these IP 
addresses on that list of IPs to your servers.

Example: Set firewalls /ACLs to only allow access from these IP addresses to 
your webservers, so that only CLoudflare's proxied records can connect to them.


Sincerely,
Jose


On 12/4/2023 1:53 PM, Randolf Richardson, Postmaster via mailop wrote:
>   Interestingly, 1.1.1.1, which is Cloudflare's famous public DNS
> resolver, is not included in that list of IPv4 addresses:
>
>   IP Ranges | Cloudflare
>   https://www.cloudflare.com/ips/
>
>   Their main reference page (above) doesn't seem to mention it, but I
> wonder if it might be prudent to whitelist it as well (in addition to
> Cloudflare's official list) to ensure smoother operations overall.
>
>> Hello,
>>
>> I believe you can enumerate cloudflare IPs via :
>>
>> https://www.cloudflare.com/ips-v4
>> https://www.cloudflare.com/ips-v6
>>
>> It's likely an overfit situation (not just resolvers), but it's something.
>>
>> -tony
>>
>> On 12/2/23 21:57, Arne Jensen via mailop wrote:
>>> Always happy to help! And wauh, times flies by these days...
>>>
>>> First of all - I completely agree with you, that several things
>>> could be better here ;-).
>>>
>>> Taking the four major ones, the top list, from best to worst, might
>>> be
>>> like:
>>>
>>> 1. OpenDNS
>>> 2. Google
>>> 3. Quad 9/PCH
>>> 4. Cloudflare
>>>
>>> Given your mention of "internal documentation", maybe there could be
>>> something more for you to document, if you haven't already:
>>>
>>> Google does, as mentioned previously, document their resolver
>>> infrastructure on the Web, contrary to many others, but also with a JSON:
>>>
>>> -> API/JSON: https://www.gstatic.com/ipranges/publicdns.json
>>>
>>> OpenDNS is also documenting theirs, and also have PTR on the
>>> outgoing resolver IP, but unfortunately, the PTR **doesn't always**
>>> point to one of their OpenDNS.* domain names, which could be confusing:
>>>
>>> Reaching OpenDNS Copenhagen:
>>> - 146.112.135.70 (r7.compute.cph1.edc.strln.net)
>>> - 2a04:e4c0:17::73 (r10.compute.cph1.edc.strln.net)
>>>
>>> Reaching OpenDNS London:
>>> - 208.69.34.73 (m53.lon.opendns.com)
>>> - 2a04:e4c0:10::91 (r3.compute.lon1.edc.strln.net)
>>>
>>> It is however consistent with their locations as retrieved from here:
>>>
>>> -> Web: https://www.opendns.com/data-center-locations/
>>> -> JSON:
>>> https://umbrella-dns-requests.marketops.umbrella.com/api/data-center
>>> -locations
>>>
>>> Currently, it seems very much a hit and miss, mostly miss, when
>>> reaching any IP address with PTR records, through Quad 9. I haven't
>>> ever seen Quad 9 document it like OpenDNS or Google.
>>>
>>> With Cloudflare, I've never see any of their outbound resolver IP
>>> addresses have any PTR records. I haven't ever seen Cloudflare
>>> document it like OpenDNS or Google.
>>>
>>> With the above possible ways to retrieve the OpenDNS and Google
>>> data, you have the option to automate e.g. a weekly update of their
>>> resolver addresses, if you feel for something like that in any way.
>>> ;)
>>>
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
Email secured by Trustwave 

Re: [mailop] Email deliverability issues to Outlook

[Bradley Silverman via mailop]

Hi gents,

Apologies for the lack of reply, I was waiting for my new account to get
send privledges.

As an example header, I have provided one below from a test account.

The thing to note is that the Original server (ending in
hostyourservices.net) sends outbound through a mail cluster that we have
other servers send through as well, about half end in hostyourservices.net
and about half don't. Any domain that does NOT end in 'hostyourservices.net'
will happily be received by Outlook at whatever SCL score is appropriate
for that email. However anything ending in hostyourservices.net will get a
SCL 9.
We have moved the domains between the servers and sent the identical
emails, and we always find, consistently, that anything ending in
hostyourservices.net will get SCL9 and that some domain (we've tried a
dozen or so personally) sending from the other server hostname will get a
SCL1.

Microsoft is clearing punishing that domain, but we can't for the life of
us work out why, and we are having zero luck with their support, whom we've
been trying to explain the issue to for months.

Anyone who has a contact with Microsoft that can help would be fantastic,
as this happened years ago and the only fix was for microsoft to intervene.


Cheers,

==
Received: from JH0PR01MB6253.apcprd01.prod.exchangelabs.com
 (2603:1096:990:9c::13) by SEYPR01MB6185.apcprd01.prod.exchangelabs.com with
 HTTPS; Mon, 4 Dec 2023 05:22:54 +
Received: from CH0P223CA0030.NAMP223.PROD.OUTLOOK.COM (2603:10b6:610:116::6)
 by JH0PR01MB6253.apcprd01.prod.exchangelabs.com (2603:1096:990:9c::13) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7046.33; Mon, 4 Dec
 2023 05:22:44 +
Received: from SN1PEPF0002636E.namprd02.prod.outlook.com
 (2603:10b6:610:116:cafe::27) by CH0P223CA0030.outlook.office365.com
 (2603:10b6:610:116::6) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7046.33 via Frontend
 Transport; Mon, 4 Dec 2023 05:22:42 +
Authentication-Results: spf=pass (sender IP is 110.232.143.186)
 smtp.mailfrom=datamaster.net.au; dkim=pass (signature was verified)
 header.d=datamaster.net.au;dmarc=bestguesspass action=none
 header.from=datamaster.net.au;compauth=pass reason=109
Received-SPF: Pass (protection.outlook.com: domain of datamaster.net.au
 designates 110.232.143.186 as permitted sender)
 receiver=protection.outlook.com; client-ip=110.232.143.186;
 helo=m4.out3.mxs.au; pr=C
Received: from m4.out3.mxs.au (110.232.143.186) by
 SN1PEPF0002636E.mail.protection.outlook.com (10.167.241.139) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384)
id
 15.20.7068.20 via Frontend Transport; Mon, 4 Dec 2023 05:22:41 +
X-IncomingTopHeaderMarker:
 
OriginalChecksum:8F96A8C1FD1A19AB5E6201A48BFCDE111D7C7542297063C2C4A7F659C437C315;UpperCasedChecksum:EFAA2613BE81E0971DB83B7DCF94896C322AB863DEB0C16D67C74A37F8938E57;SizeAsReceived:2358;Count:23
Received: from syn07be.syd6.hostyourservices.net (
syn07be.syd6.hostyourservices.net [110.232.143.84])
by out3.mxs.au (Halon) with ESMTPS (TLSv1.2) tls
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
id 240ba464-9265-11ee-b4c2-00163c573069
for ;
Mon, 04 Dec 2023 16:22:38 +1100 (AEDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=datamaster.net.au; s=default; h=Content-Transfer-Encoding:Content-Type:
Message-ID:Subject:To:From:Date:MIME-Version:Sender:Reply-To:Cc:Content-ID:
Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
:Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
List-Subscribe:List-Post:List-Owner:List-Archive;
bh=ZyAXWNyS2Wa8EhZsbJxuOR7x/gpVP+u/0b54l7af8VE=;
b=gxvFLIJyFqvQ1g6tV/vvOE3V8y
IgtL9DX65LcaKy3ttKitq/JQNiPVi8hru2ckBLKBygjH1da9H2extT+BjAuXwdoUGxLYhH8gW1FhY
NpNOZBuqKI17AvA16pc6e4k3XngPmQKsnZ+JwJOTnFebFwOZhbSuSwBFd5zfMj2lAPv7E27lbeHNi
1KQQ/uiPa8c0I9x/9l7xFnYa5GtVwSefD1vp/3dJAgTc/poMOD0Pd8IAAuUsYTJtlfHh95mKO2kI6
Nt3zq03QSBqLrOsHXPDi1Ah+GtLiC40XsvmprnS3viiNeqkrjNxZerc324YCnM/a/BBrTU1T2w0jP
QxKqI76w==;
Received: from [::1] (port=43518 helo=syn07be.syd6.hostyourservices.net)
by syn07be.syd6.hostyourservices.net with esmtpa (Exim 4.96.2)
(envelope-from )
id 1rA1Pi-004NLx-2d
for nxd...@outlook.com;
Mon, 04 Dec 2023 16:22:38 +1100
Date: Mon, 04 Dec 2023 16:22:38 +1100
From: j...@datamaster.net.au
To: nxd...@outlook.com
Subject: Follow up for support request 'SYN-E4994732'
User-Agent: Roundcube Webmail/1.6.0
Message-ID: <396d8174404677404d41dbb78b991...@datamaster.net.au>
X-Sender: j...@datamaster.net.au
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with
any abuse report
X-AntiAbuse: Primary Hostname - syn07be.syd6.hostyourservices.net
X-AntiAbuse: Original Domain - outlook.com
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender 

Re: [mailop] Google Postmaster Tools data missing recently - anyone else?

[Tim Starr via mailop]

Others have reported this, but I'm not seeing it, myself. It seems to be
intermittent. Some see it, some don't.

-Tim

On Mon, Dec 4, 2023 at 4:04 PM Omar Thameen via mailop 
wrote:

> Is anyone else seeing data missing from Google Postmaster Tools?
> For all our hosted domains, everything was consistent until Nov 28,
> then no data until Dec 2, and nothing yet for Dec 3.
>
> Omar
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Google Postmaster Tools data missing recently - anyone else?

[Randolf Richardson, Postmaster via mailop]

I'm greeted by the message "No data to display at this time. Please 
come back later" for all reports, even when setting the duration to 
the maximum of 120 days.

Hopefully it's only a temporary poroblem.

> Is anyone else seeing data missing from Google Postmaster Tools?
> For all our hosted domains, everything was consistent until Nov 28,
> then no data until Dec 2, and nothing yet for Dec 3.
> 
> Omar
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop


-- 
Postmaster - postmas...@inter-corporate.com
Randolf Richardson - rand...@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Vancouver, British Columbia, Canada
https://www.inter-corporate.com/


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

[mailop] Google Postmaster Tools data missing recently - anyone else?

[Omar Thameen via mailop]

Is anyone else seeing data missing from Google Postmaster Tools?
For all our hosted domains, everything was consistent until Nov 28,
then no data until Dec 2, and nothing yet for Dec 3.

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

Re: [mailop] New Google DNS Servers? 192.178.65.0/28 NO PTR records.. anyone? Brandon?

[Jose Morales Velazquez via mailop]

I believe they do not add the DNS IP 1.1.1.1 or any other to the list of 
IPs because the list is of access IP addresses used make requests to 
servers from their proxies backends.


Like, on the Cloudflare DNS for your domain you add a hostname record 
pointing to one of your server's IP addresses and enable Cloudflare's 
proxy on it, then Cloudflare will mask your IP address to external 
queries on their 1.1.1.1 DNS server or your domain's assigned DNS server 
from Cloudflare with one of the proxy server they assigned to your 
record. Now when someone requests that hostname they will see the 
Cloudflare Proxy IP assigned to the hostname and in the backend, 
cloudflare will route the communication thru one of these IP addresses 
on that list of IPs to your servers.


Example: Set firewalls /ACLs to only allow access from these IP 
addresses to your webservers, so that only CLoudflare's proxied records 
can connect to them.



Sincerely,
Jose


On 12/4/2023 1:53 PM, Randolf Richardson, Postmaster via mailop wrote:

Interestingly, 1.1.1.1, which is Cloudflare's famous public DNS
resolver, is not included in that list of IPv4 addresses:

IP Ranges | Cloudflare
https://www.cloudflare.com/ips/

Their main reference page (above) doesn't seem to mention it, but I
wonder if it might be prudent to whitelist it as well (in addition to
Cloudflare's official list) to ensure smoother operations overall.


Hello,

I believe you can enumerate cloudflare IPs via :

https://www.cloudflare.com/ips-v4
https://www.cloudflare.com/ips-v6

It's likely an overfit situation (not just resolvers), but it's something.

-tony

On 12/2/23 21:57, Arne Jensen via mailop wrote:

Always happy to help! And wauh, times flies by these days...

First of all - I completely agree with you, that several things could be
better here ;-).

Taking the four major ones, the top list, from best to worst, might be
like:

1. OpenDNS
2. Google
3. Quad 9/PCH
4. Cloudflare

Given your mention of "internal documentation", maybe there could be
something more for you to document, if you haven't already:

Google does, as mentioned previously, document their resolver
infrastructure on the Web, contrary to many others, but also with a JSON:

-> API/JSON: https://www.gstatic.com/ipranges/publicdns.json

OpenDNS is also documenting theirs, and also have PTR on the outgoing
resolver IP, but unfortunately, the PTR **doesn't always** point to one
of their OpenDNS.* domain names, which could be confusing:

Reaching OpenDNS Copenhagen:
- 146.112.135.70 (r7.compute.cph1.edc.strln.net)
- 2a04:e4c0:17::73 (r10.compute.cph1.edc.strln.net)

Reaching OpenDNS London:
- 208.69.34.73 (m53.lon.opendns.com)
- 2a04:e4c0:10::91 (r3.compute.lon1.edc.strln.net)

It is however consistent with their locations as retrieved from here:

-> Web: https://www.opendns.com/data-center-locations/
-> JSON:
https://umbrella-dns-requests.marketops.umbrella.com/api/data-center-locations

Currently, it seems very much a hit and miss, mostly miss, when reaching
any IP address with PTR records, through Quad 9. I haven't ever seen
Quad 9 document it like OpenDNS or Google.

With Cloudflare, I've never see any of their outbound resolver IP
addresses have any PTR records. I haven't ever seen Cloudflare document
it like OpenDNS or Google.

With the above possible ways to retrieve the OpenDNS and Google data,
you have the option to automate e.g. a weekly update of their resolver
addresses, if you feel for something like that in any way. ;)


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



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

Re: [mailop] New Google DNS Servers? 192.178.65.0/28 NO PTR records.. anyone? Brandon?

[Randolf Richardson, Postmaster via mailop]

Interestingly, 1.1.1.1, which is Cloudflare's famous public DNS 
resolver, is not included in that list of IPv4 addresses:

IP Ranges | Cloudflare
https://www.cloudflare.com/ips/

Their main reference page (above) doesn't seem to mention it, but I 
wonder if it might be prudent to whitelist it as well (in addition to 
Cloudflare's official list) to ensure smoother operations overall.

> Hello,
> 
> I believe you can enumerate cloudflare IPs via :
> 
> https://www.cloudflare.com/ips-v4
> https://www.cloudflare.com/ips-v6
> 
> It's likely an overfit situation (not just resolvers), but it's something.
> 
> -tony
> 
> On 12/2/23 21:57, Arne Jensen via mailop wrote:
> > Always happy to help! And wauh, times flies by these days...
> > 
> > First of all - I completely agree with you, that several things could be 
> > better here ;-).
> > 
> > Taking the four major ones, the top list, from best to worst, might be 
> > like:
> > 
> > 1. OpenDNS
> > 2. Google
> > 3. Quad 9/PCH
> > 4. Cloudflare
> > 
> > Given your mention of "internal documentation", maybe there could be 
> > something more for you to document, if you haven't already:
> > 
> > Google does, as mentioned previously, document their resolver 
> > infrastructure on the Web, contrary to many others, but also with a JSON:
> > 
> > -> API/JSON: https://www.gstatic.com/ipranges/publicdns.json
> > 
> > OpenDNS is also documenting theirs, and also have PTR on the outgoing 
> > resolver IP, but unfortunately, the PTR **doesn't always** point to one 
> > of their OpenDNS.* domain names, which could be confusing:
> > 
> > Reaching OpenDNS Copenhagen:
> > - 146.112.135.70 (r7.compute.cph1.edc.strln.net)
> > - 2a04:e4c0:17::73 (r10.compute.cph1.edc.strln.net)
> > 
> > Reaching OpenDNS London:
> > - 208.69.34.73 (m53.lon.opendns.com)
> > - 2a04:e4c0:10::91 (r3.compute.lon1.edc.strln.net)
> > 
> > It is however consistent with their locations as retrieved from here:
> > 
> > -> Web: https://www.opendns.com/data-center-locations/
> > -> JSON: 
> > https://umbrella-dns-requests.marketops.umbrella.com/api/data-center-locations
> > 
> > Currently, it seems very much a hit and miss, mostly miss, when reaching 
> > any IP address with PTR records, through Quad 9. I haven't ever seen 
> > Quad 9 document it like OpenDNS or Google.
> > 
> > With Cloudflare, I've never see any of their outbound resolver IP 
> > addresses have any PTR records. I haven't ever seen Cloudflare document 
> > it like OpenDNS or Google.
> > 
> > With the above possible ways to retrieve the OpenDNS and Google data, 
> > you have the option to automate e.g. a weekly update of their resolver 
> > addresses, if you feel for something like that in any way. ;)
> > 
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop


-- 
Postmaster - postmas...@inter-corporate.com
Randolf Richardson - rand...@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Vancouver, British Columbia, Canada
https://www.inter-corporate.com/


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

Re: [mailop] New Google DNS Servers? 192.178.65.0/28 NO PTR records.. anyone? Brandon?

[Tony Maszeroski via mailop]

Hello,

I believe you can enumerate cloudflare IPs via :

https://www.cloudflare.com/ips-v4
https://www.cloudflare.com/ips-v6

It's likely an overfit situation (not just resolvers), but it's something.

-tony

On 12/2/23 21:57, Arne Jensen via mailop wrote:

Always happy to help! And wauh, times flies by these days...

First of all - I completely agree with you, that several things could be 
better here ;-).


Taking the four major ones, the top list, from best to worst, might be 
like:


1. OpenDNS
2. Google
3. Quad 9/PCH
4. Cloudflare

Given your mention of "internal documentation", maybe there could be 
something more for you to document, if you haven't already:


Google does, as mentioned previously, document their resolver 
infrastructure on the Web, contrary to many others, but also with a JSON:


-> API/JSON: https://www.gstatic.com/ipranges/publicdns.json

OpenDNS is also documenting theirs, and also have PTR on the outgoing 
resolver IP, but unfortunately, the PTR **doesn't always** point to one 
of their OpenDNS.* domain names, which could be confusing:


Reaching OpenDNS Copenhagen:
- 146.112.135.70 (r7.compute.cph1.edc.strln.net)
- 2a04:e4c0:17::73 (r10.compute.cph1.edc.strln.net)

Reaching OpenDNS London:
- 208.69.34.73 (m53.lon.opendns.com)
- 2a04:e4c0:10::91 (r3.compute.lon1.edc.strln.net)

It is however consistent with their locations as retrieved from here:

-> Web: https://www.opendns.com/data-center-locations/
-> JSON: 
https://umbrella-dns-requests.marketops.umbrella.com/api/data-center-locations


Currently, it seems very much a hit and miss, mostly miss, when reaching 
any IP address with PTR records, through Quad 9. I haven't ever seen 
Quad 9 document it like OpenDNS or Google.


With Cloudflare, I've never see any of their outbound resolver IP 
addresses have any PTR records. I haven't ever seen Cloudflare document 
it like OpenDNS or Google.


With the above possible ways to retrieve the OpenDNS and Google data, 
you have the option to automate e.g. a weekly update of their resolver 
addresses, if you feel for something like that in any way. ;)




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

Re: [mailop] Outlook.com losing eMail messages and SNDS reporting failures

[Gellner, Oliver via mailop]

On 2.12.2023 at 05:37 Randolf Richardson, Postmaster via mailop wrote:

> Some of my users have been reporting that eMail messages are getting lost 
> intermittently when they're sent to users at any internet domain name that 
> relies on OUTLOOK.COM for its MX.
> Our mail server logs confirm that all outbound messages were accepted to 
> those MX's (except for mistyped addresses or when a user's quota is 
> exhausted, in which case the usual SMTP rejections occur).  No bounces were 
> received.
> Users have also reported the same intermittent problems when sending from 
> other providers (including GMail, YahooMail, etc.).  No bounces were received 
> (as far as I know).

Do you see this issue when sending emails to Microsofts consumer domains 
(Hotmail, Outlook.com, Live, etc) or to their Office365 email infrastructure? 
I'm asking because with Office365 there might be filter rules in place which 
put the message in some quarantines that the user or even the tenant 
administrator is unaware of. In this case the message would not be lost, it 
only ended up in a place that the end user cannot access.

--
Best regards
Oliver Gellner


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