Re: [mailop] ARC and not ARC, was Microsoft Announces Tenant Trusted ARC Seal

[Alessandro Vesely via mailop]

On Tue 28/Jun/2022 15:33:01 +0200 Dave Crocker via mailop wrote:


On 6/28/2022 3:32 AM, Alessandro Vesely via mailop wrote:
I agree that would've been better than ARC.  However, it'd still need to know 
which recipients are mailing list supporting DKIMv2 and operate accordingly. 
For example, on a reply-all the MSA should split the message and sign it 
regularly for regular recipients and conditionally for MLs. 



1. What do you mean by DKIMv2?



I seemed to recall that John's conditional-signatures required a version bump. 
 Now I looked at the draft again and it doesn't mention v2.




2. What features of v2 are relevant here and where are they in the spec?



The point, IIRC, was to set a mandatory tag, !fs=, which cannot be ignored.


3. How is an MSA to know, reliably and accurately, the difference between 
'regular recipients' and MLs?



Eh, that's a good question.  Vsevolod suggests a Merkle tree.  Any database 
would do, but databases don't seem to be part of the typical MTA tools.


The other side of the question is how do they obtain the relevant data.  Once I 
fantasized about a sort of extended opt-in protocol that involved the user's 
MX.  MSAs having a per-user list of subscribed MLs would have several 
advantages, and the disadvantage of decreased user privacy.


Perhaps the opposite is more workable, MLs having a per-subscriber list of MTA 
capabilities.  That way they'd know which MTA trusts their ARC sealing and can 
skim From: munging.




4. What do you mean by 'conditional' signing?


You certainly recall John's conditional signatures.  DMARC WG talked a lot 
about them in 2014, before ARC.

https://datatracker.ietf.org/doc/html/draft-levine-dkim-conditional


Best
Ale
--





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

Re: [mailop] ARC and not ARC, was Microsoft Announces Tenant Trusted ARC Seal

[Dave Crocker via mailop]

On 6/28/2022 3:32 AM, Alessandro Vesely via mailop wrote:
I agree that would've been better than ARC.  However, it'd still need 
to know which recipients are mailing list supporting DKIMv2 and 
operate accordingly. For example, on a reply-all the MSA should split 
the message and sign it regularly for regular recipients and 
conditionally for MLs. 



1. What do you mean by DKIMv2?

2. What features of v2 are relevant here and where are they in the spec?

3. How is an MSA to know, reliably and accurately, the difference 
between 'regular recipients' and MLs?


4. What do you mean by 'conditional' signing?


d/

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

Re: [mailop] ARC and not ARC, was Microsoft Announces Tenant Trusted ARC Seal

[Vsevolod Stakhov via mailop]

On 28/06/2022 11:32, Alessandro Vesely via mailop wrote:

On Mon 27/Jun/2022 13:39:52 +0200 Vsevolod Stakhov via mailop wrote:

On 25/06/2022 18:14, John Levine via mailop wrote:

It appears that Vsevolod Stakhov via mailop  said:
I really, really miss one simple feature in ARC signatures. Whilst 
it is

+/- trivial to have a list of trusted signers on a receiver side, it
would be super helpful to allow **a sender** to specify it's next
trusted hop.


You mean liks this?

   https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/

I proposed that in 2014, the ARC crowd didn't go for it.


Yes, that's exactly what I have in my mind if thinking about how to 
`fix` dmarc for forwarding!


And it doesn't introduce that bloated complexity that ARC does, 
allowing to restore authority by just following DKIM signatures. It is 
not a silver bullet as you still have a choice to trust or not for 
those forwarders but it is really a choice of a sender, like the whole 
DMARC policy.



I agree that would've been better than ARC.  However, it'd still need to 
know which recipients are mailing list supporting DKIMv2 and operate 
accordingly. For example, on a reply-all the MSA should split the 
message and sign it regularly for regular recipients and conditionally 
for MLs.


Interesting, I have just found that the current DKIM RFC actually states 
that a verifier must *ignore* the unknown tags in the signature: 
https://datatracker.ietf.org/doc/html/rfc6376#section-3.2


However, my own implementation of DKIM verifier in Rspamd fails to 
comply with this requirement (I will fix it soon). I'm curious now how 
many of the existing DKIM implementations panic on an unknown tags in 
DKIM signatures.


If we ignore unknown tags safely then this extension can be introduced 
without any additional issues with the compatibility I suppose.


Albeit requirements differ, both ARC and dkim-conditional would need to 
exchange info between a mailing list and each subscriber's MTA in order 
to operate as intended.  Perhaps an extended opt-in protocol...?



Well, it is possible for an ML software to keep all signatures in a 
Merkle tree and store any additional information about the particular 
signature to share it with the interested receivers. However, it might 
be an overkill in general, I don't know.


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

Re: [mailop] Looking for contact at iphmx.com

[Atro Tossavainen via mailop]

Hey Sidsel, Bastiaan,

On Tue, Jun 28, 2022 at 01:09:45PM +0200, Hetzner Blacklist via mailop wrote:
> That error message means your IP has a poor email reputation on Cisco Talos:
> https://talosintelligence.com/reputation_center/

Cisco Talos has to be the most opaque reputation service I have come
across so far.

They also take the word of a third party (SecurityTrails, or whatever
their IP intelligence arm is called, in this case) as gospel. Or at
least took, some time ago.

The good folks at SecurityTrails figured out a few months ago that the
presence of the RoundCube webmail product counts as "phishing against
the generic brand of email" (I shit you not) and as a result, Cisco
proceeded to list all domains operating RoundCube as bad.

How do I know? I got hit, that's how. :-D

Took me a good deal of time to even figure out who were responsible
and how, and probably wouldn't have been possible without M3AAWG
contacts. Also, I found out that some parties trusting Cisco Talos
intelligence (such as Telia Finland or the government ICT centre of
Finland) are so far behind the requirements of their jobs you
wouldn't believe they had been hired by anyone.

> 
> Regards
> Bastiaan
> 
> Am 28.06.2022 um 12:09 schrieb Sidsel Jensen via mailop:
> >Hi
> >I'm trying to locate a contact to mx1.hc1932.iphmx.com - does anybody know 
> >who to reach out to? They don't respond through ab...@enom.com 
> >mailto:ab...@enom.com (which was the only address whois showed as everything 
> >else was heavily redacted)
> >I'm trying to solve a deliverability problem towards them:
> >host mx1.hc1932.iphmx.com[216.71.154.96] refused to talk to me: 
> >554-esa6.hc1932.iphmx.com 554 Your access to this mail system has been 
> >rejected due to the sending MTA's poor reputation. If you believe that this 
> >failure is in error, please contact the intended recipient via alternate 
> >means.
> >I guess mailop applies as "alternate means" ;-)
> >Kind Regards,
> >Sidsel Jensen
> >Architect of Deliverability and Abuse @ Open-Xchange

-- 
Atro Tossavainen, Chairman of the Board
Infinite Mho Oy, Helsinki, Finland
tel. +358-44-5000 600, http://www.infinitemho.fi/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Looking for contact at iphmx.com

[Hetzner Blacklist via mailop]

That error message means your IP has a poor email reputation on Cisco Talos:
https://talosintelligence.com/reputation_center/

Regards
Bastiaan

Am 28.06.2022 um 12:09 schrieb Sidsel Jensen via mailop:

Hi
  
I'm trying to locate a contact to mx1.hc1932.iphmx.com - does anybody know who to reach out to? They don't respond through ab...@enom.com mailto:ab...@enom.com (which was the only address whois showed as everything else was heavily redacted)
  
I'm trying to solve a deliverability problem towards them:
  
host mx1.hc1932.iphmx.com[216.71.154.96] refused to talk to me: 554-esa6.hc1932.iphmx.com 554 Your access to this mail system has been rejected due to the sending MTA's poor reputation. If you believe that this failure is in error, please contact the intended recipient via alternate means.
  
I guess mailop applies as "alternate means" ;-)
  
Kind Regards,

Sidsel Jensen
  
Architect of Deliverability and Abuse @ Open-Xchange



___
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] Looking for contact at iphmx.com

[Sidsel Jensen via mailop]

Thank you Laura :-)
 
Apparently I'm blind - for some weird reason I completely missed that 
 
/Sidsel

> On 06/28/2022 12:36 PM Laura Atkins via mailop  wrote:
>  
>  
>  
> If you put iphmx into google, you get a clear statement in the first page of 
> responses that says iphmx is controlled by Cisco. But the rejection message 
> is telling you to contact the recipient - not the filter owner. 
>  
> laura 
> 
> 
> 
> > On 28 Jun 2022, at 11:09, Sidsel Jensen via mailop  > mailto:mailop@mailop.org> wrote:
> > Hi
> >  
> > I'm trying to locate a contact tohttp://mx1.hc1932.iphmx.com - does anybody 
> > know who to reach out to? They don't respond through ab...@enom.com 
> > mailto:ab...@enom.com (which was the only address whois showed as 
> > everything else was heavily redacted)
> >  
> > I'm trying to solve a deliverability problem towards them:
> >  
> > hosthttp://mx1.hc1932.iphmx.com [216.71.154.96] refused to talk to 
> > me:http://554-esa6.hc1932.iphmx.com 554 Your access to this mail system has 
> > been rejected due to the sending MTA's poor reputation. If you believe that 
> > this failure is in error, please contact the intended recipient via 
> > alternate means.
> >  
> > I guess mailop applies as "alternate means" ;-)
> >  
> > Kind Regards,
> > Sidsel Jensen
> >  
> > Architect of Deliverability and Abuse @ Open-Xchange
> > ___
> > mailop mailing list
> > mailop@mailop.org mailto:mailop@mailop.org
> > https://list.mailop.org/listinfo/mailop
> > 
> 
> -- 
> The Delivery Experts
>  
> Laura Atkins
> Word to the Wise
> la...@wordtothewise.com mailto:la...@wordtothewise.com
>  
> Email Delivery Blog: http://wordtothewise.com/blog
> 
> ___
> 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] Looking for contact at iphmx.com

[Laura Atkins via mailop]

If you put iphmx into google, you get a clear statement in the first page of 
responses that says iphmx is controlled by Cisco. But the rejection message is 
telling you to contact the recipient - not the filter owner. 

laura 


> On 28 Jun 2022, at 11:09, Sidsel Jensen via mailop  wrote:
> 
> Hi
>  
> I'm trying to locate a contact to mx1.hc1932.iphmx.com - does anybody know 
> who to reach out to? They don't respond through ab...@enom.com 
>  (which was the only address whois showed as 
> everything else was heavily redacted)
>  
> I'm trying to solve a deliverability problem towards them:
>  
> host mx1.hc1932.iphmx.com[216.71.154.96] refused to talk to me: 
> 554-esa6.hc1932.iphmx.com 554 Your access to this mail system has been 
> rejected due to the sending MTA's poor reputation. If you believe that this 
> failure is in error, please contact the intended recipient via alternate 
> means.
>  
> I guess mailop applies as "alternate means" ;-)
>  
> Kind Regards,
> Sidsel Jensen
>  
> Architect of Deliverability and Abuse @ Open-Xchange
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop

-- 
The Delivery Experts

Laura Atkins
Word to the Wise
la...@wordtothewise.com 

Email Delivery Blog: http://wordtothewise.com/blog  






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

Re: [mailop] ARC and not ARC, was Microsoft Announces Tenant Trusted ARC Seal

[Alessandro Vesely via mailop]

On Mon 27/Jun/2022 13:39:52 +0200 Vsevolod Stakhov via mailop wrote:

On 25/06/2022 18:14, John Levine via mailop wrote:

It appears that Vsevolod Stakhov via mailop  said:

I really, really miss one simple feature in ARC signatures. Whilst it is
+/- trivial to have a list of trusted signers on a receiver side, it
would be super helpful to allow **a sender** to specify it's next
trusted hop.


You mean liks this?

   https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/

I proposed that in 2014, the ARC crowd didn't go for it.


Yes, that's exactly what I have in my mind if thinking about how to `fix` dmarc 
for forwarding!


And it doesn't introduce that bloated complexity that ARC does, allowing to 
restore authority by just following DKIM signatures. It is not a silver bullet 
as you still have a choice to trust or not for those forwarders but it is 
really a choice of a sender, like the whole DMARC policy.



I agree that would've been better than ARC.  However, it'd still need to know 
which recipients are mailing list supporting DKIMv2 and operate accordingly. 
For example, on a reply-all the MSA should split the message and sign it 
regularly for regular recipients and conditionally for MLs.


Albeit requirements differ, both ARC and dkim-conditional would need to 
exchange info between a mailing list and each subscriber's MTA in order to 
operate as intended.  Perhaps an extended opt-in protocol...?



Best
Ale
--





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

[mailop] Looking for contact at iphmx.com

[Sidsel Jensen via mailop]

Hi
 
I'm trying to locate a contact to mx1.hc1932.iphmx.com - does anybody know who 
to reach out to? They don't respond through ab...@enom.com 
mailto:ab...@enom.com (which was the only address whois showed as everything 
else was heavily redacted)
 
I'm trying to solve a deliverability problem towards them:
 
host mx1.hc1932.iphmx.com[216.71.154.96] refused to talk to me: 
554-esa6.hc1932.iphmx.com 554 Your access to this mail system has been rejected 
due to the sending MTA's poor reputation. If you believe that this failure is 
in error, please contact the intended recipient via alternate means.
 
I guess mailop applies as "alternate means" ;-)
 
Kind Regards,
Sidsel Jensen
 
Architect of Deliverability and Abuse @ Open-Xchange___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop