date:20230921

Re: [mailop] Apple/icloud blocking - Message rejected due to local policy

2023-09-21 Thread Suresh Ramasubramanian via mailop

Ok we will check

--srs

From: mailop  on behalf of Scott Mutter via mailop 

Sent: Thursday, September 21, 2023 10:23:15 PM
To: mailop@mailop.org 
Subject: Re: [mailop] Apple/icloud blocking - Message rejected due to local 
policy

Message sent again - today, 2023-09-21 11:51AM CDT.

Subject of the message is - 209.236.124.55 IP Blacklisted

I sent the message to icloudad...@apple.com and 
CC'd s...@apple.com

On Thu, Sep 21, 2023 at 9:46 AM Suresh Ramasubramanian 
mailto:ops.li...@gmail.com>> wrote:

Can you resend your message to postmaster with a recent sample of the logs? Bcc 
me at s...@apple.com so I can follow up with the team.

From: mailop mailto:mailop-boun...@mailop.org>> on 
behalf of Scott Mutter via mailop mailto:mailop@mailop.org>>
Date: Thursday, 21 September 2023 at 8:00 PM
To: mailop@mailop.org 
mailto:mailop@mailop.org>>
Subject: Re: [mailop] Apple/icloud blocking - Message rejected due to local 
policy

How long should I have to wait for a response?

I haven't heard anything back and icloud is still rejecting the message due to 
local policy.

On Tue, Sep 19, 2023 at 9:07 AM Suresh Ramasubramanian 
mailto:ops.li...@gmail.com>> wrote:

I will have the team check and reply to you

From: Scott Mutter 
mailto:mailopl...@amssupport.info>>
Date: Tuesday, 19 September 2023 at 6:28 PM
To: Suresh Ramasubramanian mailto:ops.li...@gmail.com>>
Subject: Re: [mailop] Apple/icloud blocking - Message rejected due to local 
policy

I wrote icloudad...@apple.com on August 26, 2023.

Message was from 
postmas...@thoroughbred.wznoc.com

Subject of the message was - 209.236.124.55 IP Blacklisted

Just tried resending a message from this server, same error message:

 554 5.7.1 [HM08] Message rejected due to local policy. Please visit 
https://support.apple.com/en-us/HT204137

On Tue, Sep 19, 2023 at 2:08 AM Suresh Ramasubramanian 
mailto:ops.li...@gmail.com>> wrote:

Hi

What address did you email icloudadmin from?

I don’t see any current blocks on your IP

--srs

From: Suresh Ramasubramanian mailto:ops.li...@gmail.com>>
Sent: Tuesday, September 19, 2023 10:33:52 AM
To: Scott Mutter 
mailto:mailopl...@amssupport.info>>; 
mailop@mailop.org 
mailto:mailop@mailop.org>>
Subject: Re: [mailop] Apple/icloud blocking - Message rejected due to local 
policy

I’ll have someone look at your email and reply if they haven’t yet

--srs

From: mailop mailto:mailop-boun...@mailop.org>> on 
behalf of Scott Mutter via mailop mailto:mailop@mailop.org>>
Sent: Tuesday, September 19, 2023 9:11:02 AM
To: mailop@mailop.org 
mailto:mailop@mailop.org>>
Subject: [mailop] Apple/icloud blocking - Message rejected due to local policy

Anybody from Apple/iCloud able to provide any insight as to why messages from 
209.236.124.55 are being blocked with - Message rejected due to local policy 
messages?

I previously sent a message to 
icloudad...@apple.com but got no response.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] New Validity policy for paid FBL (ARF)

2023-09-21 Thread Steve Freegard via mailop

Hi Mike,

Aside from stating categorically that we're not interested in monetizing
the reports like Validity are doing, the only other thing I can suggest is
that you look at the history of what we've done in the past.   We've
provided the Abuse ContactDB as a free service for well over 10 years (used
by many places including Fail2Ban etc.), we've contributed XARF to the
community and are providing Global Reporting, which is a free Abuse
Reporting Service (of which we'll be using 99% of the code already written
to implement this Feedback Loop functionality).

The whole point about backing the Draft RFC is also to open it up as much
as possible.   The current state means that you either pay Validity or you
don't get anything, period.  They have the current monopoly and zero
competition which is why they can do this in the first place.

I'd also like to point out that there is absolutely no guarantee that any
mailbox providers will come across to us either; that will take persuasion
from the industry, but we make it as easy as possible with this
service, they're effectively swapping one email address with another.  Why
would a mailbox provider, right now, bother to put the development time
into implementing a draft RFC that (at the time of writing) only two
entities are using? (CleverReach and Onmivary with ActiveCampaign to follow
soon), they would also have the on-going management and approval of new
CFBL-Addresses to deal with as well.

The point is; we can implement this pretty quickly with a few code changes
on our end to something we've already been working on for months and
provide an alternative to Validity and help get the draft RFC more widely
implemented - at which point with much wider adoption, it makes it far more
easy (and therefore likely) for mailbox providers to implement this
themselves if they wish to, or for other entities to offer a similar
service should they choose.

That's surely better than the current status quo and sitting back and doing
nothing, right?

Kind regards,
Steve.

On Thu, 21 Sept 2023 at 20:43, Mike Hillyer  wrote:

> I think the first question anyone will ask is "How do we know that Abusix
> won't eventually become Validity 2: the Abusix Remix"? I do like the idea
> of pushing the RFC, but if you're in the middle many of those MBPs will
> likely defer to a new middle-man to handle the implementation, and we're
> back at a single vendor.
>
> Mike
> --
> *From:* mailop  on behalf of Steve Freegard
> via mailop 
> *Sent:* Thursday, September 21, 2023 12:05 PM
> *To:* Support 3Hound 
> *Cc:* mailop@mailop.org 
> *Subject:* Re: [mailop] New Validity policy for paid FBL (ARF)
>
> Just saw this thread; I published this earlier today and we're likely
> going to discuss it at M3AAWG:  https://abusix.com/feedback-loops/
>
> TLDR; Abusix is willing to take this on and provide it as a free service
> from any mailbox provider that wishes to participate, but we'll do it based
> on the Independent RFC Draft using CFBL-Address, so we don't just end up
> swapping out Validity for us, we help adopt a standard that any mailbox
> provider can use going forward if they wish.
> Putting us in the middle just means that we take on the burden of
> processing, wrapping and delivering the reports and approving the
> CFBL-Addresses that can receive them and producing some high-level
> statistics that might be interesting at the same time.
>
> Kind regards,
> Steve.
>
>
> On Mon, 11 Sept 2023 at 12:29, Support 3Hound via mailop <
> mailop@mailop.org> wrote:
>
> Dear list,
> I would like to understand what the community think about the new Validity
> universal feedback loop service that is switching to a paid service
> starting 21 September 2023.
>
> As Validity worked in the the last years to achieve the management of the
> FBL service from all the "main" country-level and international mailbox
> providers (as the "universal" word suggest), I think that this new policy
> is unfair and a very bad news for the mail operators community.
>
> During years the FBL became a kind of "safe feature" for users that prefer
> to click "junk" or "spam" and be sure they will not receive anymore.
>
> The "one click unsubscribe/ List-unsubscribe header" should be the right
> way to do that... true! But this is not the focus, everyone know that FBL
> are -de facto- used like that from users and that they are honored from
> correct sender.
>
> FBL generates also a good data flow for the mailbox provider that may
> filter the "next e-mail" from a sender that don't honor the FBL (or can't
> act realtime the unsubcribe) generating a better service for the end user
> and a way to identify good player and bad ones.
>
> Switching to a paid service bring these metrics to fails; rich spammer may
> easily honor them getting a better reputation than a little correct player.
>
> It also means that it's needed to buy a paid service from a private
> company to follows best practices, something that

Re: [mailop] Proofpoint Contact

2023-09-21 Thread Jaren Angerbauer via mailop

On Thu, Sep 21, 2023 at 12:45 PM Troy via mailop  wrote:

> Does anyone have proofpoint contact info? I have requested to have an ip
> delisted from one of their lists and haven't heard anything back and the ip
> is still being blocked.
>
> Thanks,
> Troy
>

Sent a private reply to Troy.

Thanks,

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

Re: [mailop] New Validity policy for paid FBL (ARF)

2023-09-21 Thread Mike Hillyer via mailop

I think the first question anyone will ask is "How do we know that Abusix won't 
eventually become Validity 2: the Abusix Remix"? I do like the idea of pushing 
the RFC, but if you're in the middle many of those MBPs will likely defer to a 
new middle-man to handle the implementation, and we're back at a single vendor.

Mike

From: mailop  on behalf of Steve Freegard via mailop 

Sent: Thursday, September 21, 2023 12:05 PM
To: Support 3Hound 
Cc: mailop@mailop.org 
Subject: Re: [mailop] New Validity policy for paid FBL (ARF)

Just saw this thread; I published this earlier today and we're likely going to 
discuss it at M3AAWG:  https://abusix.com/feedback-loops/

TLDR; Abusix is willing to take this on and provide it as a free service from 
any mailbox provider that wishes to participate, but we'll do it based on the 
Independent RFC Draft using CFBL-Address, so we don't just end up swapping out 
Validity for us, we help adopt a standard that any mailbox provider can use 
going forward if they wish.
Putting us in the middle just means that we take on the burden of processing, 
wrapping and delivering the reports and approving the CFBL-Addresses that can 
receive them and producing some high-level statistics that might be interesting 
at the same time.

Kind regards,
Steve.


On Mon, 11 Sept 2023 at 12:29, Support 3Hound via mailop 
mailto:mailop@mailop.org>> wrote:
Dear list,
I would like to understand what the community think about the new Validity 
universal feedback loop service that is switching to a paid service starting 21 
September 2023.

As Validity worked in the the last years to achieve the management of the FBL 
service from all the "main" country-level and international mailbox providers 
(as the "universal" word suggest), I think that this new policy is unfair and a 
very bad news for the mail operators community.

During years the FBL became a kind of "safe feature" for users that prefer to 
click "junk" or "spam" and be sure they will not receive anymore.

The "one click unsubscribe/ List-unsubscribe header" should be the right way to 
do that... true! But this is not the focus, everyone know that FBL are -de 
facto- used like that from users and that they are honored from correct sender.

FBL generates also a good data flow for the mailbox provider that may filter 
the "next e-mail" from a sender that don't honor the FBL (or can't act realtime 
the unsubcribe) generating a better service for the end user and a way to 
identify good player and bad ones.

Switching to a paid service bring these metrics to fails; rich spammer may 
easily honor them getting a better reputation than a little correct player.

It also means that it's needed to buy a paid service from a private company to 
follows best practices, something that seems to be unfair.

But... as any collaborating service it's based on other peers/nodes/players so 
my question is: how mail players will act in this scenario?

For example, if every mailbox is going to reactivate his own service to get 
back the control of their FBL, it will not have just a short term impact...

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


--

Steve Freegard

|

Senior Product Owner

T.



+44 7740 364348

abusix.com

Book a 
meeting

[My Logo]



[https://storage.letsignit.com/icons/designer/socials/Facebook--circle--black.png]

[https://storage.letsignit.com/icons/designer/socials/Twitter--circle--black.png]

[https://storage.letsignit.com/icons/designer/socials/Linkedin--circle--black.png]

[mailop] Proofpoint Contact

2023-09-21 Thread Troy via mailop

Does anyone have proofpoint contact info? I have requested to have an ip 
delisted from one of their lists and haven't heard anything back and the ip is 
still being blocked.
 
Thanks,
Troy
 
 
 
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] New Validity policy for paid FBL (ARF)

2023-09-21 Thread Tracey Crawford via mailop

Hi Steve,

That is awesome news!
Tracey Crawford

Message: 1
> Date: Thu, 21 Sep 2023 17:05:23 +0100
> From: Steve Freegard 
> To: Support 3Hound 
> Cc: mailop@mailop.org
> Subject: Re: [mailop] New Validity policy for paid FBL (ARF)
> Message-ID:
>  fperqryufwzrd7jdmz...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Just saw this thread; I published this earlier today and we're likely going
> to discuss it at M3AAWG:  https://abusix.com/feedback-loops/
>
> TLDR; Abusix is willing to take this on and provide it as a free service
> from any mailbox provider that wishes to participate, but we'll do it based
> on the Independent RFC Draft using CFBL-Address, so we don't just end up
> swapping out Validity for us, we help adopt a standard that any mailbox
> provider can use going forward if they wish.
> Putting us in the middle just means that we take on the burden of
> processing, wrapping and delivering the reports and approving the
> CFBL-Addresses that can receive them and producing some high-level
> statistics that might be interesting at the same time.
>
> Kind regards,
> Steve.
>
>
>
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Apple/icloud blocking - Message rejected due to local policy

2023-09-21 Thread Scott Mutter via mailop

Message sent again - today, 2023-09-21 11:51AM CDT.

Subject of the message is - 209.236.124.55 IP Blacklisted

I sent the message to icloudad...@apple.com and CC'd s...@apple.com

On Thu, Sep 21, 2023 at 9:46 AM Suresh Ramasubramanian 
wrote:

> Can you resend your message to postmaster with a recent sample of the
> logs? Bcc me at s...@apple.com so I can follow up with the team.
>
>
>
> *From: *mailop  on behalf of Scott Mutter via
> mailop 
> *Date: *Thursday, 21 September 2023 at 8:00 PM
> *To: *mailop@mailop.org 
> *Subject: *Re: [mailop] Apple/icloud blocking - Message rejected due to
> local policy
>
> How long should I have to wait for a response?
>
>
>
> I haven't heard anything back and icloud is still rejecting the message
> due to local policy.
>
>
>
> On Tue, Sep 19, 2023 at 9:07 AM Suresh Ramasubramanian <
> ops.li...@gmail.com> wrote:
>
> I will have the team check and reply to you
>
>
>
> *From: *Scott Mutter 
> *Date: *Tuesday, 19 September 2023 at 6:28 PM
> *To: *Suresh Ramasubramanian 
> *Subject: *Re: [mailop] Apple/icloud blocking - Message rejected due to
> local policy
>
> I wrote icloudad...@apple.com on August 26, 2023.
>
>
>
> Message was from postmas...@thoroughbred.wznoc.com
>
>
>
> Subject of the message was - 209.236.124.55 IP Blacklisted
>
>
>
> Just tried resending a message from this server, same error message:
>
>
>
>  554 5.7.1 [HM08] Message rejected due to local policy. Please visit
> https://support.apple.com/en-us/HT204137
>
>
>
>
>
>
>
> On Tue, Sep 19, 2023 at 2:08 AM Suresh Ramasubramanian <
> ops.li...@gmail.com> wrote:
>
> Hi
>
>
>
> What address did you email icloudadmin from?
>
> I don’t see any current blocks on your IP
>
>
>
> --srs
> --
>
> *From:* Suresh Ramasubramanian 
> *Sent:* Tuesday, September 19, 2023 10:33:52 AM
> *To:* Scott Mutter ; mailop@mailop.org <
> mailop@mailop.org>
> *Subject:* Re: [mailop] Apple/icloud blocking - Message rejected due to
> local policy
>
>
>
> I’ll have someone look at your email and reply if they haven’t yet
>
>
>
> --srs
> --
>
> *From:* mailop  on behalf of Scott Mutter via
> mailop 
> *Sent:* Tuesday, September 19, 2023 9:11:02 AM
> *To:* mailop@mailop.org 
> *Subject:* [mailop] Apple/icloud blocking - Message rejected due to local
> policy
>
>
>
> Anybody from Apple/iCloud able to provide any insight as to why messages
> from 209.236.124.55 are being blocked with - Message rejected due to local
> policy messages?
>
>
>
> I previously sent a message to icloudad...@apple.com but got no response.
>
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] New Validity policy for paid FBL (ARF)

2023-09-21 Thread Steve Freegard via mailop

Just saw this thread; I published this earlier today and we're likely going
to discuss it at M3AAWG:  https://abusix.com/feedback-loops/

TLDR; Abusix is willing to take this on and provide it as a free service
from any mailbox provider that wishes to participate, but we'll do it based
on the Independent RFC Draft using CFBL-Address, so we don't just end up
swapping out Validity for us, we help adopt a standard that any mailbox
provider can use going forward if they wish.
Putting us in the middle just means that we take on the burden of
processing, wrapping and delivering the reports and approving the
CFBL-Addresses that can receive them and producing some high-level
statistics that might be interesting at the same time.

Kind regards,
Steve.

On Mon, 11 Sept 2023 at 12:29, Support 3Hound via mailop 
wrote:

> Dear list,
> I would like to understand what the community think about the new Validity
> universal feedback loop service that is switching to a paid service
> starting 21 September 2023.
>
> As Validity worked in the the last years to achieve the management of the
> FBL service from all the "main" country-level and international mailbox
> providers (as the "universal" word suggest), I think that this new policy
> is unfair and a very bad news for the mail operators community.
>
> During years the FBL became a kind of "safe feature" for users that prefer
> to click "junk" or "spam" and be sure they will not receive anymore.
>
> The "one click unsubscribe/ List-unsubscribe header" should be the right
> way to do that... true! But this is not the focus, everyone know that FBL
> are -de facto- used like that from users and that they are honored from
> correct sender.
>
> FBL generates also a good data flow for the mailbox provider that may
> filter the "next e-mail" from a sender that don't honor the FBL (or can't
> act realtime the unsubcribe) generating a better service for the end user
> and a way to identify good player and bad ones.
>
> Switching to a paid service bring these metrics to fails; rich spammer may
> easily honor them getting a better reputation than a little correct player.
>
> It also means that it's needed to buy a paid service from a private
> company to follows best practices, something that seems to be unfair.
>
> But... as any collaborating service it's based on other
> peers/nodes/players so my question is: how mail players will act in this
> scenario?
>
> For example, if every mailbox is going to reactivate his own service to
> get back the control of their FBL, it will not have just a short term
> impact...
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>

-- 

Steve Freegard

|

Senior Product Owner

T.

+44 7740 364348

abusix.com

Book a meeting

[image: My Logo]

CONFIDENTIALITY This email and any attachments are confidential and may
also be privileged or otherwise protected from disclosure. If you are not
the named recipient, please notify the sender immediately and do not
disclose the contents to another person, use it for any purpose, or store
or copy the information in any medium.

You’ll find further information about privacy here

.
___
mailop mailing list
mailop@mailop.org

Re: [mailop] Apple/icloud blocking - Message rejected due to local policy

2023-09-21 Thread Suresh Ramasubramanian via mailop

Can you resend your message to postmaster with a recent sample of the logs? Bcc 
me at s...@apple.com so I can follow up with the team.

From: mailop  on behalf of Scott Mutter via mailop 

Date: Thursday, 21 September 2023 at 8:00 PM
To: mailop@mailop.org 
Subject: Re: [mailop] Apple/icloud blocking - Message rejected due to local 
policy
How long should I have to wait for a response?

I haven't heard anything back and icloud is still rejecting the message due to 
local policy.

On Tue, Sep 19, 2023 at 9:07 AM Suresh Ramasubramanian 
mailto:ops.li...@gmail.com>> wrote:
I will have the team check and reply to you

From: Scott Mutter 
mailto:mailopl...@amssupport.info>>
Date: Tuesday, 19 September 2023 at 6:28 PM
To: Suresh Ramasubramanian mailto:ops.li...@gmail.com>>
Subject: Re: [mailop] Apple/icloud blocking - Message rejected due to local 
policy
I wrote icloudad...@apple.com on August 26, 2023.

Message was from 
postmas...@thoroughbred.wznoc.com

Subject of the message was - 209.236.124.55 IP Blacklisted

Just tried resending a message from this server, same error message:

 554 5.7.1 [HM08] Message rejected due to local policy. Please visit 
https://support.apple.com/en-us/HT204137

On Tue, Sep 19, 2023 at 2:08 AM Suresh Ramasubramanian 
mailto:ops.li...@gmail.com>> wrote:
Hi

What address did you email icloudadmin from?
I don’t see any current blocks on your IP

--srs

From: Suresh Ramasubramanian mailto:ops.li...@gmail.com>>
Sent: Tuesday, September 19, 2023 10:33:52 AM
To: Scott Mutter 
mailto:mailopl...@amssupport.info>>; 
mailop@mailop.org 
mailto:mailop@mailop.org>>
Subject: Re: [mailop] Apple/icloud blocking - Message rejected due to local 
policy

I’ll have someone look at your email and reply if they haven’t yet

--srs

From: mailop mailto:mailop-boun...@mailop.org>> on 
behalf of Scott Mutter via mailop mailto:mailop@mailop.org>>
Sent: Tuesday, September 19, 2023 9:11:02 AM
To: mailop@mailop.org 
mailto:mailop@mailop.org>>
Subject: [mailop] Apple/icloud blocking - Message rejected due to local policy

Anybody from Apple/iCloud able to provide any insight as to why messages from 
209.236.124.55 are being blocked with - Message rejected due to local policy 
messages?

I previously sent a message to 
icloudad...@apple.com but got no response.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Apple/icloud blocking - Message rejected due to local policy

2023-09-21 Thread Scott Mutter via mailop

How long should I have to wait for a response?

I haven't heard anything back and icloud is still rejecting the message due
to local policy.

On Tue, Sep 19, 2023 at 9:07 AM Suresh Ramasubramanian 
wrote:

> I will have the team check and reply to you
>
>
>
> *From: *Scott Mutter 
> *Date: *Tuesday, 19 September 2023 at 6:28 PM
> *To: *Suresh Ramasubramanian 
> *Subject: *Re: [mailop] Apple/icloud blocking - Message rejected due to
> local policy
>
> I wrote icloudad...@apple.com on August 26, 2023.
>
>
>
> Message was from postmas...@thoroughbred.wznoc.com
>
>
>
> Subject of the message was - 209.236.124.55 IP Blacklisted
>
>
>
> Just tried resending a message from this server, same error message:
>
>
>
>  554 5.7.1 [HM08] Message rejected due to local policy. Please visit
> https://support.apple.com/en-us/HT204137
>
>
>
>
>
>
>
> On Tue, Sep 19, 2023 at 2:08 AM Suresh Ramasubramanian <
> ops.li...@gmail.com> wrote:
>
> Hi
>
>
>
> What address did you email icloudadmin from?
>
> I don’t see any current blocks on your IP
>
>
>
> --srs
> --
>
> *From:* Suresh Ramasubramanian 
> *Sent:* Tuesday, September 19, 2023 10:33:52 AM
> *To:* Scott Mutter ; mailop@mailop.org <
> mailop@mailop.org>
> *Subject:* Re: [mailop] Apple/icloud blocking - Message rejected due to
> local policy
>
>
>
> I’ll have someone look at your email and reply if they haven’t yet
>
>
>
> --srs
> --
>
> *From:* mailop  on behalf of Scott Mutter via
> mailop 
> *Sent:* Tuesday, September 19, 2023 9:11:02 AM
> *To:* mailop@mailop.org 
> *Subject:* [mailop] Apple/icloud blocking - Message rejected due to local
> policy
>
>
>
> Anybody from Apple/iCloud able to provide any insight as to why messages
> from 209.236.124.55 are being blocked with - Message rejected due to local
> policy messages?
>
>
>
> I previously sent a message to icloudad...@apple.com but got no response.
>
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Anyone from hostedemail.com able to help a bounce issue?

2023-09-21 Thread Daniel Thorpe via mailop

Hi,

We have a dedicated IP client getting near 100% bounce rate to domains covered 
by hostedemail.com.  The bounces are all...


  *   bad connection

Is anyone from hostedemail.com able to help look at the issue?

Thanks,
Dan
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Is anyone from Bigpond team could help for the bounce issue?

2023-09-21 Thread Bradley King via mailop


  
  
  

	
	Hi Teddy,I’ll contact you off list.Cheers,Brad
	Get Outlook for iOS

  

 From: mailop  on behalf of Teddy Choi via mailop Sent: Thursday, September 21, 2023 7:22 pmTo: mailop@mailop.org Subject: [mailop] Is anyone from Bigpond team could help for the bounce issue? 







Hello!
 
We are facing the Bigpond bounce issue which related to the envelop-from domain.
550 5.7.1 *** Sender domain rejected. IB302
 
I tried to contact Bigpond team by sending to their postmaster address (postmas...@bigpond.com) and Tmail-PostMaster address (tm-postmas...@online.telstra.com.au).
Waiting for around 3 weeks but no response from the Bigpond team about this issue yet.
 
Is anyone from the Bigpond team could help for this bounce issue?
 




Best Regards,





Teddy Choi










Deliverability Consultant












































35/F, Tower Two, Times Square,
1 Matheson Street, Causeway Bay,
Hong Kong






T:


+852 3168 2505




E:


teddy.c...@emarsys.com




W:


www.emarsys.com






























»
 Get the latest insight from Emarsys




































The information contained in this communication is intended solely for the user of the individual or entity to which
 it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on
 the contents of this information is strictly prohibited and may be unlawful. Emarsys is neither liable for the proper and complete transmission of the information contained in this communication nor for any delay in its receipt.








 
 



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

[mailop] Is anyone from Bigpond team could help for the bounce issue?

2023-09-21 Thread Teddy Choi via mailop

Hello!

We are facing the Bigpond bounce issue which related to the envelop-from domain.
550 5.7.1 *** Sender domain rejected. IB302

I tried to contact Bigpond team by sending to their postmaster address 
(postmas...@bigpond.com) and Tmail-PostMaster 
address 
(tm-postmas...@online.telstra.com.au).
Waiting for around 3 weeks but no response from the Bigpond team about this 
issue yet.

Is anyone from the Bigpond team could help for this bounce issue?

Best Regards,

Teddy Choi


Deliverability Consultant



[emarsys is part of SAP]

35/F, Tower Two, Times Square,
1 Matheson Street, Causeway Bay,
Hong Kong
T:
+852 3168 2505
E:
teddy.c...@emarsys.com
W:
www.emarsys.com



> Get the latest insight from 
> Emarsys



[cid:image003.jpg@01D9ECB0.148CEEC0]

The information contained in this communication is intended solely for the user 
of the individual or entity to which it is addressed and others authorized to 
receive it. It may contain confidential or legally privileged information. If 
you are not the intended recipient you are hereby notified that any disclosure, 
copying, distribution or taking any action in reliance on the contents of this 
information is strictly prohibited and may be unlawful. Emarsys is neither 
liable for the proper and complete transmission of the information contained in 
this communication nor for any delay in its receipt.


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

Re: [mailop] Authentication Bounces by Gmail

2023-09-21 Thread Slavko via mailop


Dňa 21. 9. o 9:27 Gellner, Oliver via mailop napísal(a):


The bugs don't have to be security related, they just lead to wrongly computed DKIM signatures, 
because some implementations applied the steps defined in the RFC for the relaxed canonicalization 
in a wrong way or wrong order or whatever. For example as reported on this very list ("We 
already found some interesting bits, like [...] mail-in-a-box using relaxed/simple for DKIM, which 
breaks signature validity on long To: headers") 
https://list.mailop.org/private/mailop/2023-February/024443.html or with Ciscos appliances which 
"fail signing and verification messages with an empty body on relaxed canonicalization" 
(bug ID CSCvh84754, but not publicly visible).
I'm not arguing against the relaxed canonicalization, just saying that it is 
merely a workaround for the quirks in different MTAs and the actual solution 
lies at fixing the behavior of those MTAs.


That is pointless.

Any software can have bug, any verifier can have bug, any hash library 
can have bug, any MTA can have bug, any router can have bug... Yes bugs 
was here, and will be here. Some are fixed over time, some fixes 
introduces new bugs, some stays here for years...


Simply, we all are doing mistakes, including HW/SW devs. Bugfree 
computers are science fiction (or PR).


regards

--
Slavko

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

Re: [mailop] Authentication Bounces by Gmail

2023-09-21 Thread Gellner, Oliver via mailop

On 21.09.2023 at 00:30 John Levine wrote:

> It appears that Gellner, Oliver via mailop  said:
>>> Yes, I'm sure it does.
>>> Using simple/simple canonicalization is not for people who want robust DKIM 
>>> signatures.
>>
>>The relaxed canonicalization of DKIM would fix this particular issue,
>>but relaxed means both the signer and the verifier have to apply 
>>modifications to the content before signing/verifying, which might introduce 
>>new bugs or edge cases. ...

> The canonicalization is done as the library computes the hash, not by making 
> a separate version of the message.  We've had DKIM libraries doing relaxed 
> signatures for over a decade and I don't ever recall a security bug related 
> to that.
> There's a separate question about why relays are munging the headers but it 
> usually comes down to, yeah, we know they shouldn't but it's not a high 
> priority to fix.

The bugs don't have to be security related, they just lead to wrongly computed 
DKIM signatures, because some implementations applied the steps defined in the 
RFC for the relaxed canonicalization in a wrong way or wrong order or whatever. 
For example as reported on this very list ("We already found some interesting 
bits, like [...] mail-in-a-box using relaxed/simple for DKIM, which breaks 
signature validity on long To: headers") 
https://list.mailop.org/private/mailop/2023-February/024443.html or with Ciscos 
appliances which "fail signing and verification messages with an empty body on 
relaxed canonicalization" (bug ID CSCvh84754, but not publicly visible).
I'm not arguing against the relaxed canonicalization, just saying that it is 
merely a workaround for the quirks in different MTAs and the actual solution 
lies at fixing the behavior of those MTAs.

--
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.

smime.p7s
Description: S/MIME cryptographic signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Apple/icloud blocking - Message rejected due to local policy

Re: [mailop] New Validity policy for paid FBL (ARF)

Re: [mailop] Proofpoint Contact

Re: [mailop] New Validity policy for paid FBL (ARF)

[mailop] Proofpoint Contact

Re: [mailop] New Validity policy for paid FBL (ARF)

Re: [mailop] Apple/icloud blocking - Message rejected due to local policy

Re: [mailop] New Validity policy for paid FBL (ARF)

Re: [mailop] Apple/icloud blocking - Message rejected due to local policy

Re: [mailop] Apple/icloud blocking - Message rejected due to local policy

[mailop] Anyone from hostedemail.com able to help a bounce issue?

Re: [mailop] Is anyone from Bigpond team could help for the bounce issue?

[mailop] Is anyone from Bigpond team could help for the bounce issue?

Re: [mailop] Authentication Bounces by Gmail

Re: [mailop] Authentication Bounces by Gmail

15 matches

Site Navigation

Mail list logo

Footer information