I don't receive emails ONLY on Apple devices

Gertjan

Well, yeah, no : I don't know what is in all those lists.
You (should !) know (before using them).

The mail service(s ?) that don't work anymore, who are they ?

@Unoptanio said in I don't receive emails ONLY on Apple devices:

fakenews

Yeah, I can imagine that a mail server might fall under that category ....

As said above : if pfBlockerng blocks for example "yahoo.com", you can see that happening on the Firewall > pfBlockerNG > Alerts page. You see also then which list contained the blocked host name.
You can unblock (whitelist) domains on the same Firewall > pfBlockerNG > Alerts page.

dennypage

@Unoptanio By default, Apple devices use Privacy Protection, which routes email access through a relay in order to hide the user’s IP address. The relay is probably appearing in the blacklist.

On a phone, the setting which controls this can be found in Settings -> Apps -> Mail -> Privacy Protection.

Gertjan

@dennypage said in I don't receive emails ONLY on Apple devices:

On a phone, the setting which controls this can be found in Settings -> Apps -> Mail -> Privacy Protection.

I'll have to play with that option.
Mine was not set of course, but what happens when it is set ?
Is this for sending mails ? Receiving ? Both ?

And why "hiding" mail traffic ?
There isn't (shouldn't be, were in 2025 now) be any mail traffic anymore that doesn't use TLS, so no MITM is possible between my phone, and the server at the other end.

Hiding what from the mail server to which I've send a mail ?
That's counter productive as if the receiving mail server can't check who I am - where the mail came from, change become bigger that the mail is treated as "less serious" thus the mail gets marked as spam or even discarded.

Anyway, me just thing out loud here, I'll set this option to on and see what happens.

edit : activating the option doesn't change anything for me.
I could send a mail to a gmail account just fine.
Still saw my Phone's IPv6 (a pfSense LAN prefix IPv6) in the mail headers.
I'm plowing through the mail headers right now, can't see anything obvious or new or different.

Is it this :

?

So before sending a mail, my phone needs to tell apple first where I'm sending to, receiving from ?
For my privacy ?

Qinn

It might be that Apple's iCloud Private Relay is blocked and if you add below to your whitelist and do an update in pfBlockerNG, you should recieve mail again

Good luck

.metrics.icloud.com # Apple mail block introduced with ios 18.2

dennypage

@Gertjan said in I don't receive emails ONLY on Apple devices:

And why "hiding" mail traffic ?
There isn't (shouldn't be, were in 2025 now) be any mail traffic anymore that doesn't use TLS, so no MITM is possible between my phone, and the server at the other end.

It's not about the content, it's about tracking. In short, senders of emails place content links in emails sent to you. When you access the email, the sender can see the IP address(s) that are used to retrieve the content. The IP address information allows for tracking of your physical location. The relay addresses this by routing all content retrieval through a privacy proxy.

Gertjan

@dennypage said in I don't receive emails ONLY on Apple devices:

senders of emails place content links in emails sent to you. When you access the email, the sender can see the IP address(s) that are used to retrieve the content. The IP address information allows for tracking of your physical location

The famous white 1x1 pixel image present in a mail ... I know.

That issue has been solved many years ago
Example : my mail client (Outlook 365) shows this :

Based of who sends the mail == who I think was sending the mail and the content .... publicity of course in this case, it's "Delete" right away.

@dennypage said in I don't receive emails ONLY on Apple devices:

The relay addresses this by routing all content retrieval through a privacy proxy

Ah, the interesting part. Thanks.
So, when using this functionality on the iDevice, the mail client will access all URLs in a mail using some Apple proxy.
If this proxy - most probably know by the iOS with a host name, is blocked by pfBlockerng, then loading te images in a mail becomes impossible.
Still, the mail app in the iPhone would show == receive the mails ....
This doesn't check with the subject of this thread :

I don't receive emails ONLY on Apple devices

where @Unoptanio says he/she can't retrieve the mails == she/he can't access his mail server ... (I guess - posed questions are still unanswered )

dennypage

@Gertjan said in I don't receive emails ONLY on Apple devices:

The famous white 1x1 pixel image present in a mail ... I know.

That issue has been solved many years ago

Not the infamous 1 pixel image used on websites. This is usually general, required content. Real images, present in almost all commercial messages, without which the email does not render properly. Like the name of the sender as an image, signature lines, etc. You probably see dozens per day without noticing. Install something like Little Snitch if you want to see what's all going on behind the scenes.

Unoptanio

@dennypage
Mail cannot function in IOS 18.2 if iCloud Private Relay is blocked at a network level

https://discussions.apple.com/thread/255916395?sortBy=rank

mask.icloud.com
mask-h2.icloud.com

johnpoz

@Unoptanio maybe for apple (icloud) mail? But gmail mail works just fine on my iphone and tablet with those blocked..

; <<>> DiG 9.16.50 <<>> mask.icloud.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5949
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

; <<>> DiG 9.16.50 <<>> mask-h2.icloud.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 42606
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

dennypage

@Unoptanio said in I don't receive emails ONLY on Apple devices:

Mail cannot function in IOS 18.2 if iCloud Private Relay is blocked at a network level

https://discussions.apple.com/thread/255916395?sortBy=rank

This reference is/was out of date. The linked discussion referrers to a specific bug introduced iOS 18.2 (December 11, 2024), which was corrected in iOS 18.3 (January 27, 2025). Apple stopped signing of 18.2.X a week later, almost 2 months before this thread began.