Re: [mailop] Microsoft SNDS website not working

[Scott Mutter via mailop]

Yea, the authorization emails aren't coming through.  I don't know if they
aren't being sent or if they're being stopped some where else.  But it's
been 10 hours and I still haven't received the authorization verification
email.

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

Re: [mailop] [E] Mail Rejected by Yahoo/Prodigy DNSBL:RBL 521

[Lili Crowley via mailop]

Please contact me off list.

Thanks!
Lili



*Lili Crowley*

she/her

Postmaster








On Thu, Jun 6, 2024 at 9:08 PM Joe Muller via mailop 
wrote:

> I'm looking for help from what I assume to the Yahoo mail team - our
> Mailing List server at 64.142.105.165 (lists.sonic.net) is being blocked
> by the following servers:
>
> al-ip4-mx-vip1.prodigy.net
> al-ip4-mx-vip2.prodigy.net
> ff-ip4-mx-vip1.prodigy.net
> ff-ip4-mx-vip2.prodigy.net
>
> Here is an example log line from our sendmail instance:
>
> Jun  6 17:33:49 listman.sonic.net sendmail[30018]: 4570XhGQ029645:
> to=, delay=00:00:01, xdelay=00:00:01,
> mailer=esmtp, pri=211884, relay=ff-ip4-mx-vip2.prodigy.net.
> [144.160.159.22], dsn=5.6.0, reply=553 5.3.0 flph831 DNSBL:RBL 521<
> 64.142.105.165 >_is_blocked.For assistance forward this error to
> abuse_...@abuse-att.net, stat=Data format error
>
> Our same customer has reported this issue on May 8th and May 21st, so
> this is the third time I have had to request removal of a block. Each
> time, a consultation of the Spamhaus lookup service did not show our IP
> address on any RBL.
>
> If someone on this list can please reach out to me directly, I'd like to
> get an explanation as to why we keep getting blocked and what we can do
> to fix any outstanding problems.
>
> -- Joe Muller
> System Administrator
> Sonic.
>
> ___
> mailop mailing list
> mailop@mailop.org
>
> https://urldefense.com/v3/__https://list.mailop.org/listinfo/mailop__;!!Op6eflyXZCqGR5I!AoAbPwwkGYaD3fK23LzQIfoIoMAPdJJZe9F_GrDfrmCuhwFWV7jAJ92FHQlhtsZzEp-tTPeA05gW74HN1TY$
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mail Rejected by Yahoo/Prodigy DNSBL:RBL 521

[Jeff P via mailop]

Hi

ATT has their own RBL list which they don't share with you.
Once your email server gets tagged by them, please contact the email address:
abuse_...@abuse-att.net
to submit your question. They are kindly enough to reply you manually.
(just from my experience from ATT/SBC).

regards.



> 
> I'm looking for help from what I assume to the Yahoo mail team - our 
> 
> Mailing List server at 64.142.105.165 (lists.sonic.net) is being blocked 
> 
> by the following servers:
> 
> al-ip4-mx-vip1.prodigy.net
> 
> al-ip4-mx-vip2.prodigy.net
> 
> ff-ip4-mx-vip1.prodigy.net
> 
> ff-ip4-mx-vip2.prodigy.net
> 
> Here is an example log line from our sendmail instance:
> 
> Jun  6 17:33:49 listman.sonic.net sendmail[30018]: 4570XhGQ029645: 
> 
> to=, delay=00:00:01, xdelay=00:00:01, 
> 
> mailer=esmtp, pri=211884, relay=ff-ip4-mx-vip2.prodigy.net. 
> 
> [144.160.159.22], dsn=5.6.0, reply=553 5.3.0 flph831 DNSBL:RBL 521< 
> 
> 64.142.105.165 >_is_blocked.For assistance forward this error to 
> 
> abuse_...@abuse-att.net, stat=Data format error
> 
> Our same customer has reported this issue on May 8th and May 21st, so 
> 
> this is the third time I have had to request removal of a block. Each 
> 
> time, a consultation of the Spamhaus lookup service did not show our IP 
> 
> address on any RBL.
> 
> If someone on this list can please reach out to me directly, I'd like to 
> 
> get an explanation as to why we keep getting blocked and what we can do 
> 
> to fix any outstanding problems.
> 
> -- Joe Muller
> 
> System Administrator
> 
> Sonic.
> 
> ___
> 
> mailop mailing list
> 
> mailop@mailop.org
> 
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Mail Rejected by Yahoo/Prodigy DNSBL:RBL 521

[Joe Muller via mailop]

I'm looking for help from what I assume to the Yahoo mail team - our 
Mailing List server at 64.142.105.165 (lists.sonic.net) is being blocked 
by the following servers:


al-ip4-mx-vip1.prodigy.net
al-ip4-mx-vip2.prodigy.net
ff-ip4-mx-vip1.prodigy.net
ff-ip4-mx-vip2.prodigy.net

Here is an example log line from our sendmail instance:

Jun  6 17:33:49 listman.sonic.net sendmail[30018]: 4570XhGQ029645: 
to=, delay=00:00:01, xdelay=00:00:01, 
mailer=esmtp, pri=211884, relay=ff-ip4-mx-vip2.prodigy.net. 
[144.160.159.22], dsn=5.6.0, reply=553 5.3.0 flph831 DNSBL:RBL 521< 
64.142.105.165 >_is_blocked.For assistance forward this error to 
abuse_...@abuse-att.net, stat=Data format error


Our same customer has reported this issue on May 8th and May 21st, so 
this is the third time I have had to request removal of a block. Each 
time, a consultation of the Spamhaus lookup service did not show our IP 
address on any RBL.


If someone on this list can please reach out to me directly, I'd like to 
get an explanation as to why we keep getting blocked and what we can do 
to fix any outstanding problems.


-- Joe Muller
System Administrator
Sonic.

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

Re: [mailop] Debugging fwd issue meta.com to zoho.com (Help from user under meta.com needed)

[Richard Clayton via mailop]

In message ,
Tobias Fiebig via mailop  writes

>My point here is, that 'deliverability' is often more of a priority for

>ESPs than 'following all documents to the letter'. Granted, for the

>bigger ones, usually more like 'outbound deliverability' than 'inbound

>deliverability', though.

>
>Hence, I am not completely sure if the stance is outright unreasonable,

>even if it disagrees with the documents.

If you send an encoded DKIM header field then it is rather unlikely that
large mailbox providers will parse it correctly (I don't think they run
rpamd) or indeed at all.

Failure to get a "DKIM pass" may well mean that "no auth no entry"
(recall that 1 Feb was a while back) will kick in and your
deliverability will be zero.

The likelihood of getting an error message that illuminates the (rather
obscure) cause of the deliverability failure is zero.

Recall that the first thing Postel said was "be conservative in what you
send".

BTW: RFC2047 encoding the bit in the angle brackets in the RFC5322 From
(which a non-zero number of senders were doing, last I looked at
$DAYJOB$ data) will also mean no deliverability (albeit some of the
error messages you get for that may lead you to your formatting problem
relatively quickly).

-- 
richard   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755


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

Re: [mailop] Microsoft SNDS website not working

[Scott Mutter via mailop]

I'm still not getting the authorization emails.  But maybe that's just me.
I seem to recall that these emails aren't instant and sometimes take
several hours to come in.

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

Re: [mailop] Microsoft SNDS website not working

[Mark Fletcher via mailop]

On Thu, Jun 6, 2024 at 9:11 AM Scott Mutter via mailop 
wrote:

> Trying to add an IP address to our SNDS accounts at:
>
> https://sendersupport.olc.protection.outlook.com/snds/index.aspx
>
> Is resulting in a lot of failed page loads, a lot of having to refresh,
> authorization emails seemingly not being sent.
>
> I have experienced that off and on over the past several months. However,
it did just now work for me.


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

[mailop] Microsoft SNDS website not working

[Scott Mutter via mailop]

Trying to add an IP address to our SNDS accounts at:

https://sendersupport.olc.protection.outlook.com/snds/index.aspx

Is resulting in a lot of failed page loads, a lot of having to refresh,
authorization emails seemingly not being sent.

Anyone else having issues with Microsoft's SNDS site?  Is this a known
issue?

Anyone from Microsoft want to investigate these issues?
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] comcast.net & DMARC policy

[Brotman, Alex via mailop]

Hello folks,

For a few reasons, we're going to be changing the policy for "comcast.net", as 
well as the default subdomain policy.   We're going to target July 15th, 2024 
as the first change.  Approximately on that day, we will change to p=quarantine 
and sp=reject.  We do understand this will have some impact on users who are 
utilizing third-party services to send messages as "comcast.net", as well as 
some participating in mailing lists. 

-- 
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
 

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

Re: [mailop] Email connection timeouts from Proofpoint (67.231.157.0/24) to my Aussie Broadband static IP (mx1.imrryr.org[144.6.86.210])

[Mike Reed via mailop]

Hi,

I think it's not an email issue but a routing one.

Zayo in Sydney shows:
? 67.231.157.0/24B 170120 4294967294  38195
19551 22843 I
  unverified   >203.153.18.37
  ?B 170120 3491
19551 22843 I
  unverified   >64.125.28.18
64.125.28.50

AussieBB in Hawthorn shows:
 Advertised IPv4 Unicast paths to peers (in unique update groups):
61.245.147.114
  19551 26211 209 3356 1299 19551 22843

It's not wrong, but it's weird.

AussieBB's router in LA has some decent routes to Proofpoint over
Arelion and Cogent but doesn't advertise them to peers :(

Best of luck,

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

Re: [mailop] Debugging fwd issue meta.com to zoho.com (Help from user under meta.com needed)

[Viktor Dukhovni via mailop]

On Thu, Jun 06, 2024 at 10:23:28AM +0200, Tobias Fiebig via mailop wrote:

> > To a degree, but not to the point of accepting total garbage
> > (RFC2047-encoded DKIM-Signature headers), or especially, generating
> > total garbage (producing RFC2047-encoded DKIM-Signature headers).
> 
> Just to clarify here: rspamd creates correct DKIM signatures when
> working as a signer; The broken DKIM sig was somebody else's
> accomplishment. rspamd ingested it and was ably to verify it.

That level of bending over backwards to tolerate garbage is generally
counterproductive.  Instead treat the message as not signed (by any
domains in mangled DKIM-Signature headers).

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

Re: [mailop] Debugging fwd issue meta.com to zoho.com (Help from user under meta.com needed)

[Tobias Fiebig via mailop]

Moin,

On Thu, 2024-06-06 at 17:53 +1000, Viktor Dukhovni via mailop wrote:
> It is also, IIRC, a DKIM *signer* and verifier.  DKIM signing and
> verification needs to interoperate.
> ...
> To a degree, but not to the point of accepting total garbage
> (RFC2047-encoded DKIM-Signature headers), or especially, generating
> total garbage (producing RFC2047-encoded DKIM-Signature headers).

Just to clarify here: rspamd creates correct DKIM signatures when
working as a signer; The broken DKIM sig was somebody else's
accomplishment. rspamd ingested it and was ably to verify it.

With best regards,
Tobias

-- 
Dr.-Ing. Tobias Fiebig
T +31 616 80 98 99
M tob...@fiebig.nl

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

Re: [mailop] Email connection timeouts from Proofpoint (67.231.157.0/24) to my Aussie Broadband static IP (mx1.imrryr.org[144.6.86.210])

[Mark Delany via mailop]

On 06Jun24, Viktor Dukhovni via mailop apparently wrote:

> > I'd also raise it with Aussie Broadband and see if they are able to

I too raised a ticket with ABB as I accidentally discovered that 
67.231.157.0/24 was not
able to reach my mail servers on the ABB network. Fortunately in enough time 
before the
queues timed out.

At this stage the ticket has moved from their L1 front-line to their L2 NOC, so 
maybe a
fix is in sight.

The easiest way to confirm this reachability issue is with
http://lg.aussiebroadband.com.au which shows that, e.g., 67.231.157.237 is not 
reachable
from BNE NextDC, but is reachable from SIN Equinix DC. Clearly a systemic issue.


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

Re: [mailop] Debugging fwd issue meta.com to zoho.com (Help from user under meta.com needed)

[Viktor Dukhovni via mailop]

On Thu, Jun 06, 2024 at 08:38:48AM +0100, Vsevolod Stakhov via mailop wrote:

> > Such willful disregard of essential interoperability requirements in
> > "rspamd" means I will not use it unless you back off from your current
> > position, and will strongly discourage others (e.g. postfix-users list
> > readers) from using it.  I've heard "rspamd" otherwise has some
> > appealing features, but this is show-stopper. :-(
> > 
> 
> I'm sorry but I do not accept the interoperability argument in this context.
> Rspamd is not an MTA - it is a spam filtering system.

It is also, IIRC, a DKIM *signer* and verifier.  DKIM signing and
verification needs to interoperate.

> Hence, it has to work *somehow* with broken and non-conformant emails.
> I've seen so many messages with bad mime structure, bad headers
> encoding, broken received traces etc.

To a degree, but not to the point of accepting total garbage
(RFC2047-encoded DKIM-Signature headers), or especially, generating
total garbage (producing RFC2047-encoded DKIM-Signature headers).

> What I wanted to say by this message is that complications in the standards
> lead to ambiguity in the implementations (as they , which, in turn, lead to
> the possibilities for spammers to exploit those implementation issues. I'm
> not even talking about the standard that are ambiguous by design, e.g. DKIM
> simple canonicalization.

I am well aware of the issues.  I wrong a MIME-normaliser circa Y2K that
too questionable MIME in, and produced unambiguous MIME out.  But
unambiguous did not mean bending over backwards to accommodate total
garbage.  Rather, in many cases, just neuter it so that downstream tools
are not going to be confused.  And certainly, not to produce output that
violates the specs.

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

Re: [mailop] Debugging fwd issue meta.com to zoho.com (Help from user under meta.com needed)

[Tobias Fiebig via mailop]

Moin,

On Thu, 2024-06-06 at 12:44 +1000, Viktor Dukhovni via mailop wrote:
> The distinction is essential, because it would be a terrible mistake
> to, for example, RFC2047-encode the "mailbox" construct in "From",
> "To", ... headers.  An RFC2047-ignorant MUA or MTA can still
> correctly decode the addresses in those headers without caring about
> the display name encoding.

Kind of a point; However, if I got John correctly, an SMTPUTF8 mail
having to go through a system that does not support it should simply
bounce?

On Wed, 2024-06-05 at 11:00 +0200, John R Levine via mailop wrote:
> Nope.  You cannot downgrade a SMTUTF8 message to an ASCII message. 
> The experimental versions of EAI tried to do that and it never worked
> so they took it out of the standards track EAI RFCs.

To be fair... if my students working on 'normal' security stuff
complain about things being to confusing, inconsistent, and complex...
I threaten them with the proposition that they could _also_ be working
on DNS. If those working on DNS complain, I suggest they could also do
BGP instead.

Now, if the ones working on BGP complain, I threaten them with the
prospect of working on mail.

And if the ones working on mail complain... I usually just say "I'm
sorry; At least look at the bright side: It can't get worse." ;-)

(This is a joke.)

On Thu, 2024-06-06 at 12:44 +1000, Viktor Dukhovni via mailop wrote:
> It seems to me, that you may not have thought through the issues
> deeply enough.

I would, indeed, argue that this issue has a few more facets that need
to be discussed; With some of those potentially being somewhat
supportive of Vsevolod's point.

On Thu, 2024-06-06 at 12:44 +1000, Viktor Dukhovni via mailop wrote:
> On Wed, 2024-06-05 at 17:29 +0100, Vsevolod Stakhov via mailop wrote:
> > As Rspamd author, I will not change the existing logic, as it works
> > with headers as with black boxes making the following steps: unfold
> > -> rfc2047 decode -> process specific data.
> 
> This, IMNSHO, is not a reasonable stance to take...

I am not so sure, at least IMSSANSMBLAHSIDTO (in my somewhat-stupid-
and-not-so-my-but-looking-at-how-some-implementations-do-this opinion)
the sketched approach is also how, e.g., Python handles RFC2047
headers. In fact, it was somewhat messy to convince python to rewrite
an RFC2047-ized DKIM header to not mime encoded text, as the email
module would read the header correctly, print it in ASCII/UTF8, but
writes it back mime encoded (this is for email-security-scans.org; So a
specific case sometimes requiring doing weird things not advisable
anywhere else, i.e., here the rewriting.).

On Thu, 2024-06-06 at 12:44 +1000, Viktor Dukhovni via mailop wrote:
> Such willful disregard of essential interoperability requirements...

To be fair, rspamd was the _more_ interoperable mail handling software
in this case.

> I've heard "rspamd" otherwise has some appealing features, but this
> is show-stopper. :-(

It does. Especially when it comes to DKIM (ed25519 support, not
injecting funny whitespaces breaking signatures), ARC (well, it _does_
ARC, contrary to many other implementations), DMARC reporting (which
also tends to be more slim in other implementations) etcetc. And,
contrary to many other milters, it is really scalable. So, personally,
big fan of rspamd.

So, the stance, which I would abbreviate as 'in case of doubt, I do
anything to get an email reliably processed and delivered' is not only
Vsevolod's; In fact, Gmail--for example--also tends to be 'a bit more
lenient' to get an (outbound) email delivered. Including, up until
recently, 'ignore DNSSEC being broken' (even though that _does_ seem to
have changed, at least when testing this morning; Or it is attached to
a timer for a domain, i.e., if a domain has been seen with working
DNSSEC for $time, it starts to get enforced; Anyway, tangential.).

My point here is, that 'deliverability' is often more of a priority for
ESPs than 'following all documents to the letter'. Granted, for the
bigger ones, usually more like 'outbound deliverability' than 'inbound
deliverability', though.

Hence, I am not completely sure if the stance is outright unreasonable,
even if it disagrees with the documents. After all, the 'drift' between
documents and 'what is being done on the wire' has been getting larger
for some time already. And if I have the choice between 'no commits for
six years' (OpenDKIM; Good candidate for next xz, imho, btw.),
'something involving python' (dkimpy), and rspamd, I am somewhat
inclined to use rspamd, i.e., there is not that many alternatives to
recommend, when recommending people not to use rspamd.

(The last comment is observational concerning that drift, and not a
suggestion to outright change the documents, a call for rspamd to
change, or a statement in support for either direction; I am marveling
the problem, suggesting that this drift might need some discussion
(again), and ultimately, some form of approach to fix it.)

With best 

Re: [mailop] Debugging fwd issue meta.com to zoho.com (Help from user under meta.com needed)

[Vsevolod Stakhov via mailop]

On 06/06/2024 03:44, Viktor Dukhovni via mailop wrote:

On Wed, Jun 05, 2024 at 05:29:16PM +0100, Vsevolod Stakhov via mailop wrote:


In fact, the original distinction between structured and unstructured
headers defined in the RFC2047 just makes parsing extremely complicated and
I personally consider it as an example of a standard being accepted with a
clear violation of KISS principle for no good reason.


The distinction is essential, because it would be a terrible mistake to,
for example, RFC2047-encode the "mailbox" construct in "From", "To", ...
headers.  An RFC2047-ignorant MUA or MTA can still correctly decode the
addresses in those headers without caring about the display name
encoding.


Unfortunately, SMTPUTF8 makes it even worse as instead of following
something that works (e.g. punycode) it creates a completely different state
machine for parsing messages otherwise indistinguishable from generic ASCII
compatible emails.


It seems to me, that you may not have thought through the issues deeply
enough.


As Rspamd author, I will not change the existing logic, as it works with
headers as with black boxes making the following steps: unfold -> rfc2047
decode -> process specific data.


This, IMNSHO, is not a reasonable stance to take...

Such willful disregard of essential interoperability requirements in
"rspamd" means I will not use it unless you back off from your current
position, and will strongly discourage others (e.g. postfix-users list
readers) from using it.  I've heard "rspamd" otherwise has some
appealing features, but this is show-stopper. :-(



I'm sorry but I do not accept the interoperability argument in this 
context. Rspamd is not an MTA - it is a spam filtering system. Hence, it 
has to work *somehow* with broken and non-conformant emails. I've seen 
so many messages with bad mime structure, bad headers encoding, broken 
received traces etc. And in all the cases MUAs were able somehow to show 
that apparent spam/phishing to the end users. For example, one spam 
campaign has used '\0' character in messages, as this character is 
silently removed and ignored by Microsoft Outlook.


What I wanted to say by this message is that complications in the 
standards lead to ambiguity in the implementations (as they , which, in 
turn, lead to the possibilities for spammers to exploit those 
implementation issues. I'm not even talking about the standard that are 
ambiguous by design, e.g. DKIM simple canonicalization.

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

Re: [mailop] Apple/iCloud message blocking

[Suresh Ramasubramanian via mailop]

That is the postmaster address for icloud so yes.

The team will respond.

Please see https://support.apple.com/en-us/HT204137

--srs

From: mailop  on behalf of Jeff P via mailop 

Sent: Thursday, June 6, 2024 12:08:37 PM
To: mailop@mailop.org 
Subject: Re: [mailop] Apple/iCloud message blocking

My message sent to icloud was lost siliently. Neither returned message nor 
message in icloud inbox/spam.
I can provide the sender and other recipient details, and/or mail.log.
Can I write to this email icloudad...@apple.com as well?

Thanks.


>
> Day 3 - still no response from icloudad...@apple.com.
>
> Guessing there's nobody from Apple or iCloud is on this list.
>
> And nobody at Apple/iCloud really cares.
>
___
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] Email connection timeouts from Proofpoint (67.231.157.0/24) to my Aussie Broadband static IP (mx1.imrryr.org[144.6.86.210])

[Viktor Dukhovni via mailop]

On Mon, Jun 03, 2024 at 09:41:45PM +0930, Joseph B via mailop wrote:

> > I am also unable to ping the sending machine from "mx1.imrryr.org", 
> > while it is pingable from Munich and LA:
> 
> Ripe ATLAS probes on Aussie Broadband are also unable to ping the host you 
> mentioned, while other AU ISPs are just fine.
> 
> https://atlas.ripe.net/measurementdetail/72982362/results

Thanks for the probe data.

> I'd also raise it with Aussie Broadband and see if they are able to
> contact the Imperva or Proofpoint NOCs to confirm what they see from
> their view point. I wasn't able to find a public looking glass in
> either of those networks to check.

I've opened a ticket with Aussie BB that includes the above link.
Perhaps they'll take a look, though it is possible they'll decide it is
not a priority for them...

I've added a backup MX in the UK, and the affected Proofpoint mail is
now getting routed there, and relayed hence down under.  I am not
optimistic that the connectivity problem will be addressed any time
soon. :-(

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

Re: [mailop] Apple/iCloud message blocking

[Jeff P via mailop]

My message sent to icloud was lost siliently. Neither returned message nor 
message in icloud inbox/spam.
I can provide the sender and other recipient details, and/or mail.log.
Can I write to this email icloudad...@apple.com as well?

Thanks.


> 
> Day 3 - still no response from icloudad...@apple.com.
> 
> Guessing there's nobody from Apple or iCloud is on this list.
> 
> And nobody at Apple/iCloud really cares.
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Apple/iCloud message blocking

[Suresh Ramasubramanian via mailop]

I will have the team check

--srs

From: mailop  on behalf of Scott Mutter via mailop 

Sent: Thursday, June 6, 2024 11:02:03 AM
To: mailop@mailop.org 
Subject: Re: [mailop] Apple/iCloud message blocking


On Wed, Jun 5, 2024 at 10:43 PM Suresh Ramasubramanian 
mailto:ops.li...@gmail.com>> wrote:
What address did you send it from? We don’t seem to see any email from your 
address so can you please resend it.


--srs

postmas...@olympic.wznoc.com

The apple.com mail server doesn't return any traceable 
message id upon message acceptance, but my logs show the message being accepted 
with a  250 2.5.0 Ok response.

First message:
2024-06-03 14:03:49.293 [1314] 1sECyA-LB-0l => 
icloudad...@apple.com 
F=mailto:postmas...@olympic.wznoc.com>> 
P=mailto:postmas...@olympic.wznoc.com>> 
R=dkim_lookuphost T=dkim_remote_smtp S=2669 
H=mx-in.g.apple.com [17.32.222.242]:25 
I=[205.251.153.98]:48242 X=TLS1.2:ECDHE-RSA-AES128-GCM-SHA256:128 CV=yes 
DN="/C=US/ST=California/O=Apple 
Inc./CN=mx-in.g.apple.com" L C="250 2.5.0 Ok" 
QT=2.995s DT=2.813s

Second message:
2024-06-05 09:34:33.460 [37726] 1sErif-0009oT-2Q => 
icloudad...@apple.com 
F=mailto:postmas...@olympic.wznoc.com>> 
P=mailto:postmas...@olympic.wznoc.com>> 
R=dkim_lookuphost T=dkim_remote_smtp S=2587 
H=mx-in.g.apple.com [17.32.222.242]:25 
I=[205.251.153.98]:60066 X=TLS1.2:ECDHE-RSA-AES128-GCM-SHA256:128 CV=yes 
DN="/C=US/ST=California/O=Apple 
Inc./CN=mx-in.g.apple.com" L C="250 2.5.0 Ok" 
QT=3.655s DT=3.494s
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop