Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Hector Santos]

On 4/28/2023 5:19 AM, Alessandro Vesely wrote:
> On Sun 02/Apr/2023 20:13:48 +0200 Scott Kitterman wrote:
>> Mailing list changes to ameliorate damage due to DMARC are in no 
way an improvement.  Absent DMARC, they would not be needed at all.

>
> +1

In my view, when an incomplete protocol is introduced, it creates 
gaps. If there are no guidelines for addressing these gaps in a 
graceful and elegant manner, solutions can vary widely. As developers, 
it's important to have the ability to make adjustments to our software.


Here are a few suggestions to "ameliorate damages" caused by an 
incomplete protocol:


1) Address the gaps with proper protocol negotiation guidelines and a 
well-defined state machine. This includes addressing third-party 
signers and providing guidance for groupware, one-to-many, mailing 
lists, and newsletter distribution mailers. This would make the 
protocol more complete.


2) If option #1 is not viable and continues to be a non-starter with 
the editor of this standard track bis document, the document's status 
and endorsement become technically challenged in many ways. It then 
becomes critical to have a Field Operations status report on a) DMARC 
p=reject problems, b) current problem mitigations, and c) any new 
security threats introduced by the mitigations, particularly with a 
DMARC Security teardown.


There aren't many options for MLS developers when dealing with an 
incomplete protocol.


I have been developing mail software since the '80s, with products 
such as Silver Xpress, Platinum Xpress, Gold Xpress, and Wildcat! 
These early experiences have informed my current understanding of the 
challenges in integrating DMARC into systems.


Regarding rewrite, we don't want to promote it, but it may now be 
necessary to describe it as a new potential "Display Name" security 
threat. However, there are legitimate situations where a rewrite is 
both technically necessary and ethically acceptable. For example:


A MLM Newsletter list domain MUST have a From: domain example-biz.com 
for security. This is a read-only list, and only a few authorized 
submitters can post newsletters. They use their ESP's MUA to submit 
using their ESP's domain address.


In this case, it is about the content payload, not the submitter. This 
is a legitimate situation where a complete rewrite of the incoming 
header is warranted. In the case of DMARC, it becomes necessary. The 
ESP's headers are removed, and the RFC5322 is applied for a secure, 
unambiguous result. It would be as if the customer logged into wcWEB 
and posted the newsletter directly in their MLM List storage area, but 
they prefer to do it via ESP email.


Therefore, rewrite can be described as BAD when used intentionally to 
break down DMARC security or GOOD when used to create DMARC secured 
distribution.


Thanks

--
Hector Santos,
https://santronics.com
https://winserver.com



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-10.txt

[Hector Santos]

+1

On 4/27/2023 10:11 AM, Brotman, Alex wrote:


In summary:

“Report senders SHOULD attempt delivery via SMTP using STARTTLS to 
all receivers.  Transmitting these reports via a secured session is 
preferrable.”


I don’t think we should add this in, but receivers could deploy 
DANE/MTA-STS if they wanted to ensure senders who honor those will 
use TLS.


--

Alex Brotman

Sr. Engineer, Anti-Abuse & Messaging Policy

Comcast

*From:* dmarc  *On Behalf Of * Hector Santos
*Sent:* Wednesday, April 26, 2023 4:29 PM
*To:* Scott Kitterman 
*Cc:* IETF DMARC WG 
*Subject:* Re: [dmarc-ietf] I-D Action: 
draft-ietf-dmarc-aggregate-reporting-10.txt





On Apr 26, 2023, at 3:50 PM, Scott Kitterman
mailto:skl...@kitterman.com>> wrote:

I think it would be crazy in 2023 not to use STARTTLS is offered.


+1


Personally I interpreted it more as employ a secure transport
and think through if you really want to be sending the report if
you can't.

I think there's some room for interpretation and I think that's
fine.


I believe connectivity is independent of the application.

All connections SHOULD assume the highest possible security 
available today.


For unsolicited email, the presumption would be:

Port 25
STARTTLS

If I was start performing reports (and I think I will), that is how 
I would begin, naturally, with outbound SMTP clients with optional 
TLS if offered.


Sorry if I was not focused with the main question,

—
HLS



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc



--
Hector Santos,
https://santronics.com
https://winserver.com



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows

[Hector Santos]

On 4/26/2023 11:51 AM, Scott Kitterman wrote:

I agree that more will be needed.  Thanks for the feedback.  The last run at 
this question ended up being a mess, so I'm trying to see if we can get further 
by going in small steps.



Scott,

I  provided some suggested text below of what I think, as an 
implementator,  to get closer to finishing this DKIM Policy project.


Incremental changes is always preferred, but it has been many years 
with operational experiences. We know where the stepping stones are.  
That was the goal with ADSP as well and unfortunately the stepping 
stones are being ignored.  So lets not ignore them anymore to we can 
move forward with a more protocol complete DKIM Policy model.


The beauty of the IETF RFC documentation format is that its addresses 
a wide audience of disciplines  It's a blend of all the functional, 
technical, security and operator's manual.  But the RFC is for 
everyone, including management and decision makers.   I think the 
wording for the I-D can be done to satisfy all.


Look it at this another way. We really don't have a problem anymore. 
We know what the mitigations are.  So whatever is done with the I-D, 
the problems as been addressed.   So I suppose, its more of a clean 
up, a codification of what has happened with the DKIM Policy model 
that now comes under the umbrella of DMARC.  We know what the issues 
are and the solutions.  Why not just document this and be done.


Proposed new Appendix A section.

   A.8  Mailing List Servers

   Mailing List Servers (MLS) applications who are compliant with
   DMARC operations, SHOULD adhere  to the following guidelines to
   integrated DMARC.

   Subscription and Submission Controls

   MLS subscription processes should perform a DMARC check to
   determine if a subscribing or submission email  domain DMARC
   policy is restrictive in regards to mail integrity changes or
   3rd party signatures. The MLS SHOULD only allow subscriptions
   and submission from original domain policies who allow 3rd
   party signatures with p=none policy.


   Message Content Integrity Change

   List Servers which will alter the message content SHOULD only
   do so for original domains with optional DKIM signing
   practices. If the List Server is not going to alter the
   message, it SHOULD NOT remove the signature, if present.


   Security Tear Down

   The MLS SHOULD NOT change the author's security by changing
   the authorship address (From) domain.  It should apply
   subscription/submission controls.  However, if there
   circumstances where a From rewrite is necessary, ideally, a
   rewrite with a new address SHOULD may the same level of
   security as the original submission to avoid potential Replay
   and Display Name Attacks.


Proposed updated 4.4.3 section.

4.4.3. Alignment and Extension Technologies

   DMARC can be extended to include the use of authentication and
   authorization mechanisms that assist in DMARC evaluation of policy.

   Any new authentication extensions will need to allow for domain
   identifier extraction so that alignment with the RFC5322.From
   domain can be verified.

   Authorization extensions deal with the condition when the author
   domain does not match the signer domain.  These are called 3rd
   party signatures.  The following Author::Signer domain
   authorization methods has been explored:

   DomainKeys Identified Mail (DKIM) Authorized Third-Party
   Signatures (ATPS)
   [https://datatracker.ietf.org/doc/html/rfc6541]

   Third-Party Authorization Label  (TPA)
   [https://datatracker.ietf.org/doc/html/draft-otis-tpa-label-08]

   Mandatory Tags for DKIM Signatures
   [https://datatracker.ietf.org/doc/html/draft-levine-dkim-conditional-04]

   Delegating DKIM Signing Authority
   [https://datatracker.ietf.org/doc/html/draft-kucherawy-dkim-delegate-02]

   The first two are DNS-based and the latter are non-DNS-based. All
   have one goal - To authorize the 3rd party signature.

   The ATPS proposal is the simplest method and it has shown success
   in practice to reduce false positive failure results when a valid
   and unverified but ATPS authorized 3rd party signer is present in
   a message.  MDA receivers should consider using ATPS to verify 3rd
   party signatures.


I hope this can be a starting point for someone better than me can 
write for the RFC wide audience.


I personally feel, we should have an ATPS section that shows the 
simple steps with the "atps=y" tag added to the DMARC record, the 
discovery method and how publishers can delegate 3rd party signers 
using ATPS records.


The key is to get closer towards completing the DKIM-based secured 
mail system with 3rd party signer support as it was originally 
envisioned.


Thanks

--
Hector Santos,
https://santronics.com
https://winserver.com



___
dma

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-10.txt

[Hector Santos]

> On Apr 26, 2023, at 3:50 PM, Scott Kitterman  > wrote:
> 
> I think it would be crazy in 2023 not to use STARTTLS is offered.  

+1

> Personally I interpreted it more as employ a secure transport and think 
> through if you really want to be sending the report if you can't.
> 
> I think there's some room for interpretation and I think that's fine.
> 

I believe connectivity is independent of the application.  

All connections SHOULD assume the highest possible security available today.

For unsolicited email, the presumption would be:

Port 25
STARTTLS

If I was start performing reports (and I think I will), that is how I would 
begin, naturally, with outbound SMTP clients with optional TLS if offered.

Sorry if I was not focused with the main question,

—
HLS___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows

[Hector Santos]

On 4/26/2023 7:21 AM, Scott Kitterman wrote:

On April 26, 2023 8:08:39 AM UTC, Alessandro Vesely  wrote:

On Tue 25/Apr/2023 20:27:18 +0200 Scott Kitterman wrote:

My recollection is that a general formulation that I proposed had at least
some traction out of both groups:


[some appropriate description] domains MUST NOT publish restrictive DMARC
policies due to interoperability issues

Leaving aside (for now) the question of what goes into [some appropriate
description] and with the assumption that there will be some non-normative
discussion to amplify whatever that is and probably give some indication about
what domains might do to not be one of those domains, is there anyone who just
can't live with that formulation of the situation?

Me, for one.  Because more than 98% of domains are going to fall into the 
description, however we word it, that statement makes the whole I-D 
nonsensical.  Cannot we just tell the problem without MUSTard?

In any case, using the complement of [some appropriate description] is 
certainly easier.  For example:

Forcing authentication into Internet mail by publishing restrictive DMARC
policies breaks some well established patterns of usage.  Publishing such
policies is thus RECOMMENDED only for domains [in this other appropriate
description].


Thanks.

I understand your objection to be that the proposed description of the 
interoperability problems would apply to too many domains, regardless of the 
modifier we might use.  Is that correct?

I don't understand the technical issue associated with that objection.  I get 
that you feel the construction is too negative, but I don't have a sense you 
think it's inaccurate.  Focusing on the technical aspects of this, would you 
please help me understand what you think is technically incorrect about it?

Scott K


Scott,

I will two to remained focus. With Barry's MUST NOT text and as you 
surmised:


   [some appropriate description] domains MUST NOT publish 
restrictive DMARC

   policies due to interoperability issues

I believe you are asking if this is technically correct ...  for IETF 
PS passage?


To me, there were a number of folks who indicated support for MUST NOT 
but preferred more details.


We will need to deal with the consequences when existing restrictive 
domains have the proverbial "book" thrown at them for their user's 
actions which creates the necessary known mitigations;  Rewrite and 
Subscription/Submission controls.  As advice to MLS/MLM 
implementators, the latter should be a natural part of the protocol 
when honoring the policy. The former is a security tear down when 
intentionally not honoring the policy.


With no deliberation as to what the interop issues are and the 
mitigation, not closing the loop holes for implementators, I see a new 
potential security issue is highlighted. The "MUST NOT due to Interop 
issues" may require a security review with a new possible Security 
Section 11.9 "Intentional DMARC Security Tear down Threats" or it may 
fall under an updated section 11.4 as a Display Name Attack.


So is it technically correct and sufficient?

I would be flabbergasted if this was IETF/IESG "technically correct" 
as a PS.  Maybe as an Informational Status, but difficult as a PS and 
I believe Barry may have suggested that.  I agree with that if left as is.



--
HLS

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows

[Hector Santos]

On 4/25/2023 10:06 PM, Scott Kitterman wrote:

On April 26, 2023 1:47:14 AM UTC, Hector Santos wrote:

On 4/25/2023 9:06 PM, John Levine wrote:

PS: If anyone was going to suggest we just tell people how to change
their mailing lists to work around DMARC, don't go there.

I don't follow.

A "no change" recommendation caused problems.  The current fix is:

1) "Rewrite From" to tear down restrictive DMARC security,
2) Prevent Subscription/Submission of restrictive DMARC domains.

#1 is undesirable. Empirical practice on a different internet has shown when 
following #2, for an existing list with members with restrictive domains, they 
will essentially become Read-Only List members because any submission/reply by 
them will be blocked.


Hector,

I think we all understand that there are things mailing lists can do to 
mitigate the interoperability impacts of DMARC.  I don't think it's germane to 
the current question.  Please, let's stay focused.


I honestly don't follow the PS.  What is the question?  Where are we 
not suppose to "go there" to?


Let me ask, is DMARCbis going to be intentionally ambiguous about 
these long time inherent protocol problems? Just like ADSP was?  Or we 
just want it to be open ended - say nothing?  I don't know. We do 
that. But not like this, for so long.  I just wish to finally close 
some of the most obvious loop holes and reduce false positives with 
well defined options like done with SPF.   SPF has a way to offer 3rd 
party machines.  DMARC also needs a way to offer 3rd party signers.


Something like a simple DMARCbis endorsement would work wonders:

Verifier MAY check|explore|consider|implement an extended technology
for ADID::SDID authorization. There are a number of concepts 
available

using a DNS or non-DNS approach to verifier the association, if any.
The following proposals are available:

Personally, I think it should be reduced to two simple approaches, 
described in IETF fashion:


ATPS - Murray's protocol.  Brilliant. Simply wasn't promoted.
VBR  - Levine's protocol. Also brilliant. Why was it not used?

A published DMARCbis will most likely not going to change again for a 
long time.  So it should recognize in this draft document, the need to 
help close the loop holes ADSP failed to do causing it to be 
abandoned.   DMARCbis risk the same sound engineering challenges.


--
Hector Santos,
https://santronics.com
https://winserver.com



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows

[Hector Santos]

On 4/25/2023 9:06 PM, John Levine wrote:

It appears that Scott Kitterman   said:

My recollection is that a general formulation that I proposed had at least
some traction out of both groups:


[some appropriate description] domains MUST NOT publish restrictive DMARC
policies due to interoperability issues

This seems like a reasonable approach. As a purely practical point, I
cannot imagine this document getting through the IESG without some
clear guidance about DMARC's interop issues.


+1


PS: If anyone was going to suggest we just tell people how to change
their mailing lists to work around DMARC, don't go there.


I don't follow.

A "no change" recommendation caused problems.  The current fix is:

1) "Rewrite From" to tear down restrictive DMARC security,
2) Prevent Subscription/Submission of restrictive DMARC domains.

#1 is undesirable. Empirical practice on a different internet has 
shown when following #2, for an existing list with members with 
restrictive domains, they will essentially become Read-Only List 
members because any submission/reply by them will be blocked.


--
Hector Santos,
https://santronics.com
https://winserver.com



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Definitely no Delegated authentication for Gmail

[Hector Santos]

t necessary.


Barry, as chair



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc



--
Hector Santos,
https://santronics.com
https://winserver.com



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Two basic Issues to address to help complete DMARCbis

[Hector Santos]

On 4/24/2023 7:22 AM, Alessandro Vesely wrote:

On Sun 23/Apr/2023 19:20:06 +0200 Hector Santos wrote:

On 4/23/2023 6:10 AM, Alessandro Vesely wrote:


Meanwhile, digressions about ATPS and similar schemes can help 
casting some light on future evolution.  From: rewriting cannot be 
the final solution; it is a temporary hack. Digressions don't slow 
down the publication, as discussions about actual text quickly 
prevail.  They are just a mean to help convergence toward a common 
vision of the future.


With each year, that "temporary hack" becomes the new normal and it 
will be harder to clean up. It is not the right way and I don't  
its too late to reverse.  However, it has been 17 years and 
DMARCbis is not finished without some clean up in this area.


First, Section 4.4.3 should have text on using extended tag methods 
to provide 3rd party authorization methods.  Just add the RFC 6541 
abstract or version of it:



Proposing to add text to DMARCbis about 3rd party auth is not a 
digression.  We cannot solve the problem before publishing 
DMARCbis.  The text to add to DMARCbis can mention that From: 
rewriting will fade out, but cannot say how. (This is not a rule, 
just a scheduling requirement.)


This suggestion is helpful, thanks.

I believe the time is now during this drafting.  I rather not punt. I 
don't wish to wait another 5-10 years to address this again.


DMARCbis should be the string board to finally solidity the potential 
DMARC add-on market to deal with the long time loopholes. The 
conceptual solutions are well known and there are both DNS and non-DNS 
proposals to explore.  It can reference the efforts and explain why 
ESPs may not be able to use it for outbound mail, but may be able to 
support it for verification of inbound mail.  It clearly scales for 
verification.  Why not help with inbound security even if they can't 
use it from themselves?   We are helping yahoo.com and others p=reject 
domains and I hope they are helping senders with their receivers.  
Even if the ESP has no policy or p=none, it can still do an 
verification ATPS check when the author and signer domains do not 
match.  How hard is that?


Any proposed text should cover these main points.

--
HLS

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[Ubuntu-x-swat] [Bug 2004237] Re: Intel Raptor Lake-P support for intel-media-driver in jammy

[Hector CAO]

It also works for the free version of intel media driver

ubuntu@ubuntu-Latitude-7440:~$ sudo apt policy intel-media-va-driver
intel-media-va-driver:
  Installed: 22.3.1+dfsg1-1ubuntu2
  Candidate: 22.3.1+dfsg1-1ubuntu2
  Version table:
 *** 22.3.1+dfsg1-1ubuntu2 500
500 http://archive.ubuntu.com/ubuntu jammy-proposed/universe amd64 
Packages
100 /var/lib/dpkg/status
 22.3.1+dfsg1-1ubuntu1 500
500 http://tw.archive.ubuntu.com/ubuntu jammy-updates/universe amd64 
Packages
 22.3.1+dfsg1-1 500
500 http://tw.archive.ubuntu.com/ubuntu jammy/universe amd64 Packages


ubuntu@ubuntu-Latitude-7440:~$ vainfo
libva info: VA-API version 1.14.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_14
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.14 (libva 2.12.0)
vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 22.3.1 ()
vainfo: Supported profile and entrypoints
  VAProfileNone   : VAEntrypointVideoProc
  VAProfileNone   : VAEntrypointStats
  VAProfileMPEG2Simple: VAEntrypointVLD
  VAProfileMPEG2Main  : VAEntrypointVLD
  VAProfileH264Main   : VAEntrypointVLD
  VAProfileH264Main   : VAEntrypointEncSliceLP
  VAProfileH264High   : VAEntrypointVLD
  VAProfileH264High   : VAEntrypointEncSliceLP
  VAProfileJPEGBaseline   : VAEntrypointVLD
  VAProfileJPEGBaseline   : VAEntrypointEncPicture
  VAProfileH264ConstrainedBaseline: VAEntrypointVLD
  VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP
  VAProfileVP8Version0_3  : VAEntrypointVLD
  VAProfileHEVCMain   : VAEntrypointVLD
  VAProfileHEVCMain   : VAEntrypointEncSliceLP
  VAProfileHEVCMain10 : VAEntrypointVLD
  VAProfileHEVCMain10 : VAEntrypointEncSliceLP
  VAProfileVP9Profile0: VAEntrypointVLD
  VAProfileVP9Profile0: VAEntrypointEncSliceLP
  VAProfileVP9Profile1: VAEntrypointVLD
  VAProfileVP9Profile1: VAEntrypointEncSliceLP
  VAProfileVP9Profile2: VAEntrypointVLD
  VAProfileVP9Profile2: VAEntrypointEncSliceLP
  VAProfileVP9Profile3: VAEntrypointVLD
  VAProfileVP9Profile3: VAEntrypointEncSliceLP
  VAProfileHEVCMain12 : VAEntrypointVLD
  VAProfileHEVCMain422_10 : VAEntrypointVLD
  VAProfileHEVCMain422_12 : VAEntrypointVLD
  VAProfileHEVCMain444: VAEntrypointVLD
  VAProfileHEVCMain444: VAEntrypointEncSliceLP
  VAProfileHEVCMain444_10 : VAEntrypointVLD
  VAProfileHEVCMain444_10 : VAEntrypointEncSliceLP
  VAProfileHEVCMain444_12 : VAEntrypointVLD
  VAProfileHEVCSccMain: VAEntrypointVLD
  VAProfileHEVCSccMain: VAEntrypointEncSliceLP
  VAProfileHEVCSccMain10  : VAEntrypointVLD
  VAProfileHEVCSccMain10  : VAEntrypointEncSliceLP
  VAProfileHEVCSccMain444 : VAEntrypointVLD
  VAProfileHEVCSccMain444 : VAEntrypointEncSliceLP
  VAProfileAV1Profile0: VAEntrypointVLD
  VAProfileHEVCSccMain444_10  : VAEntrypointVLD
  VAProfileHEVCSccMain444_10  : VAEntrypointEncSliceLP

-- 
You received this bug notification because you are a member of Ubuntu-X,
which is subscribed to intel-media-driver in Ubuntu.
https://bugs.launchpad.net/bugs/2004237

Title:
  Intel Raptor Lake-P support for intel-media-driver in jammy

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/intel-media-driver/+bug/2004237/+subscriptions


___
Mailing list: https://launchpad.net/~ubuntu-x-swat
Post to : ubuntu-x-swat@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-x-swat
More help   : https://help.launchpad.net/ListHelp

[Ubuntu-x-swat] [Bug 2004237] Re: Intel Raptor Lake-P support for intel-media-driver in jammy

[Hector CAO]

bug fixed on Jammy with intel-media-va-driver-non-free package in
proposed,

ubuntu@ubuntu-Latitude-7440:~$ sudo apt policy intel-media-va-driver-non-free
intel-media-va-driver-non-free:
  Installed: 22.3.1+ds1-1ubuntu0.1
  Candidate: 22.3.1+ds1-1ubuntu0.1
  Version table:
 *** 22.3.1+ds1-1ubuntu0.1 500
500 http://archive.ubuntu.com/ubuntu jammy-proposed/multiverse amd64 
Packages
100 /var/lib/dpkg/status
 22.3.1+ds1-1 500
500 http://tw.archive.ubuntu.com/ubuntu jammy/multiverse amd64 Packages


ubuntu@ubuntu-Latitude-7440:~$ vainfo
libva info: VA-API version 1.14.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_14
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.14 (libva 2.12.0)
vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 22.3.1 ()
vainfo: Supported profile and entrypoints
  VAProfileNone   : VAEntrypointVideoProc
  VAProfileNone   : VAEntrypointStats
  VAProfileMPEG2Simple: VAEntrypointVLD
  VAProfileMPEG2Simple: VAEntrypointEncSlice
  VAProfileMPEG2Main  : VAEntrypointVLD
  VAProfileMPEG2Main  : VAEntrypointEncSlice
  VAProfileH264Main   : VAEntrypointVLD
  VAProfileH264Main   : VAEntrypointEncSlice
  VAProfileH264Main   : VAEntrypointFEI
  VAProfileH264Main   : VAEntrypointEncSliceLP
  VAProfileH264High   : VAEntrypointVLD
  VAProfileH264High   : VAEntrypointEncSlice
  VAProfileH264High   : VAEntrypointFEI
  VAProfileH264High   : VAEntrypointEncSliceLP
  VAProfileVC1Simple  : VAEntrypointVLD
  VAProfileVC1Main: VAEntrypointVLD
  VAProfileVC1Advanced: VAEntrypointVLD
  VAProfileJPEGBaseline   : VAEntrypointVLD
  VAProfileJPEGBaseline   : VAEntrypointEncPicture
  VAProfileH264ConstrainedBaseline: VAEntrypointVLD
  VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
  VAProfileH264ConstrainedBaseline: VAEntrypointFEI
  VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP
  VAProfileVP8Version0_3  : VAEntrypointVLD
  VAProfileHEVCMain   : VAEntrypointVLD
  VAProfileHEVCMain   : VAEntrypointEncSlice
  VAProfileHEVCMain   : VAEntrypointFEI
  VAProfileHEVCMain   : VAEntrypointEncSliceLP
  VAProfileHEVCMain10 : VAEntrypointVLD
  VAProfileHEVCMain10 : VAEntrypointEncSlice
  VAProfileHEVCMain10 : VAEntrypointEncSliceLP
  VAProfileVP9Profile0: VAEntrypointVLD
  VAProfileVP9Profile0: VAEntrypointEncSliceLP
  VAProfileVP9Profile1: VAEntrypointVLD
  VAProfileVP9Profile1: VAEntrypointEncSliceLP
  VAProfileVP9Profile2: VAEntrypointVLD
  VAProfileVP9Profile2: VAEntrypointEncSliceLP
  VAProfileVP9Profile3: VAEntrypointVLD
  VAProfileVP9Profile3: VAEntrypointEncSliceLP
  VAProfileHEVCMain12 : VAEntrypointVLD
  VAProfileHEVCMain12 : VAEntrypointEncSlice
  VAProfileHEVCMain422_10 : VAEntrypointVLD
  VAProfileHEVCMain422_10 : VAEntrypointEncSlice
  VAProfileHEVCMain422_12 : VAEntrypointVLD
  VAProfileHEVCMain422_12 : VAEntrypointEncSlice
  VAProfileHEVCMain444: VAEntrypointVLD
  VAProfileHEVCMain444: VAEntrypointEncSliceLP
  VAProfileHEVCMain444_10 : VAEntrypointVLD
  VAProfileHEVCMain444_10 : VAEntrypointEncSliceLP
  VAProfileHEVCMain444_12 : VAEntrypointVLD
  VAProfileHEVCSccMain: VAEntrypointVLD
  VAProfileHEVCSccMain: VAEntrypointEncSliceLP
  VAProfileHEVCSccMain10  : VAEntrypointVLD
  VAProfileHEVCSccMain10  : VAEntrypointEncSliceLP
  VAProfileHEVCSccMain444 : VAEntrypointVLD
  VAProfileHEVCSccMain444 : VAEntrypointEncSliceLP
  VAProfileAV1Profile0: VAEntrypointVLD
  VAProfileHEVCSccMain444_10  : VAEntrypointVLD
  VAProfileHEVCSccMain444_10  : VAEntrypointEncSliceLP

-- 
You received this bug notification because you are a member of Ubuntu-X,
which is subscribed to intel-media-driver in Ubuntu.
https://bugs.launchpad.net/bugs/2004237

Title:
  Intel Raptor Lake-P support for intel-media-driver in jammy

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/intel-media-driver/+bug/2004237/+subscriptions


___
Mailing list: https://launchpad.net/~ubuntu-x-swat
Post to : ubuntu-x-swat@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-x-swat
More help   : 

Re: [dmarc-ietf] Two basic Issues to address to help complete DMARCbis

[Hector Santos]

> On Apr 23, 2023, at 4:17 PM, Dotzero  wrote:
> 
> On Sun, Apr 23, 2023 at 1:20 PM Hector Santos 
> mailto:40isdg@dmarc.ietf.org>> wrote:
>> 
>> With each year, that "temporary hack" becomes the new normal and it 
>> will be harder to clean up. It is not the right way and I don't  its 
>> too late to reverse.  However, it has been 17 years and DMARCbis is 
>> not finished without some clean up in this area.
> 
> It HAS NOT been 17 years for either DMARC (first published in 2011  and first 
> submitted to IETF as informational in 2015) or DMARCbis. Let's at least use 
> publicly available data points for time frames rather than time frames pulled 
> out of thin air.

Wow.  I’ll apologize for the confusion. Allow me to paraphrase it:

“However, it has been 17 years since the evolution of SSP, DSAP, ADSP, ATPS and 
now DMARCbis and unfortunately it is not finished without some clean up in this 
area.”

A little better, I hope.

I see all of the as a DKIM Policy Model and DMARC just happens to be current 
rendition of the concept.  I have worked with all of them and before that, we 
did a real security analysis and requirements work.  Not sure if you 
participated in this early DKIM wg work.

>> 
>> I can understand why DMARCbis's editor does not want to document  
>> rewrite, but imto, can't be ignored anymore.   The details of a 
>> rewrite can be quickly outlined.  To help the RFC process, maybe 
>> DMARCbis could refer to the Functional Specifications of SSP (RFC5016) 
>> Section 5.3, Item 10 which basically reinforces the idea that local 
>> policy ALWAYS prevails and it is quite possible there will be 
>> undesirable tearing down of secured submissions.  One possible 
>> mitigation is to replaced it with a secured rewriter with a p=reject 
>> policy.
> 
> SSP is long gone and failed. Referencing something which failed to gain 
> support many years ago is also not a path to go down. 


I referenced the Functional Specification for SSP (RFC5016), not the SSP itself 
which was still only in draft form.  
https://datatracker.ietf.org/doc/html/draft-allman-dkim-ssp-02

The development and point of RFC4866 and RFC5016 was to help Eric and Jim 
create SSP and thats when Levine’s ADSP stepped in.  From a software 
engineering standpoint, the documents provided the security analysis and 
requirements to make a "SSP” protocol.  It does not change the original 
analysis or requirements. 

Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)
https://datatracker.ietf.org/doc/html/rfc4686

Requirements for a DomainKeys Identified Mail (DKIM) Signing Practices Protocol
https://datatracker.ietf.org/doc/html/rfc5016

Please review these, especially Section 5.3 of RFC5016.  I was sort of helping 
DMARCbis.  It can refer that provision to maybe justify the rewrite.  After 
all, it was a game changer in all this when it was added.

—
HLS

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] Two basic Issues to address to help complete DMARCbis

[Hector Santos]

On 4/23/2023 6:10 AM, Alessandro Vesely wrote:


Meanwhile, digressions about ATPS and similar schemes can help 
casting some light on future evolution.  From: rewriting cannot be 
the final solution; it is a temporary hack.  Digressions don't slow 
down the publication, as discussions about actual text quickly 
prevail.  They are just a mean to help convergence toward a common 
vision of the future.


With each year, that "temporary hack" becomes the new normal and it 
will be harder to clean up. It is not the right way and I don't  its 
too late to reverse.  However, it has been 17 years and DMARCbis is 
not finished without some clean up in this area.


First, Section 4.4.3 should have text on using extended tag methods to 
provide 3rd party authorization methods.  Just add the RFC 6541 
abstract or version of it:


ATPS [RFC6541] is an experimental specification proposed which 
adds a extended tag "atps=" allowing
advertisement of third-party signature authorizations that are to 
be interpreted as equivalent to a signature
added by the administrative domain of the message's author. ATPS 
was designed for ADSP.  There is interest to
apply this tag to DMARC to help deal with unchecked but 
authorized resigners false positives.


Second, there are possible outcomes with members using restrictive 
domains:


1) Legacy MLS/MLM, unaware of protocol, unchanged author domain, 
submission mail integrity is broken due to long time practice of body 
and subject changes, can cause members of a list to be 
auto-unsubscribed when their receivers begin to honor p=reject and 
reject mail integrity DKIM failures.


2) Protocol Awareness, honoring the policy, constraining subscription 
and submissions to unsecured submissions.  Restrictive domains not 
acceptable for list submissions.  Note: It is possible to allow a 
Read-Only List Member concept.


3) Protocol Awareness, not honoring policy and tearing down the author 
security, replacing with unsecured distribution.


The correct way for any protocol is to close security  loopholes. In 
this case, recommend #2 using Subscription and Submission controls.  
Let the author domain figure it out.  DMARCbis MUST recognize if the 
intent of the domain is to clean up their brand, by implementing hard 
failure rejects at both SPF and DMARC, then it should recommend 
handlers SHOULD honor the policy of the domain or be prepared for the 
possible false positives.


I can understand why DMARCbis's editor does not want to document 
rewrite, but imto, can't be ignored anymore.   The details of a 
rewrite can be quickly outlined.  To help the RFC process, maybe 
DMARCbis could refer to the Functional Specifications of SSP (RFC5016) 
Section 5.3, Item 10 which basically reinforces the idea that local 
policy ALWAYS prevails and it is quite possible there will be 
undesirable tearing down of secured submissions.  One possible 
mitigation is to replaced it with a secured rewriter with a p=reject 
policy.


I don't think the above will take long to do and I believe will help 
resolve the conflict.


--
Hector Santos,
https://santronics.com
https://winserver.com



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[Bug rtl-optimization/109585] Carla/sord miscompiled with -O2 on ARM64 with flexible array member

[hector at marcansoft dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109585

--- Comment #15 from Hector Martin  ---
The prior repro was too complex and depended on other environmental stuff (some
other people couldn't repro it on arm64 either), so please ignore it. If the
reduced repro triggers the issue, it's the same bug.

Re: [dmarc-ietf] Definitely no Delegated authentication for Gmail

[Hector Santos]

Barry,  

This is wrong. He knows his post was not off-list. His defamation of my 
character is out of line. But he does it to those disagrees with. He is 
smarting than all of us. So nothing knew.

Levine, editor of ADSP and the editor DMARCbis, needs to finally support DKIM 
Policy or give up editorship to a DKIM Policy Advocate engineer who does.

You will see how fast it will be finished.  This document will not change 
anything regarding p=reject but only promote a rewrite, tearing down DMARC 
security  as the only solution. Even if he refuses to write about it  he uses 
it to tear down the very essence of the document purpose in life.

The long time interference with the high interest for a DKIM Policy solution 
needs to finally end. 

—
HLS

> On Apr 22, 2023, at 5:22 PM, John Levine  wrote:
> 
> [[ rather off list ]]
> 
> I think we all established a long time ago that the Internet that
> Hector uses is very unlike the one the rest of us use, and it's not
> worth arguing with him.
> 
> That said, I really wish the chairs would shut down the trolls.  They may
> not think they're trolls, but they are having the classing trolling effect
> of wasting time and driving people away.
> 
> R's,
> John
> 
> 
> It appears that Dotzero  mailto:dotz...@gmail.com>> said:
>> -=-=-=-=-=-
>> 
>> On Sat, Apr 22, 2023 at 2:04 PM Hector Santos > 40isdg@dmarc.ietf.org> wrote:
>> 
>>> 
>>> On Apr 22, 2023, at 12:58 PM, John Levine  wrote:
>>> 
>>> It appears that Jesse Thompson   said:
>>> 
>>> -=-=-=-=-=-
>>> 
>>> A DNS-based lookup, perhaps in the style of ATSP as this thread is
>>> describing, to query for not just domain-level authorization, but also
>>> potentially user-level authorization, I think is
>>> compelling because it can:
>>> 
>>> 
>>> Once again, no. This is not mission creep, it is mission gallop.
>>> 
>>> 
>>> The current mission is chaos!!  I sometimes wonder If the intent is to
>>> keep it chaotic to show non-consensus in really the strategy.  Jesse was
>>> referring to user policies.  ATPS is about domain policies.  Lets not
>>> confuse this.
>>> 
>>> Nobody uses ATSP, nobody is going to use ATSP, this is just yet more
>>> distraction and wheel spinning that is keeping us from finishing.
>>> 
>>> 
>>> -1
>>> 
>>> First, not true, there is running code using ATPS, and you know it.
>>> Second, there are APIs that support it.  It may be disabled in the open
>>> source but it's there. Second, when an editor does not champion his own
>>> work, it will be much harder to sell.  There is absolute no reason why a
>>> receiver can not to an ATPS check if its already doing an DMARC with false
>>> positive results due to not doing an ATPS.
>>> 
>>> What has kept us from finishing this 17+ year project was the editor of
>>> ADSP and now editor of DMARCbis preventing 3rd party authorization
>>> concepts.  He removed it from SSP when it was hijacked with ADSP.   To his
>>> credit, its on the record, he didn’t want people using ADSP and was
>>> successful to get it abandoned as a proposed standard and made it historic.
>>> 
>> 
>> You are incorrect that SSP was "hijacked" by ADSP.  I was the one who
>> suggested the change from Sender Signing Protocol to Author Domain Signing
>> Protocol because the effort was about domains and NOT individuals. It was
>> ONLY a name change. As with many other efforts there was evolution, both
>> before the name change (which occurred around SSP 11 if I remember
>> correctly) and after. Anyone can go back to the list archives to verify
>> this.
>> 
>>> 
>>> But DMARC snuck in via M3 as an Informational status and since he can’t
>>> stop domains from using DMARC, he took over the editing of DMARCbis and now
>>> wants a MUST NOT p=reject without explaining how to best avoid its problems
>>> for existing systems.
>>> 
>> 
>> As one of the original organizers of the DMARC effort I object to your
>> characterization of DMARC as having "snuck in via M3". The DMARC effort
>> coalesced when an earlier effort called MOOCOW organized by JD Falk failed.
>> (I had declined to participate in MOOCOW because I believed early on that
>> it was doomed to fail.) Yes, some of the DMARC meetings took place
>> immediately preceding M3 meetings as a matter of convenience but many more
>> took place online or were hosted by participating organizations at their
>> offices. There were 

Re: [dmarc-ietf] Definitely no Delegated authentication for Gmail

[Hector Santos]

> On Apr 22, 2023, at 12:58 PM, John Levine  wrote:
> 
> It appears that Jesse Thompson   said:
>> -=-=-=-=-=-
>> 
>> A DNS-based lookup, perhaps in the style of ATSP as this thread is 
>> describing, to query for not just domain-level authorization, but also 
>> potentially user-level authorization, I think is
>> compelling because it can:
> 
> Once again, no. This is not mission creep, it is mission gallop.

The current mission is chaos!!  I sometimes wonder If the intent is to keep it 
chaotic to show non-consensus in really the strategy.  Jesse was referring to 
user policies.  ATPS is about domain policies.  Lets not confuse this.

> Nobody uses ATSP, nobody is going to use ATSP, this is just yet more
> distraction and wheel spinning that is keeping us from finishing.

-1

First, not true, there is running code using ATPS, and you know it.  Second, 
there are APIs that support it.  It may be disabled in the open source but it's 
there. Second, when an editor does not champion his own work, it will be much 
harder to sell.  There is absolute no reason why a receiver can not to an ATPS 
check if its already doing an DMARC with false positive results due to not 
doing an ATPS.

What has kept us from finishing this 17+ year project was the editor of ADSP 
and now editor of DMARCbis preventing 3rd party authorization concepts.  He 
removed it from SSP when it was hijacked with ADSP.   To his credit, its on the 
record, he didn’t want people using ADSP and was successful to get it abandoned 
as a proposed standard and made it historic. 

But DMARC snuck in via M3 as an Informational status and since he can’t stop 
domains from using DMARC, he took over the editing of DMARCbis and now wants a 
MUST NOT p=reject without explaining how to best avoid its problems for 
existing systems.

Yet, his answer to the DMARC problem, as a single implementation with IETF 
list, is to strip the security of a domain using a Rewrite and does not want to 
document it as a DMARCBis solution to the problem he refuses to help fix, nor 
document the subscription/submission restrictions method, something he could 
have done rather than introduce an unfortunate mail engineering taboo to they 
industry - a new security loophole with caused by this rewrite:

 Destroyed Mail Authorship Authentication Replays

I almost believe he wants DMARCBis to fail as a Proposed Standard, therefore 
refusing to also change it back to informational status as suggested by Barry 
Leibre since it would give DMARCbis a better chance of surviving IETF 
engineering scrutiny and passing last call.

As a proposed standard, there will be friction when ADSP was abandoned for 
reasons DMARCBis is not resolving other than saying don’t use restrictive 
domains.   That’s what slowing this down.

—
HLS___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Delegated authentication for Gmail

[Hector Santos]

Here is an scenario I long envisioned with high-valued services implementing a 
DKIM Policy model.

Example: bank and a new online banking customer:

Bank:  "For online banking we need an email address for secured private email 
communications."

User:  "hmm, user.n...@esp1-domain.com "

Bank:  "OK, let me check its security………please wait…."

Bank does some DNS lookups and finds no DKIM POLICY record. At the time,  it 
was SSP, ADSP, DSAP.  Imagine today, the bank checks DMARC and finds no record 
for esp1-example.com .

Bank:  "I’m sorry, this email address is not considered secured. Do you have 
another?"

User:  "Yes, I have another.n...@esp2-domain.com 
 try that."

Bank sees the domain has a SPF all? neutral policy and a DMARC p=none policy.

Bank:  "Mr. User, this email address is not secured for our secured banking 
needs with your new online account. How about we assigned you a new secured 
bank address.  new.u...@secured-users.bank.net 
”

User:  "Ok, but wow, another address I have to remember??  Can I use my 
iCloud.com account?

Bank: “iCloud.com is a secured domain.  You can use that email.”

So the user had the option to use a secure domain account or the user would be 
assigned one by the service.

That’s how I saw it high-value transactions and companies moving,   That 
special address MAY BE a 3rd party too bank authorized via ATPS.

The unsecured domain ESP user simply can not be used with private services 
where the data exchanges need to be 100% transported authenticated and 
authorized.   The current practice with the majority of MLM, at least as I 
experienced with then IETF list, break the security in the name of not stopping 
the mail flow.


---
HLS


> On Apr 22, 2023, at 9:53 AM, Jesse Thompson  wrote:
> 
> On 4/22/2023 6:20 AM, Alessandro Vesely wrote:
>> Those kinds of sender-side authorization schemes seem to be designed for 
>> ESP-like businesses, where a domain owner delegates Domain2 to send messages 
>> on its behalf.  Using such schemes for mailing lists, thereby going down to 
>> per-user records sounds improper and bloats the amount of DNS stuff.
> Does it bloat DNS more than DNSBLs do? Would it make more sense if it were 
> done via HTTPS?
> 
> Here's what I see in the real world:
> * Organization's policy dictates "use a subdomain" for non-general-purpose 
> use cases. 
> * Legacy non-general-purpose use of the org domain is tolerated because there 
> is no easy migration path. 
> * People within the organization instinctively want to use the org domain.
> * They're very confused how it works technically, they try to pull strings to 
> get what they want.
> * Eventually a person high enough in the organization intervenes.
> * So, the domain owner has no choice but to authorize the ESP to use the 
> entire org domain, yet again.
> 
> Why is it improper for a domain owner to have an ability to delegate 
> per-user? I understand that it may be technically infeasible, but why is it 
> improper?
> 
> I'm still not certain why ESPs are fundamentally different than mailing lists.
> ESP: A message author confirms their identity with the ESP and asks the ESP 
> to emit mail with their rfc5322.From address
> MLM: A message author confirms their identity with the MLM and asks the MLM 
> to emit mail with their rfc5322.From address
> 
> 
> 
>> To address mailing list and forwarding for address portability, I'd rather 
>> devise receiver-side schemes, whereby the final receiver acknowledges that 
>> the email address of a user of its has been written to a file that produces 
>> mailing list of forwarding effects, while the author domain is not involved 
>> at all.  A very rough idea here:
>> https://datatracker.ietf.org/doc/draft-vesely-email-agreement/
> 
> A scheme like this seems just as applicable to ESPs as it does mailing lists, 
> insofar as mutual consensus of confirmed opt-in can be achieved between all 3 
> parties.
> 
> 
>> "Upon user confirmation, that MTA itself confirms the subscription to the 
>> MLM."
> 
> Since you mentioned this enables address portability: If the user changes 
> mailbox providers, how do they communicate all of their prior confirmed 
> subscriptions to the MTA? How does the MLM know if the confirmed 
> subscriptions have not been back-filled?
> 
> Jesse
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Delegated authentication for Gmail

[Hector Santos]

> On Apr 21, 2023, at 10:19 PM, Douglas Foster 
>  > wrote:
> 
> I mean something different.
> 
> By "user-to-domain" I mean a DNS function which asserts:
> When the message is signed by IETF, and the From address is my account, the 
> message is considered authenticated by this DNS entry.
> If the message is signed by IETF but the From address is a different account 
> in the same domain, the message is not authenticated by this DNS entry.o
That’s the conceptual TPA protocol theory.  Consider SPF has a TPA system when 
the possible external MTA (smtp client machine) was “authorized” by IP address. 
  It took a while before domains were adding -include _spf.google.com 
 to their SPF primary domain records.  Conceptually, 
that is what ATPS, TPA, DSAP ideas offered to DKIM+ADSP and now DKIM+DMARC.   

> We have three uses cases:
> The owner of an account on a mailbox provider such as Gmail, who wants to 
> create an ESP account for mass mailings.   Girl Scout troops were mentioned 
> as a community that had this problem after the Yahoo lockdown.
> 
> The subscriber to a mailing list who wants to authorize the list owner to 
> send messages using his From identity.  We all have this problem.
> 
> And the newly introduced problem of the domain owner who is not willing to 
> delegate a DKIM scope.   They might be willing to authorize the ESP to send 
> messages on behalf of market...@example.com , 
> until they realize that it also authorizes the ESP to send on behalf of 
> c...@example.com  .   The ESP is willing to accept a 
> DKIM scope, but the management sees the delegation as too risky.

1) This scenario is a typical one.  Mailing list had early esp domains, 
yahoo.com , gmail.com , msn.com 
, so many that become “spam-polluted” that at one point, I was 
among those calling for a flat out block of these highly abusive domains.I 
give many kudos for AOL.COM  to start with a hard reject with 
SPF and jump start the MARID working group that began the SPF and the DKIM era. 
 YAHOO.COM  finally said enough with DMARC p=reject and why 
not? Yahoo invented DomainKeys with the reject concept "o=-“ tag on the 
signature, no DNS lookup needed. So no one should be surprise that the patented 
idea finally was activated via DMARC p=reject.   

2) This scenario is also typical - the subscriber with DNS control of the 
domain to add an authorization record.  That would be me and a good bit of the 
developers here.

3) This is not new. In fact, it has been the #1 reason for DKIM with a POLICY 
enforcement concept.  It is the #1 payoff.  It was the strongest, the most 
restrictive policy. Original DKIM had o=- which was split into SSP with other 
o= signing patterns, which was replaced with ADSP with Discardable and now 
DMARC with p=reject.  The concept was so powerful,  the Functional 
Specification for SSP indicated that it MUST NOT trump local policy.What 
happen with DMARC causing From Rewrite is a reminder of local policy can not be 
controlled by author domain policy.

> 
> To solve these use cases, we need a DNS lookup that is based on the fully 
> qualified From address and the DKIM domain.   In concept, it seems like a 
> straightforward extension of any of the third-party signing strategies.   


The Domain Policy Model I believe is sufficient than a Domain User Policy.  It 
would also be Using email address would need to be manageable via DNS.
 
TPA has scoping logic that was too complex for me to follow.  ATPS was simpler. 
   You might follow Doug Otis’s TPA better than I did.

> 
> What I see as the primary difficulty is the need to publish a DNS entry which 
> is specific to my email account, without announcing to every spammer in the 
> world that my account is an available spam target.Hashing helps, but 
> creates collisions.   To avoid side-channel authorizations, we need a way to 
> disaggregate collisions.   ATSP does that by providing the domain name in 
> cleartext, but that I don't see that as acceptable for a user account.   Some 
> critics may argue that hashing is not an adequate data-hiding technique 
> anyway,
> 
> It would be the solution to the great mailing list problem if we can make it 
> work.   But is that possible?


We can make anything happen with software changes.  This requires changes to 
legacy mail unit operations, MSA, MDA, MLS, MTA, the C/C++ SMTP developers, the 
Mail Men, the transporters, and changes to the "low code”  that makes up MLM 
scipts for the Administrators.

For a long time, starting with FidoNet [1] and also with the IETF too, I 
experienced a good bit of the debates with future methods and directions was 
often a clash between Developers vs Administrators.  Basically software 
developers want to do it right - cross all the tees, dot 

Re: [dmarc-ietf] Delegated authentication for Gmail

[Hector Santos]

> On Apr 21, 2023, at 2:14 PM, Douglas Foster 
>  wrote:
> 
> Can it provide a user-to-domain authentication solution?   

Unless I am not following you, DKIM inherently provides "user-to-domain" 
authentication by hash binding the 5322 From: and To: headers.  

> That is what mailing lists need and that is what mailbox provider clients 
> need.  These use cases are pretty fundamental to our objective of getting 
> mail authenticated without causing damage 

A mailing list is a 1 to Many distribution.  Legacy mail integrity lost was a 
normal practice for a list system, i.e, footers. Well, technically no.  For 
DKIM, if you used the l= content length tag and did not change the subject 
line, the original signature could survive. 


GMAIL could easily provide a box for their users that authorized signers and 
MTAs.  Come inbound time, it can check for the authorize the MTA and 3rd party 
signer.  

What I am missing, Google boys? 


—
HLS



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Delegated authentication for Gmail

[Hector Santos]

Doug,

You might want review Doug Otis’s TPA (Third Party Authorization).  It has a 
higher scale method. 

https://datatracker.ietf.org/doc/draft-otis-dkim-tpa-ssp/

Abstract


TPA-label is a DNS-based prefix mechanism for DKIM policy records as a means to 
authorize Third-Party domains. This mechanism allows first-party domains to 
autonomously authorize a range of third-party domains in a scalable, individual 
DNS transaction. This authorization extends the scope of DKIM policy assertions 
to supplant more difficult to administer mechanisms. Alternatives for 
facilitating third-party authorizations currently necessitate the coordination 
between two or more domains by setting up selector/key DNS records, DNS zone 
delegations, or the regular exchange of public/ private keys. Checking DKIM 
policies may occur when a From header email-address is not within the domain of 
a valid DKIM signature. When a Third-Party signature is found, TPA-labels offer 
an efficient means for email address domains to authorize specific third-party 
signing domains. The scope of the authorization may separately assert identity 
authentication for From and Sender and Resent-* headers for email- addresses 
within the authorizing domain. Identity authentication can be asserted by the 
scope of the authorization, even when signed by a Third-Party domain. In 
addition, the RFC2821.MailFrom domain can authorize domains for controlling 
DSNs.

—
HLS


> On Apr 21, 2023, at 7:15 AM, Douglas Foster 
>  wrote:
> 
> Thinking on this some more, there are some tricky design risks:
> If the user-to-domain delegation scheme exposes an email address to the 
> world, that information may be used for unwanted purposes, particularly 
> increased spam volumes.   Hashing provides part of that solution.   The ATSP 
> document solves this problem by using a mix of hash and cleartext domain 
> name, but we should not expose a cleartext username.
> 
> Hash algorithms are intended to create enough collisions so that reversing 
> the hash is not practical, but the lookup process needs to ensure uniqueness 
> so that a delegation record does not create unauthorized secondary 
> delegations.   Similarly, the domain owner needs a way to clean up his DNS 
> when an account is terminated.   This includes removing delegations for the 
> terminated account without causing mistakes caused by hash collisions.   So 
> some form of tiebreaker will be needed to ensure uniqueness.
> Mitigation ideas:
> A user-to-domain delegation always uses plus addressing.  This increases 
> randomness of the hash process and adds complexity to hash-reversal attacks.  
>  It also simplifies privacy recovery if the plus address is compromised.
> The delegation record lookup uses a hash key based on the authorizing user 
> and the signing domain concatenated together, and a secondary key based on 
> the signing domain alone.   I don't know whether it will be better to look up 
> the signing domain using hash or cleartext.
> To handle the hopefully rare case where a hash collision still occurs, the 
> domain owner creates multiple delegation records and assigns them a record 
> number which is used internally to associate a specific record with a 
> specific user account.
> Doug
> 
> On Thu, Apr 20, 2023 at 6:24 PM Douglas Foster 
>  > wrote:
>> Murray's ATSP proposal (https://www.ietf.org/rfc/rfc6541.txt) and Hector's 
>> DSAP proposal 
>> (https://datatracker.ietf.org/doc/html/draft-santos-dkim-dsap-00) have a 
>> similar goal:   Allow "Domain2" to send authenticated messages for "Domain1".
>> This is authorized when
>> the message is signed by "Domain2" and
>> a DNS entry in "Domain1" is configured to authorizes "Domain2" as a 
>> delegated signer.
>> (I will use RFC6541 as my primary reference because it seems to have avoided 
>> scaling problems.)
>> 
>> A mailbox account owner cannot benefit from these ideas because he needs the 
>> ability to define a user-authorizes-domain or user-authorizes-user 
>> relationship.   Consequently, we should extend the RFC 6541 design to 
>> support a subkey of the form:
>> ._users.._atsp...
>> 
>> Query sequence:
>> The initial query is for an ATSP policy at 
>> ._atsp..  If it returns a result that 
>> authorizes the signatures, the search stops.
>> If the query returns NXDOMAIN, no further search is needed because the 
>> _users subkey does not exist.
>> Otherwise, a second query is performed for an ATSP policy at 
>> ._Users.._atsp ..  If a valid 
>> result is found, the signature is also authorized.  T
>> The DNS entries for user-level authentication would be created automatically 
>> by the mailbox provider upon request from the user.
>> 
>> This approach gives the mailbox provider the ability to control which 
>> delegated domains are allowed.   If a third-party signer is badly behaved, 
>> the mailbox domain could remove all of its delegated signing entries and 
>> prevent new ones.   A 

[Bug middle-end/109585] Carla/sord miscompiled with -O2 on ARM64 (inlining issue)

[hector at marcansoft dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109585

--- Comment #11 from Hector Martin  ---
Giving a nonzero size to the `ZixBTreeIterFrame stack[]` member also avoids the
segfault, so this might be a flexible array member thing.

[Bug middle-end/109585] Carla/sord miscompiled with -O2 on ARM64 (inlining issue)

[hector at marcansoft dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109585

--- Comment #9 from Hector Martin  ---
Yes, a strict aliasing violation could explain the behavior of the optimizer
here... but given all the types are identical and there is no casting going on,
clearly there is no strict aliasing violation.

[Bug target/109585] Carla/sord miscompiled with -O2 on ARM64 (inlining issue)

[hector at marcansoft dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109585

--- Comment #6 from Hector Martin  ---
Cleaned it up into a self-contained repro. Simply compiling with `gcc -O2 -o
test test.c && test` gives a segfault. -O1 or -fno-schedule-insns
-fno-schedule-insns2 avoids the issue.

Looking at assembly output on godbolt, it seems this likely goes at least as
far back as 11.1 if not earlier.

[Bug target/109585] Carla/sord miscompiled with -O2 on ARM64 (inlining issue)

[hector at marcansoft dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109585

--- Comment #5 from Hector Martin  ---
Created attachment 54904
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54904=edit
self-contained reproducer

[Bug target/109585] Carla/sord miscompiled with -O2 on ARM64 (inlining issue)

[hector at marcansoft dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109585

--- Comment #4 from Hector Martin  ---
This whole codebase is complex, and the problem is in btree code which is hard
to simplify down. Best I can do right now is this. First grab the lv2.tar.gz
attachment and extract it into /tmp. Then:

$ git clone https://github.com/falkTX/Carla
$ cd Carla && make -C source/modules/lilv
$ cat > test.c << EOF
#include "lilv/lilv.h"

int main(int argc, char **argv)
{
LilvWorld* world = lilv_world_new();

lilv_world_load_all(world, "/tmp/lv2");
}
EOF
$ gcc -I source/includes/ -I source/modules/lilv/lilv-0.24.0/ -o test test.c
./build/modules/Release/lilv.a -lm
$ ./test

Compiling with -fno-schedule-insns -fno-schedule-insns2 seems to work properly.

[Bug target/109585] Carla/sord miscompiled with -O2 on ARM64 (inlining issue)

[hector at marcansoft dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109585

--- Comment #3 from Hector Martin  ---
Created attachment 54903
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54903=edit
lv2 plugin bundle for testing

[Bug c/109585] Carla/sord miscompiled with -O2 on ARM64 (inlining issue)

[hector at marcansoft dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109585

--- Comment #1 from Hector Martin  ---
Created attachment 54901
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54901=edit
Preprocessed input

[Bug c/109585] New: Carla/sord miscompiled with -O2 on ARM64 (inlining issue)

[hector at marcansoft dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109585

Bug ID: 109585
   Summary: Carla/sord miscompiled with -O2 on ARM64 (inlining
issue)
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hector at marcansoft dot com
  Target Milestone: ---

Created attachment 54900
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54900=edit
Manually annotated disassembly identifying the problem

GCC 12.1.0 miscompiles sord_free() with -O2 due to bad inlining on ARM64.
Reproducible on Compiler Explorer on 12.2 and also trunk.

https://godbolt.org/z/rvxP1oodh (includes full preprocessed input)

I've attached an annotated disassembly. The problem is that
zix_btree_iter_increment() and zix_btree_iter_is_end() are inlined together
into sord_free(), but the `i->stack[0].node == NULL` check in
zix_btree_iter_is_end() somehow got hoisted before the `f->node = NULL;` in
zix_btree_iter_increment(), so the check fails when it pass (ending the loop),
and then the loop body goes on to deref a NULL pointer.

Re: [dmarc-ietf] Is From spoofing an interoperability issue or not?

[Hector Santos]

> On Apr 19, 2023, at 10:29 PM, Jesse Thompson  wrote:
> 
> The choice for both the mailing list and mail-service company is to:
> 
> 1) ignore DMARC and continue to emit mail as the original author intended 
> (the author might be ignorant of DMARC too) and assume the mailbox providers 
> are smart enough to understand that, like mailing lists, mail-service 
> companies and their mail emitting authors shouldn't be caught up by a DMARC 
> misdeployment by the domain owner

This will cause the list bounce problem.  This was seen immediately in the IETF 
list when it 100% ignorance of DKIM.  Signatures broke.  

Solution: Support DKIM and resign as 3rd party
Problem: Policy does not allow a resigner.

No one honored broken signatures, policies. Recorded as fail but no lost until 
YAHOO shook the world and began to honor p=reject policies.  Bounce problem.


> 2) be cognisant of DMARC's effects, and in the interest of keeping the 
> author's mail flowing, use a different domain and put the author's address in 
> the friendly from or similar, or just refuse to accept the messages, until 
> delegation can be set up

> I can say, anecdotally, that people really really want #1 to be true, but 
> they eventually learn #2 leads to a better long term outcome. I'd like that 
> "learning" to be less painful by having something unambiguous to point at in 
> DMARCbis.
> 

We allowed a protocol incomplete to take off without dealing with the known 
potential problem.  No one will honor DKIM policy stuff.

Now its broken.

As a Mailing List Server developer, we need a migration path to a 3rd option 
(ATPS concept) which using #2 temporarily.   Ideally no From destruction is the 
goal.  For now, I use #2 restrictions on subscription and submissions 

—
HLS___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] About UAID User Agent Identity.

[Hector Santos]

ractable by reading DKIM-BASE is:

Assessment = ASSESSOR(SDID, UAID="")

where the UAID is optional.

I argued during the drafting of DKIM-BASE to add back ADID by passing 
the ADID with SDID which is how the original DKIM modeled it:


Assessment = ASSESSOR(ADID, SDID, UAID="")

Unfortunately, I was the only DKIM Policy advocate objecting to 
DKIM-BASE trying to, as its abstract says:


   DKIM separates the question of the identity
   of the Signer of the message from the purported author of the
   message.  Assertion of responsibility is validated through a
   cryptographic signature and by querying the Signer's domain directly
   to retrieve the appropriate public key.


So not even this backward compatible assessment was acceptable to have 
in the DKIM-BASE standard.


Assessment = ASSESSOR(SDID, UAID="", ADID="")

For many here, the reputation of the signer trumps everything.  I 
don't think the DKIM Policy advocates ever disputed the need for 
reputation but as a final layer, not the first layer.


This is why we have had 17 years of a DKIM Policy vs DKIM Reputation 
modeling conflicts in the DKIM-related working groups.  Just keep in 
mind we have no public domain, not proposed method to do a SDID only 
assessment. But we certainly do have a several ADID::SDID assessment 
proposals!


We can't totally separate the ADID from the any SDID assessment. The 
Author ADID, From: header, is the only required header to be hashed 
bound to DKIM-Signature.  It is impossible to be  separated from 
consideration, and the irony is,  if the assessment of the signer is 
negative, it is the Author address, its MTA, its delivery agent 
(return-path) who gets hurt.


ADID can not be separated.  It is a complex situation when you are 
dealing with unsolicited mail when ADID does not equal SDID.   This is 
why DMARC can only focus with a ADID=SDID policy.


Now throw in the UAID and we have additional, complex, extended 
policies to deal with.  We don't know how to use it, optimally, 
especially for a mailing list where thousands of emails need to be 
signed.  Do you sign 1 list distribution for all  or do you sign each 
list outbound message?   Those are big scaling optimization 
considerations.


For the most exclusive policy, via DMARC:

p=reject; adkim=s; aspf=s

everything must match.

for:

p=reject; adkim=r; aspf=r

A little more relaxed for subdomains.

I think what is there is enough for this limited policy which does not 
care for users using the domain outside the main stream.


--
Hector Santos,
https://santronics.com
https://winserver.com





___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Is From spoofing an interoperability issue or not?

[Hector Santos]

On Apr 18, 2023, at 1:11 PM, Alessandro Vesely  wrote:
> 
> Perhaps when DMARC will work smoothly, someone will find out how to tell 
> legitimate rewriting from plain spoof.
> 

Lookup DMARC record and begin to piggy back off this lookup:

- Check for rewrite=1 tag indicating allowance to rewrite. 

- Check for asl= or atps=y signer authorization.

If the domain tells the resigner he can destroy the authorship, you now have a 
legitimate protocol negotiated handshake/contract. I prefer if there was an 
explicit authorization using asl= or atps=y, but an open ended rewrite=1 tag is 
fine, I think.  It is permission the domain is giving to resigners.

—
HLS

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Signaling MLMs

[Hector Santos]

> On Apr 18, 2023, at 12:24 PM, Alessandro Vesely  wrote:
> 
> What's the point of wearing an atps record if it's not called out in a DKIM 
> signature?  (I wouldn't have tested it anyway).


Alessandro, you are already doing the DNS call for DMARC.  Hitch a ride!! You 
can check for atps=y or asl= for 3rd party authorization. 

> What's the point of ARC-sealing a message which is not arrived from an 
> external ADMD?

I have no idea and I think ARC is a waste of time. Way too much overhead.  Not 
a good idea to pursue this has a long term solution.  I rather not.

> I'm rather happy with the amount of gibberish I currently get.  For this 
> Benny's message it was:
> 
> Authentication-Results: wmail.tana.it;
>  spf=pass smtp.mailfrom=ietf.org;
>  dkim=pass reason="transformed" header.d=junc.eu;
>  dkim=pass (whitelisted) header.d=ietf.org
>header.b=yiVUz1hG (ietf1);
>  dkim=pass (whitelisted) header.d=ietf.org
>header.b=yiVUz1hG (ietf1);
>  arc=fail (1 set(s)) smtp.remote-ip=50.223.129.194
> 

So your verifier see Benny’s as suspicious because of arc=fail? 

Benny is telling the world “ietf.org  is authorize to resign 
on my behalf” via DNS.  No headers required.  No delayed learning necessary.

What more is needed?



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[Ubuntu-x-swat] [Bug 2004237] Re: Intel Raptor Lake-P support for intel-media-driver in jammy

[Hector CAO]

@tjaalton : i did not need it to make things work, i might miss anything
?

-- 
You received this bug notification because you are a member of Ubuntu-X,
which is subscribed to intel-media-driver in Ubuntu.
https://bugs.launchpad.net/bugs/2004237

Title:
  Intel Raptor Lake-P support for intel-media-driver in jammy

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/intel-gmmlib/+bug/2004237/+subscriptions


___
Mailing list: https://launchpad.net/~ubuntu-x-swat
Post to : ubuntu-x-swat@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-x-swat
More help   : https://help.launchpad.net/ListHelp

Re: [dmarc-ietf] Signaling MLMs

[Hector Santos]

On 4/17/2023 6:48 PM, Benny Pedersen wrote:

Hector Santos skrev den 2023-04-17 20:55:


One solution is for the junc.eu domain to add an ATPS authorization
record for ietf.org [1] to the junc.eu [2] zone:

pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps  TXT ("v=atps01; d=ietf.org;")


retest


[3] https://winserver.com/public/wcDmarc




Hi Benny,

Thanks for testing!!  The verification on your message showed dmarc=fail.

Apparently, I couldn't completely turn off the ADSP/ATPS logic when I 
added the DMARC/ATPS to the wcDKIM Policy verifier. Once I re-enabled 
ADSP/ATPS, it worked with the expected responses by running the code 
on the saved original inbound message. The Author Domain policy, if 
any, in this case ADSP and DMARC, ares applied to each signature found.


*Authentication-Results: dkim.winserver.com;**
** dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;**
** adsp=none author.d=junc.eu signer.d=ietf.org;**
**dmarc=pass policy=none author.d=junc.eu asl.d=ietf.org (asl signer);**
** dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;**
** adsp=none author.d=junc.eu signer.d=ietf.org;**
**dmarc=pass policy=none author.d=junc.eu asl.d=ietf.org (asl signer);**
**dkim=fail (DKIM_BODY_HASH_MISMATCH) header.d=junc.eu 
header.s=default header.i=@junc.eu;**

** adsp=dkim-fail author.d=junc.eu signer.d=junc.eu;**
** dmarc=dkim-fail policy=none author.d=junc.eu signer.d=junc.eu 
(originating signer);*



Description.  The DMARC record for junc.eu was updated with two new tags:

*atps=y;asl=ietf.org*

No ADSP record was found.  No ADSP+ATPS policy logic applied. The 
DMARC+ATPS verifier found the asl= signer condition to be true.  If 
asl= was false, the atps=y tag enables an ATPS record lookup for the 
signer domain ietf.org.


Time to update this 2011 code to allow ADSP to be disabled and the new 
DMARCBis new lookup algorithm considerations.


Thanks for exploring this DKIM Policy Model solution with 3rd party 
signer support using DMARC+ATPS.



--
Hector Santos,
https://winserver.com/public/wcADSP
https://winserver.com/public/wcDMARC


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Signaling MLMs

[Hector Santos]

> On Apr 16, 2023, at 11:31 PM, Benny Pedersen  wrote:
> 
> Hector Santos skrev den 2023-04-17 05:06:
> 
>> Anyway, there are far too much waste in electronic mail, ADSP/DMARC
>> and this quest to resolve its issues, creating more junk, ARC, is not
>> getting anywhere.
> 
> ?, spamassassin 4, do something, i use fuglu in prequeue smtpd postfix, works 
> for me atleast, it sometimes helps to be a gentoo ebuild maintainer, i still 
> like to find proxy maintainers helping me
> 
> with arc its sadly appled AFTER mailman have scrampled dkim :/
> 
> arc sign/seal should be done on incomming mails, not on outgoing


Thanks for the information.

Just consider your message source. The header overhead is massively complex to 
read. It is really a waste on receivers.

The final Auth-Result for your message:


Authentication-Results: dkim.winserver.com;
 dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;
 dmarc=fail policy=none author.d=junc.eu signer.d=ietf.org 
(unauthorized signer);
 dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;
 dmarc=fail policy=none author.d=junc.eu signer.d=ietf.org 
(unauthorized signer);
 dkim=fail (DKIM_BODY_HASH_MISMATCH) header.d=junc.eu header.s=default 
header.i=@junc.eu;
 dmarc=dkim-fail policy=none author.d=junc.eu signer.d=junc.eu 
(originating signer);


One solution is for the junc.eu domain to add an ATPS authorization record for 
ietf.org <http://ietf.org/> to the junc.eu <http://junc.eu/> zone:

pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps  TXT ("v=atps01; d=ietf.org;")
to authorize the signer domain ietf.org:

See the wcDMARC wizard:


https://winserver.com/public/wcDmarc


—
HLS___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Is From spoofing an interoperability issue or not?

[Hector Santos]

On 4/17/2023 9:43 AM, Scott Kitterman wrote:


OK.  The discussion of the 5322.From comment through me off, I guess.

I think there's probably room for the IETF to document Bext Current Practices
(BCP) around DMARC usage.  I think it's a step beyond the interoperability
discussion we need for the DMARCbis protocol document.  Assuming we think we
know enough, we might consider that for additional WG scope after we have
(essentially) completed the currently chartered work.



From my readings, my support considerations are:

+1 Codifying a MUST NOT use p=reject for XYZ reasons,
+1 Changing status to Informational, Experimental.

We can't make this a "Standard" when the odds are extremely high there 
is going to be many addressing this DKIM POLICY problem that could not 
be resolved for the 2nd time in nearly 17 years, for the same 
reasons.  Thanks to DMARC.  We have more DKIM Policy advocates today.  
If have had this with ADSP, we would be debating MUST NOT use 
"Discardable" instead use "All".


We should piggyback off DMARC calls.  It would be nice to see support 
by the key cogs for section 4.4.3 and Extended Tag Extensions. 
Suggestion: Add some more text here regarding dealing with authorization.


I consider DMARC today as the new "railroad tracks," the DNS method to 
get a mail operations policy from the Author Domain.  But its policies 
are incomplete. We need to recognize there are other policies other 
than the most restrictive with perfect alignment. We had more 
flexibility with SSP and a few with ADSP  "must be signed by me" and 
"must be signed by someone."   More flexible.


--
Hector Santos,
https://santronics.com
https://winserver.com



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Signaling MLMs

[Hector Santos]

On 4/16/2023 8:43 PM, Neil Anuskiewicz wrote:


Hector, respecfully, I disagree with several of your points.

* You seemes to be saying that when spf fails then usually dkim 
fails, too. I’ve seen first hand that’s nit true.


Yes, most of the times.  The exceptions are the true forwards. It's 
easily resolved.  Have the user prepare to pick up the mail.


* you seemed to be placing too much weight on the value of spf 
hardfail. Even 10 years ago, few receivers rejected on an spf hardfail.


I was one of the early adopters among aol.com and others to promote 
hard fails early on because it was quite evident most of the time it 
was a complete waste of DNS calls when its softfail or especially 
neutral or NXDOMAIN.


All of my wcSMTP customers benefited from the integrated 
wcDKIM/wcDMARC add-on.


As of today, after 20 years of daily data collection, SPF offers 6.3% 
of the INCOMING total rejection rates.   It was a slow climb. None are 
forwarding problems.


I'm pretty sure a huge set of transport outgoing logs of forwarded 
mail were 55z due to SPF hardfail policies.  Not the only one.


Some do but it’s not at all reliable. DMARC is accepted by most as 
the new policy layer. It’s where policy should be handled. The OR 
logic is in part to get away from the policy layer that breaks 
fairly easily (e.g., forwarding). SPF is important but given a 
choice between authenticating with just aligned SPF or just aligned 
DKIM, I’d choose DKIM.


Gmail rejects forwards.  Its users MUST POP to pick up there mail now.

Could you provide a citation for the following claim:
 “Over 88% of the time, when SPF fails, DKIM/ADSP/DMARC, if 
available would also fail.  So the payoff is high to short-circuit 
and lowered when you needless transfer a potential large and harmful 
payload.”


I’m skeptical and I’d imagine some others are too so a cite would go 
a long way. Thanks.


I have 20 years of collected daily stats here:

https://winserver.com/public/spamstats.wct

By the way, the #1 rejection method is the CBV - Call Back Verifier.  
Comes from the Modem Caller ID days where you check the client's ID.  
Check out the stats!!


SPF started as an IP::DOMAIN association.  In started during MARID. 
The early 2000 emergency IETF working group to help address the spoof 
problem to the tune of $13B dollars in the industry.  Yes, I remember 
the news number. :-)


I've implemented many of the LMAP IP::DOMAIN proposed; DMP, RMX and 
SPF was somewhat of a blend. I was there with this.  Did you know 
Microsoft still has their early version of SenderID in XML format? It 
came with a _ep.  subdomain, so please do a DNS TXT up for _ep.hotmail.com


"testing='true'>list1._ep.hotmail.com
t>list2._ep.hotmail.comlist3._ep.hotmail.com"


Since day one. I was there.

DKIM came with a ADID::SDID association (author, signer) and that was 
defined via policy, starting with SSP, reduced to ADSP and replaced as 
DMARC with the same ADSP problems. But Levine did not believe anyone 
would honor the hard policies.  He was wrong, right?


The problem since day one was that we can't resolve the 3rd party 
association, the ADID::SDID authorization missing piece.


Anyway, there are far too much waste in electronic mail, ADSP/DMARC 
and this quest to resolve its issues, creating more junk, ARC, is not 
getting anywhere.


Hence, until I have more confidence in whats being developed, I will 
always go the route of optimization and in this case, SPF hard 
failures are rejected before the DATA payload.  Any forwarded issue is 
resolved by the originator fixing issues, the MDA whitelisting, or 
prepare the user to POP3 pick up the mail. Everyone happy now.


--
Hector Santos,
https://santronics.com
https://winserver.com



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Signaling MLMs

[Hector Santos]

On 4/15/2023 6:53 AM, Alessandro Vesely wrote:
I only know a handful of mailing lists, and they all do From: 
rewriting.  Some took years to adapt, but eventually adapted.  Are 
there any who don't?


Since 1996, wcListServer.

I agree lists may also refuse participation and require posters to 
get gmail addresses.


In the case of IETF lists, copyright issues are addressed by the 
Note Well.  I see no violation in From: rewriting.


Since the dawn of messaging, there was much power in From authorship - 
its a taboo to destroy it.  What you write is copyrighted.  It's 
yours.  Yes. The copyright is not lost with the IETF rewrite.


Until then, there is some disruption.  We know it.  We can document 
it; we're not ignoring it.  We thought hard about it and concluded 
that it necessarily arises.  To timidly roll back doesn't seem to be 
a feasible option.  Making laws that cannot be followed, implying 
that every body is implicitly guilty, is an oldish governmental 
practice which sounds just silly when enacted by someone who does 
not even have a protocol police.


Agree.  The MLS/MLM will need to adjust.  Restricting 
subscription/submissions (honoring the protocol) is the easiest first 
step. Imto, this is the correct technical way but it comes with 
disruption.  This disruption MAY be acceptable to the domain but not 
the user.


--
Hector Santos,
https://santronics.com
https://winserver.com



--
Hector Santos,
https://santronics.com
https://winserver.com



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Give up on SPF alone

[Hector Santos]

On 4/15/2023 11:27 AM, Douglas Foster wrote:
Sorry Hector, but you are wrong on the theory and off topic.   DMARC 
and SPF authenticate different things.  DMARC is designed to 
override SPF Fail to handle the case of forwarding without SRS, 
which would be optimal if all messages were signed.


SPF is ignorant of DMARC both literally and technically.  DMARC 
depends on SPF and it may never get a chance to be tested.  That's the 
reality.  Sorry.


Bandwidth optimization was an issue when we were on dial-up, but now 
we size capacity to need, and use other defenses for DDoS attacks 
that saturate bandwidth.


Who is we?  Anyhow. Not applicable.

Discarding DMARC is not feasible, because you cannot revoke an RFC 
and you cannot make people stop knowing what they already know


Way over my head.

--
Hector Santos,
https://santronics.com
https://winserver.com



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] list history, Signaling MLMs

[Hector Santos]

On 4/15/2023 4:39 PM, Scott Kitterman wrote:

On April 15, 2023 8:17:41 PM UTC, John R Levine  wrote:
I would like a pony, too. But ARC is as good as we have now and 
after a decade of beating our heads against the wall, I don't think 
we're going to find anything better. I've suggested a bunch of 
things that would make lists' life better, and nobody is interested: 

Agreed.

If someone has a great idea for a third way in email authentication, they 
should develop the idea, get some deployment experience, and then document the 
protocol.  After that would come the question of adding it to DMARC.  This is 
not the working group to do that work.



ARC is overhead junk to reach a more optimized solution with a TPA 
(Third Party Authorization) protocol. Anyone. Pick one.


Maybe we should add an optional new SPF directive

-DMARC:5322.From.domain

To help resolve this problem DMARC discovery issues at SMTP?

ARC is junk.  Why is it IETF perpetuated is beyond me.  Soon we will 
I-D proposals to clean up this massive overhead.


--
HLS

--
Hector Santos,
https://santronics.com
https://winserver.com



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Signaling MLMs

[Hector Santos]

> On Apr 14, 2023, at 7:31 PM, Dotzero  wrote:
> 
> On Fri, Apr 14, 2023 at 5:55 PM Hector Santos  <mailto:40isdg@dmarc.ietf.org>> wrote:
>> Yes, it is simple DeMorgan’s Theorem where you use short-circuiting logic.
>> 
>> DMARC says that any FAIL calculated via SPF or DKIM is an overall DMARC 
>> failure.  In standard boolean logic is it an OR condition:
>> 
>> IF SPF FAILS or DKIM FAILS Then Reject.
> 
> You have it absolutely backwards.
> 
> DMARC says if either (aligned) SPF validates or (aligned) DKIM validates, it 
> passes.

Hi Mike, 

Appreciate your comment. 

This OR gate logic will short-circuit DKIM with SPF validating.  Optimizing 
means not processing the payload and just issue a 250 which is ‘absolutely' not 
what we want. In fact, DMARC logic is an AND gate of two protocols; one 
standard, one informational with some controversial constraints (alignment).  I 
think you maybe meant:

SPF predates ADSP/DMARC. It is a 5321 level technology.  It is not a payload 
5322 technology.   Interestingly, you might be thinking in terms of SenderID 
which was a 5322 technology which offers SPF with the PRA (5322.From) as a new 
identity to evaluate.  

I know it’s hard to believe for many but there is still a good percentage of 
domains that do not do ADSP or DMARC and maybe not even DKIM.  Just consider 
platforms using Integrated Mail Bots to automate things and they who don’t need 
the overhead. SPF is good enough.

Using Pareto, SPF is the only thing needed for hard reject policy (-ALL).  
DMARC is useless at this point unless you want it to override SPF hardfail 
rejects and record and send reports,  That would be a local policy.  An 
implementation detail.

Over 88% of the time, when SPF fails, DKIM/ADSP/DMARC, if available would also 
fail.  So the payoff is high to short-circuit and lowered when you needless 
transfer a potential large and harmful payload.

But for SPF soft failures (~ALL), that is when the interest of coupling SPF 
soft fail results  with ADSP results got traction.  

SPF verifiers will pass SPF weaker policy results in meta-header data and that 
meant the payload protocol can help here.  Microsoft explored this method and 
had a secret source to determine how soft failures can be coupled with ADSP 
results. 

DMARC never considered partial results. DMARC see SPF as a pass not soft-fail.  
So if DKIM passes and all four (4) domain identities are aligned, the 
transaction passes.  That’s an AND gate and you don’t need to even to process 
SPF or do DKIM validation if the domains do not align. 

—
HLS




___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] Author vs Signer Domains

[Hector Santos]

On 4/14/2023 7:31 PM, Dotzero wrote:
On Fri, Apr 14, 2023 at 5:55 PM Hector Santos 
<mailto:40isdg@dmarc.ietf.org>> wrote:


Yes, it is simple DeMorgan’s Theorem where you use
short-circuiting logic.

DMARC says that any FAIL calculated via SPF or DKIM is an
overall DMARC failure.  In standard boolean logic is it an OR
condition:

IF SPF FAILS or DKIM FAILS Then Reject.


You have it absolutely backwards.

DMARC says if either (aligned) SPF validates or (aligned) DKIM 
validates, it passes.

I don't follow you, so NO

a fail of either is a failure as a whole.

That is how the major EPS of late are applying it - per specs.


--
Hector Santos,
https://santronics.com
https://winserver.com

--
Hector Santos,
https://santronics.com
https://winserver.com



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Signaling MLMs

[Hector Santos]

Yes, it is simple DeMorgan’s Theorem where you use short-circuiting logic.

DMARC says that any FAIL calculated via SPF or DKIM is an overall DMARC 
failure.  In standard boolean logic is it an OR condition:

IF SPF FAILS or DKIM FAILS Then Reject.

I hope you can understand this technical implementation detail.

—
HLS



> On Apr 14, 2023, at 5:44 PM, Douglas Foster 
>  wrote:
> 
> Hector, it sounds like you are saying that SPF is all we need, so scrap 
> DMARC.   If it is something else please clarify.
> 
> Doug
> 
> On Fri, Apr 14, 2023, 4:44 PM Hector Santos 
> mailto:40isdg@dmarc.ietf.org>> wrote:
>> 
>> 
>>> On Apr 14, 2023, at 3:20 PM, Murray S. Kucherawy >> <mailto:superu...@gmail.com>> wrote:
>>> 
>>> On Fri, Apr 14, 2023 at 10:20 AM Alessandro Vesely >> <mailto:ves...@tana.it>> wrote:
>>>> On Fri 14/Apr/2023 15:47:12 +0200 Scott Kitterman wrote:
>>>> > On April 14, 2023 1:29:58 PM UTC, "Murray S. Kucherawy" 
>>>> > mailto:superu...@gmail.com>> wrote:
>>>> >> On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely >>> >> <mailto:ves...@tana.it>> wrote:
>>>> >>
>>>> >>> Heck, MLMs should start rejecting messages sent from domains that 
>>>> >>> publish a 
>>>> >>> blocking policy *when they fail authentication on entry*!!
>>>> >>
>>>> >> That's not enough to avoid the damage we're talking about.
>>>> 
>>>> Agreed.  Yet, it is a sane half-way between crazy rejecting always and 
>>>> completely ignoring ABUSE.
>>> 
>>> Both DKIM (certainly) and SPF (I'm pretty sure) advocate against rejection 
>>> of messages merely because they fail authentication on ingress. 
>> 
>> And respectfully, SPF always had a strong reject, hard fail policy concept 
>> since it's LMAP R upbringing — immediate rejection, 55z rejection code.
>> 
>> Why Not?  It was optimized.  It served a purpose to address spoofs. Partial, 
>> Neutral and Unknown results were possible. That was suppose to be feed to a 
>> heuristics, highly subjective Reputation Engine. After exactly 20 years of 
>> data, SPF rejection rate is 6.3% of the incoming rejection reasons. 
>> https://winserver.com/public/spamstats.wct
>> 
>>>> I agree there are better solutions, but they're not yet developed.  As 
>>>> ugly as 
>>>> it may be, From: munging is the emerged solution.  It is a _fact_.  Now 
>>>> repeat 
>>>> again that the IETF standardized facts, not theories...
>>> 
>>> Let's put the challenge back on you: Where's your evidence that From 
>>> munging is the emerged consensus solution that this working group should 
>>> standardize?  Where is this _fact_?  If we advance that as a Proposed 
>>> Standard, the community will quite reasonably ask why we think this is 
>>> true, and we're going to need to be able to answer them.  If working group 
>>> consensus agrees, then away we go.
>> 
>> As much as I am an original mail engineering purest (anyone here ever work 
>> with Fidonet?) and therefore consider it to be a fundamental taboo to 
>> destroy originating copyrighted authorship of anything, the MLS/MLM needs to 
>> evolve to handle the various 1::many broadcasting distributions under a new 
>> security umbrella.
>> 
>> Because the current DMARCbis umbrella ist not providing 100% coverage, for 
>> the MLS./MLM, it needs to do one of two things;  restrict 
>> subscription/submissions or strip the security and rewrite the copyrighting 
>> authorship, perpetuating a potential harm including legal.
>> 
>> The latter is not preferred.  The former would be normal part of a protocol 
>> complete algorithm. You would do the former always.  It’s the easiest.  No 
>> need to modify the MLS.  Just the MLM low code provisional scripts.
>> 
>> —
>> HLS
>> ___
>> dmarc mailing list
>> dmarc@ietf.org <mailto:dmarc@ietf.org>
>> https://www.ietf.org/mailman/listinfo/dmarc

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Signaling MLMs

[Hector Santos]

> On Apr 14, 2023, at 3:20 PM, Murray S. Kucherawy  wrote:
> 
> On Fri, Apr 14, 2023 at 10:20 AM Alessandro Vesely  > wrote:
>> On Fri 14/Apr/2023 15:47:12 +0200 Scott Kitterman wrote:
>> > On April 14, 2023 1:29:58 PM UTC, "Murray S. Kucherawy" 
>> > mailto:superu...@gmail.com>> wrote:
>> >> On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely > >> > wrote:
>> >>
>> >>> Heck, MLMs should start rejecting messages sent from domains that 
>> >>> publish a 
>> >>> blocking policy *when they fail authentication on entry*!!
>> >>
>> >> That's not enough to avoid the damage we're talking about.
>> 
>> Agreed.  Yet, it is a sane half-way between crazy rejecting always and 
>> completely ignoring ABUSE.
> 
> Both DKIM (certainly) and SPF (I'm pretty sure) advocate against rejection of 
> messages merely because they fail authentication on ingress. 

And respectfully, SPF always had a strong reject, hard fail policy concept 
since it's LMAP R upbringing — immediate rejection, 55z rejection code.

Why Not?  It was optimized.  It served a purpose to address spoofs. Partial, 
Neutral and Unknown results were possible. That was suppose to be feed to a 
heuristics, highly subjective Reputation Engine. After exactly 20 years of 
data, SPF rejection rate is 6.3% of the incoming rejection reasons. 
https://winserver.com/public/spamstats.wct

>> I agree there are better solutions, but they're not yet developed.  As ugly 
>> as 
>> it may be, From: munging is the emerged solution.  It is a _fact_.  Now 
>> repeat 
>> again that the IETF standardized facts, not theories...
> 
> Let's put the challenge back on you: Where's your evidence that From munging 
> is the emerged consensus solution that this working group should standardize? 
>  Where is this _fact_?  If we advance that as a Proposed Standard, the 
> community will quite reasonably ask why we think this is true, and we're 
> going to need to be able to answer them.  If working group consensus agrees, 
> then away we go.

As much as I am an original mail engineering purest (anyone here ever work with 
Fidonet?) and therefore consider it to be a fundamental taboo to destroy 
originating copyrighted authorship of anything, the MLS/MLM needs to evolve to 
handle the various 1::many broadcasting distributions under a new security 
umbrella.

Because the current DMARCbis umbrella ist not providing 100% coverage, for the 
MLS./MLM, it needs to do one of two things;  restrict subscription/submissions 
or strip the security and rewrite the copyrighting authorship, perpetuating a 
potential harm including legal.

The latter is not preferred.  The former would be normal part of a protocol 
complete algorithm. You would do the former always.  It’s the easiest.  No need 
to modify the MLS.  Just the MLM low code provisional scripts.

—
HLS___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Signaling MLMs

[Hector Santos]

The solution to move forward is:

- Recommend MUST NOT publish if domain wants to allow users to use domain in 
public list systems,

- Warn MLS/MLS  to avoid From Rewrite and recommend to honor p=reject by 
rejecting subscription, submissions. This is already in practice since 2011.

- Update section 4.4.3 to assist domains with a desire to use p=reject to 
consider supporting extended technologies to help with public usage of p=reject.

- Add a section for marketers of DMARC security systems to assist in correcting 
this problem with less aggressive campaigns to be prepare mail hosting 
customers with p=reject policies before they’re ready to do so. Always start 
with p=none.

- Make DMARCbis Informational status for faster IETF adoption  As a proposed 
standard, it’s going to be a rough poison pill too shallow after ADSP was 
abandoned for the same problems.  The difference now is this MUST NOT publish 
and honor for DMARCbis.  This may be enough to get IETF endorsement for a 
proposed standard.  

—
HLS


> On Apr 14, 2023, at 1:58 PM, Scott Kitterman  wrote:
> 
> On Friday, April 14, 2023 1:20:28 PM EDT Alessandro Vesely wrote:
>> On Fri 14/Apr/2023 15:47:12 +0200 Scott Kitterman wrote:
>>> On April 14, 2023 1:29:58 PM UTC, "Murray S. Kucherawy" 
>  wrote:
 On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely  wrote:
> Heck, MLMs should start rejecting messages sent from domains that
> publish a
> blocking policy *when they fail authentication on entry*!!
 
 That's not enough to avoid the damage we're talking about.
>> 
>> Agreed.  Yet, it is a sane half-way between crazy rejecting always and
>> completely ignoring ABUSE.
>> 
> From: rewriting is the de-facto standard.  In DMARCbis we can only
> substitute "de-facto" with "proposed".  Better methods, implying
> different, possibly experimental, protocols are to be defined in
> separate documents. >>
 
 Are you suggesting we put that forward as our Proposed Standard way of
 dealing with this problem?  It's been my impression that this is not a
 solution that's been well received.
>> 
>> I agree there are better solutions, but they're not yet developed.  As ugly
>> as it may be, From: munging is the emerged solution.  It is a _fact_.  Now
>> repeat again that the IETF standardized facts, not theories...
>> 
> Let me recall that when I proposed something like that, I was told that
> that was phase II and the WG was then already in phase III.  So, let's
> complete DMARCbis /without cannibalizing the spec/ by saying that it
> MUST NOT be used (as it is being used already).
 
 What you describe as "cannibalizing" is actually a matter of presenting
 the
 correct normative advice about interoperability.
>> 
>> It is nonsensical.  It means DMARC is only useful for looking at the
>> reports. If that's really what we think, we'd be better off deprecating p=
>> completely. Otherwise, let's wait until next April 1st and publish it as
>> such.  It's ridiculous.
>> 
 So I don't agree at all with that characterization.
>>> 
>>> Agreed.  If people can't get over saying some domains will have
>>> interoperability problems when that's demonstrably a technically accurate
>>> statement (and I don't see anyone claiming it isn't), I don't see how
>>> progress is possible.
>> 
>> I agree that we have to say that some domains have interoperability problems
>> as a consequence of DMARC.  Let's say that MLMs MUST do From: munging
>> unless (or until) better solutions arise, or unless they don't alter
>> messages.
>> 
>> We're proposing email authentication, not anything less.
> 
> Yes, but we don't get to close our eyes and pretend the rest of the world 
> doesn't exist.
> 
> If we want to change this, we're going to have to update RFC 5321, which I 
> think is out of our scope.  In the section on aliases and lists (3.9), it 
> says:
> 
>>   However, in this case, the message header section (RFC 5322 [4]) MUST
>>   be left unchanged; in particular, the "From" field of the header
>>   section is unaffected.
> 
> I think it would be wrong to mandate From rewriting for a lot of reasons, but 
> I don't think we get to just ignore an Internet Standard.  I think we 
> particularly don't get to ignore an Internet Standard and make it through an 
> IETF wide last call.
> 
> I still don't hear anyone claiming there's no interoperability problems when 
> some domains publish p=reject.  Can we please just agree to document reality 
> and move forward?
> 
> Scott K
> 
> 
> ___
> dmarc mailing list
> dmarc@ietf.org 
> https://www.ietf.org/mailman/listinfo/dmarc

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Signaling forwarders, not just MLMs

[Hector Santos]

On 4/14/2023 7:43 AM, Alessandro Vesely wrote:

On Thu 13/Apr/2023 18:01:40 +0200 John R Levine wrote:

In ADSP I made the equivalent policy "discardable" to reinforce 
this point.  My co-authors weren't happy about it, but they 
couldn't disagree.


ADSP was different from DMARC.



ADSP dkim=discardable basically said "Expect mail to be always signed 
by the author and only the author if not, discard" which is basically 
DMARC p=reject.   Discard is used because was possible to process 
after acceptance. So to avoid the "required" bounce, this authorize 
mail men discard it. Don't bounce it, don't let the user see it.   If 
DMARC was processed at data before acceptance, then its a 55z Reject 
concept.  So the same as DMARC p=reject.


ADSP dkim=all said "expect my mail to be signed by someone"

We could not finish this 3rd party idea of authorizing the always signed.

DMARC needs this Always Signed by someone idea too with ATPS to finish 
the authorization missing piece.


--
Hector Santos,
https://santronics.com
https://winserver.com

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Signaling MLMs

[Hector Santos]

> On Apr 13, 2023, at 4:33 PM, John Levine  wrote:
> 
>> (2) An author domain can decide to affix this at its discretion, ...
> 
> The basic problem is that author domains lie about their policy, i.e.,
> p=none but they expect mailing lists to work, and their users are
> stuck.

It’s not a lie. The protocol expected the MLS or MLM using low code scripts to 
adjust. It’s been 17 years!  Hello?

1. Honor the policy, protect security by rejecting restrictive domains, or

2. Break the security layer, redistribute with no security.

You, as the author of DMARCbis, oddly choose #2.  Why not #1?

—
HLS

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Signaling forwarders, not just MLMs

[Hector Santos]

> On Apr 13, 2023, at 3:13 PM, Hector Santos 
>  wrote:
> 
> On 4/13/2023 11:21 AM, Barry Leiba wrote:
>>> Anyone who does forwarding is damaged by DMARC because there are a lot of
>>> people who do DMARC on the cheap with SPF only.
>> This brings up another issue, I think: that there should also be
>> stronger advice that using DKIM is critical to DMARC reliability, and
>> using SPF only, without DKIM, is strongly NOT RECOMMENDED.
>> 
> Keep in mind, there are implementers of SPF that act at SMTP before DATA and 
> reject hard failures with 55z errors.  In other words, no payload is 
> transferred.
> 


Let me expand on this:

First, SPF predated DMARC. 

DMARC as a payload protocol, like any other payload protocol have high overhead 
associated with it;  DKIM, ADSP, ATPS, DMARC processing.  

Nothing to worry about at low scale and nothing to worry about at high scale if 
optimized correctly, and that is by allowing SPF to pre-empt payload processing 
when there is a hard SPF failure.  That’s good. Not Bad. In 18 years of SPF,  I 
maybe had 1 false positive.

But even then with introduction of DMARC, I recognized the domain policy may be 
p=none or p=quarantine.

Therefore I propose RFC 4405 SUBMITTER protocol to pass the PRA at MAIL FROM

C: MAIL FROM: SUBMITTER=pra

Where the PRA is the 5322.From address.

The allow SMTP to check the DMARC policy at SMTP. helping it how to handle SPF 
rejections.

Please let’s make this Protocol Complete.   If DMARC requires SPF to be delayed 
until the DATA state, then you are talking about an anti-scaling feature. Use 
SUBMITTER to pass the PRA.

—
HLS

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Signaling forwarders, not just MLMs

[Hector Santos]

I didn’t we need to mention the type of people, organization, etc.

“This is particularly important because SPF will always fail in situations 
where mail is forwarded.”  

The issue applies to all.

> On Apr 13, 2023, at 12:04 PM, Todd Herr 
>  wrote:
> 
> On Thu, Apr 13, 2023 at 11:21 AM Barry Leiba  > wrote:
>> > Anyone who does forwarding is damaged by DMARC because there are a lot of
>> > people who do DMARC on the cheap with SPF only.
>> 
>> This brings up another issue, I think: that there should also be
>> stronger advice that using DKIM is critical to DMARC reliability, and
>> using SPF only, without DKIM, is strongly NOT RECOMMENDED.
>> 
> I don't disagree.
> 
> How do we make the following text stronger?
> 5.5.2.  
> Configure
>  Sending System for DKIM Signing Using an Aligned Domain 
> 
> While it is possible to secure a DMARC pass verdict based on only one of SPF 
> or DKIM, it is commonly accepted best practice to ensure that both 
> authentication mechanisms are in place to guard against failure of just one 
> of them.
> 
> This is particularly important because SPF will always fail in situations 
> where mail is sent to a forwarding address offered by a professional society, 
> school or other institution, where the address simply relays the message to 
> the recipient's current "real" address. Many recipients use such addresses 
> and with SPF alone and not DKIM, messages sent to such users will always 
> produce DMARC fail. 
> 
> The Domain Owner SHOULD choose a DKIM-Signing domain (i.e., the d= domain in 
> the DKIM-Signature header) that aligns with the Author Domain.
> 
> 
> 
> -- 
> Todd Herr  | Technical Director, Standards and Ecosystem
> e: todd.h...@valimail.com  
> m: 703.220.4153
> 
> This email and all data transmitted with it contains confidential and/or 
> proprietary information intended solely for the use of individual(s) 
> authorized to receive it. If you are not an intended and authorized recipient 
> you are hereby notified of any use, disclosure, copying or distribution of 
> the information included in this transmission is prohibited and may be 
> unlawful. Please immediately notify the sender by replying to this email and 
> then delete it from your system.
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Signaling forwarders, not just MLMs

[Hector Santos]

On 4/13/2023 11:21 AM, Barry Leiba wrote:

Anyone who does forwarding is damaged by DMARC because there are a lot of
people who do DMARC on the cheap with SPF only.

This brings up another issue, I think: that there should also be
stronger advice that using DKIM is critical to DMARC reliability, and
using SPF only, without DKIM, is strongly NOT RECOMMENDED.

Keep in mind, there are implementers of SPF that act at SMTP before 
DATA and reject hard failures with 55z errors.  In other words, no 
payload is transferred.




--
Hector Santos,
https://santronics.com
https://winserver.com



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Signaling MLMs

[Hector Santos]

On 4/13/2023 11:14 AM, Barry Leiba wrote:
There's no need for a signal here: the MLM can simply check the 
sending domain's DMARC policy when a new post comes in, and 
preemptively reject it if the policy is "reject". The IETF 
considered doing that and ruled it out because it would mean that 
users with yahoo.com addresses (and others) could then not 
participate in IETF mailing lists without changing addresses. 

Code change where?  In the MLS or some post scripting code?

I think that was the wrong decision, but we decided on the ugly 
"from" alteration instead. 


Code change anyway.   No way around this code change - a direct MLS 
change or MLM low code script add-on/change.   My MLS checks it's 
entry points for restrictive DMARC domain; subscription and submissions.


I still think that outright refusal of posts from p=reject domains 
is a good approach and I wish it were used more, but most MLMs that 
are willing to put in a change to address this seems to prefer not 
to punish the sending domains users for the excesses of the domain 
management.


+1.

It can only be considered more with key cogs support and promotion to 
their industry/trade support peers. Iow, Editors SHOULD 
support/champion their RFC work like ATPS and DMARC.  Many ideas and 
concepts from DSAP merged from WG work. DMARC is a collection of all 
the past work with reporting. But it needs DSAP policy ideas and ATPS 
concept to help bring some steady state to transporters. DMARCbis p= 
should be describing the failure handling not restricting the 
evaluation of a failure.  This will provide the tools to define the 
nine possible 1st vs 3rd party signers.  MLS needs to support this.  
The MLM operators need to support it too. Of course, the MLS/MLM can 
use Local Policy to override at its own risk especially when DMARCBis 
offers nothing to resolve this problem.  But it can easily fit in too 
and see where it goes.



--
Hector Santos,
https://santronics.com
https://winserver.com



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Signaling MLMs

[Hector Santos]

 dmarc  as string
dim adsp  as string
dim policy as string
if GetDMARC(eaFrom.Domain, "", dmarc) then
   policy = lcase(GetHeaderTag(dmarc,"p="))
   dim fv as integer
   if policy = "reject" or policy = "quarantine" then
  //
  // This domain can not post to the list, if the MLS is not
  // prepared to do a restrictive DMARC domain check.
  //
  sfAppendMetaLog(msgfn,"Rejected by 
smtpfilter-listchecker: "+From)
  sfAppendMetaLog(msgfn,"Restricted DMARC policy for 
domain: "+eaFrom.Domain):

  sflog(lchReject,"Rejecting mail for: "+rcpt+" from: "+from)
  sflog(lchReject,"Restricted DMARC policy for domain: 
"+eaFrom.Domain)

  sflog(lchReject,"File: "+msgfn+".policy-dmarc")
  CopyFile(msgfn,msgfn+".dmarc")
  sfSetGlobalResult(SF_DISCARD,SF_ENDRULES,554)
  // create response
  fv = open msgfn+".response" for output
  if fv > 0 then
print #fv,"554 Restricted DMARC policy for domain: 
"+eaFrom.Domain+". Can not post to list: "+lname

close #fv
  end if
  END
   end if
end if
if GetADSP(eaFrom.Domain, adsp) then
   policy = lcase(GetHeaderTag(adsp,"dkim="))
   if policy = "discardable" then
  //
  // This domain can not post to the list, if the MLS is not
  // prepared to do a restrictive ADSP domain check.
  //
  sfAppendMetaLog(msgfn,"Rejected by 
smtpfilter-listchecker: "+From)
  sfAppendMetaLog(msgfn,"Restricted ADSP policy for 
domain: "+eaFrom.Domain):

  sflog(lchReject,"Rejecting mail for: "+rcpt+" from: "+from)
  sflog(lchReject,"Restricted ADSP policy for domain: 
"+eaFrom.Domain)

  sflog(lchReject,"File: "+msgfn+".policy-adsp")
  CopyFile(msgfn,msgfn+".dmarc")
  sfSetGlobalResult(SF_DISCARD,SF_ENDRULES,554)
  // create response
  fv = open msgfn+".response" for output
  if fv > 0 then
print #fv,"554 Restricted ADSP policy for domain: 
"+eaFrom.Domain+". Can not post to list: "+lname

close #fv
  end if
  END
   end if
end if
 end if

 //-
 s = s + " accepted for WCLS address: " + rcpt
 sflog(lchInfo,s)
 sfAppendMetaLog(msgfn,"Accepted by smtpfilter-listchecker: "+From)
 sfSetGlobalResult(SF_ACCEPT,SF_ENDRULES)
  end if

  END


--
Hector Santos,
https://santronics.com
https://winserver.com



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Signaling MLMs

[Hector Santos]

> On Apr 12, 2023, at 2:15 PM, Murray S. Kucherawy  wrote:
> 
> I've been thinking about the point a few people have made now that DMARC has 
> two actors that cause the problem: Those who "blindly" apply "p=reject", and 
> those who advertise "p=reject".  You do, indeed, need two to tango; 
> enforcement doesn't happen without an advertising sender and a participating 
> receiver.  Maybe any "MUST NOT" advice we provide needs to cover both ends.  
> We need to be careful about admonishing participating receivers though.  What 
> would we say to them about how to be selective in application?

Murray, you have RFC 5016 Section 10.3, Item10 as a Functional Specification 
reinforcement basis for a MUST NOT honor DMARC p=reject that causes 3rd party 
problems.   Even though 5016 applied to SSP, it applies equally to DMARCbis too.

—
HLS


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] Introducing DSAP/ATPS for Improved Email Authentication

[Hector Santos]

Dear Alex and all,

I appreciate your insights on the challenges of balancing security and 
interoperability, particularly in the context of DMARC and its implications on 
email delivery. I agree with your suggestion of adding a more detailed section 
on the implications of DMARC policies in DMARCbis. We could provide an in-depth 
explanation of the various policy types, their use cases, and the potential 
implications of each, which would help stakeholders make more informed 
decisions when implementing their email authentication strategies.

In light of the ongoing discussion, I would also like to introduce the concept 
of DSAP (Domain-based Sender Authorization Protocol) with ATPS (Authorized 
Third-Party Signers) as a potential solution to address these concerns and 
improve email authentication.

DSAP with ATPS aims to offer a more comprehensive and flexible approach to 
email authentication by accounting for all possible combinations of 1st and 3rd 
party signers. This not only addresses the limitations of DMARC and its 
p=reject policy but also enables domain owners to define their own email 
signature expectations and authorized third-party signers.

By adopting DSAP with ATPS, we can reduce false positives and improve the 
overall accuracy and effectiveness of email authentication, leading to a more 
secure email ecosystem without causing disruptions to mail delivery.

I invite all stakeholders, including MLM developers and operators, to join the 
discussion and collaborate on the development of DSAP/ATPS as a more robust and 
adaptable email authentication protocol that serves the interests of all 
parties involved.

I look forward to your thoughts and feedback on this proposal.

Best regards,

Hector Santos, CEO/CTO
Santronics.com


> On Apr 12, 2023, at 8:20 AM, Brotman, Alex 
>  wrote:
> 
> There is a non-zero set of cases where the IETF prefers security over 
> interoperability.   A document like RFC8997/8996 where we've deprecated TLSv1 
> in because it was no longer secure. I assure you there are still 
> systems/users who have devices incapable of TLSv1.2.  DNSSEC (and things that 
> depend on it) can break in "mysterious" ways (specific to DNSSEC) that impact 
> interoperability, but sites do so in the in the name of security.
> 
> I think we all understand the inconvenience that DMARC can cause to a subset 
> of domains, or more accurately its users.  8996 has a section about 
> operational considerations, and discusses the impact of systems/users that do 
> not support TLSv1.2 and how it will break interoperability.  Can we not do 
> similar in DMARCbis with a more lengthy section about the implications of 
> "reject"?  Perhaps even expand it to cover the use cases of each policy type, 
> and the implications of each?  
> 
> --
> Alex Brotman
> Sr. Engineer, Anti-Abuse & Messaging Policy
> Comcast
> 
>> -Original Message-
>> From: dmarc  On Behalf Of Scott Kitterman
>> Sent: Tuesday, April 11, 2023 11:50 PM
>> To: dmarc@ietf.org
>> Subject: Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with 
>> p=reject?
>> 
>> 
>> 
>> On April 12, 2023 3:24:39 AM UTC, Neil Anuskiewicz > tech@dmarc.ietf.org> wrote:
>>> 
>>> 
>>>> On Apr 8, 2023, at 6:56 AM, John Levine  wrote:
>>>> 
>>>> We're never going to persuade DMARC absolutists that the damage is
>>>> real, nor the rest of us that we can wave our hands and ignore the damage.
>>> 
>>> John, the damage is real. There’s no doubt about that. Trade offs, painful 
>>> trade
>> offs, have to be made and I’m sure this isn’t the first WG to face trade 
>> offs and
>> have to make hard decisions or not.
>>> 
>>> If DMARC can protect domains from spoofing which I believe ends up costing
>> over $14 billion per year. Forget about the $14 billion and think how this 
>> crime
>> spree affects people’s view of one of the last remnants of the free 
>> internet. It’s
>> a fiasco on so many levels. If you have the tools to make a real difference 
>> and I
>> can say from first hand experience DMARC has helped people’s financial and
>> mental health.
>>> 
>>> The standard and the document should reflect that it’s already making a
>> massive difference and could do even more. I don’t think it’s unreasonable to
>> expect ml managers to adapt. If cyber crime was street crime people would be
>> panicking in the streets.
>>> 
>> You can leave the marketing text aside.  We know.
>> 
>> The purpose of IETF specifications is to promote interoperability.  For good
>> reason, they tend to mostly document reality, not drive it.
>> 
>> The imp

Re: [dmarc-ietf] DMARC is designed to break mail, Example of Indirect Mail Flow Breakage with p=reject?

[Hector Santos]

> On Apr 12, 2023, at 9:41 AM, John R Levine  wrote:
> 
> When we say that mail systems that don't fit the DMARC threat profile 
> shouldn't publish DMARC policies, we have good reasons to say so, and that's 
> what our standards need to say if we're serious about interoperating.
> 

With DMARCbis, If domains MUST NOT publish p=reject is mandated for certain 
classes of domain mail, then it should also apply to MUST NOT honor p=reject as 
a recommendation for verifiers.  If so,

- Should MDA receivers ignore sender p=reject for local users?
- Should MLM strip the submission security (From rewrite)?

—
HLS




___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: how to change default nameserver?

[Richard Hector]

On 11/04/23 15:17, gene heskett wrote:

On 4/10/23 18:04, zithro wrote:


So, I got curious about his claim : "that change to resolv.conf adding 
the search line [search hosts, nameserver] has been required since red 
hat 5.0 in 1998".

(The bracket addition is mine)

I'm not using RHEl-based systems a lot so I may be wrong, and there's 
not a lot of material left from the 1998 web, but the resolv.conf file 
*looks* identical in RHEL-based systems, at least nowadays.
I quickly browsed a few RH help pages about resolv.conf, but couldn't 
find his claim.


I then searched for "search hosts, nameserver" on search engines 
(-with- the quotes, to only get full-match results).
Either I get no results or ... wait for it ... it *ONLY* gives me 
results where Gene posted !


So Gene, can you tell us where you read this ?


In a man page from a good 20 years ago. I still have a copy of that 
original redhat 5.0 on a shelf above me, but not a floppy drive to read 
those disks with.


Well, it's not in resolver(5) (which is for resolv.conf) on Red Hat 5.0.5.

Richard

Re: how to change default nameserver?

[Richard Hector]

On 11/04/23 15:17, gene heskett wrote:
In a man page from a good 20 years ago. I still have a copy of that 
original redhat 5.0 on a shelf above me, but not a floppy drive to read 
those disks with.


Downloading an iso ... :-)

Richard

Re: [dmarc-ietf] not really such a thing as AOL-compatible mailing lists

[Hector Santos]

> On Apr 10, 2023, at 12:55 PM, Murray S. Kucherawy  wrote:
> 
> I think the one thing we haven't discussed is: Could the 80-20 rule apply 
> here?  That is, if we start off with something like what 
> draft-kucherawy-dkim-transform proposed (or even a trivial subset of it), 
> might it make enough of a dent to get us through this stalemate, and then we 
> can figure out what to do with the rest of it?
> 

Speaking of Pareto:

- DMARC covers only 22% of the full ranges of signature scenarios with no 
provision to define nor authorize 3rd party (re)signers. 

- Occam’s Razor,  the solution is often more simpler than its often appears, 
80% of the time — ATPS.  Your Idea. Champion it and it will get supported by 
your peers.   Want to try inline method?  Fine. But explain why more complexity 
is better to reach same conclusion ATPS provides.  Best option; support both to 
cover the different admin methods.

- 80% of those who have been involved since MARID with LMAP, SPF, DKIM/, SSP, 
ADSP and "Super ADSP” DMARC are disillusioned why the IETF has allowed the same 
key cogs over 17 years to continue to perpetuate a broken protocol and problem 
when they never believed in SPF, ADSP and DMARC — their focus was Reputation 
modeling with no standard in place for an assessment lookup (opening a door for 
business interest).

This is not about heuristics.  We should first close the deterministic holes by 
providing domains a method to expose their 1st vs 3rd party expectations.  
DMARC is not a protocol complete when it comes to domain policies.

Too many closes. 80%???

—
HLS












___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] not really such a thing as AOL-compatible mailing lists

[Hector Santos]

> On Apr 10, 2023, at 12:55 PM, Murray S. Kucherawy  wrote:
>> 
> I think the one thing we haven't discussed is: Could the 80-20 rule apply 
> here?  That is, if we start off with something like what 
> draft-kucherawy-dkim-transform proposed (or even a trivial subset of it), 
> might it make enough of a dent to get us through this stalemate, and then we 
> can figure out what to do with the rest of it?
> 
> -MSK, participating

Please consider the overall goal and the various methods to get to the same 
conclusion:

- Inline ADID::SDID authorization (2nd signatures, new tags, complexity)
- DNS lookup ADID::SDID authorization (plug and plug)

The later is the more optimized method for plug and play implementation.

I would rather not have to change SPF, DKIM to support a protocol incomplete 
ADSP/DMARC proposal. We can begin to fix this with the proper add-ons or 
replacement of DMARC (which is not a good idea. We want to piggyback off the 
lookups).

DSAP provides domains a method to expose what is expected, unexpected and 
optional.  

Cover the boundary conditions to close loop holes that exist.

Too many holes.

—
HLS

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Hector Santos]

> On Apr 9, 2023, at 2:33 PM, Barry Leiba  wrote:
> 
> > As Todd previously stated, my preference is for language that
> > acknowledges the primacy of the domain owner over interoperability
> 
> The problem is that IETF standards are about interoperability, not about 
> anyone’s primacy.
> 
> There is an alternative, though: we can acknowledge that because of how those 
> deploying DMARC view their needs over interoperability, DMARC is not 
> appropriate as an IETF standard, and we abandon the effort to make it 
> Proposed Standard.

+1,  please make this an Informational status.  

> 
> I see that as the only way forward if we cannot address the damage that 
> improperly deployed DMARC policies do to mailing lists.

+1

In fact, lets take a step back and split DMARCbis to:

DMARC-Reporting 
DMARC-Policy

Let’s get reporting out the door and spend time to revisit the DKIM Policy 
Model via DMARC which combines two protocols.

With the ESP now honoring DMARC as is, the middle ware is forced to take 
drastic changes in order for the “mail men” to move mail.

Thanks Barry.

—
HLS___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Hector Santos]

> On Apr 9, 2023, at 2:15 PM, Murray S. Kucherawy  wrote:
> 
> On Sun, Apr 9, 2023 at 6:33 AM Jesse Thompson  > wrote:
>> As Todd previously stated, my preference is for language that acknowledges 
>> the primacy of the domain owner over interoperability. CISOs have been sold 
>> (arguably, by the DMARC deployment companies' marketing) on the idea that 
>> there are security benefits. Maybe oversold, but there are benefits and the 
>> motivation will not change. Let's not also overlook the primary benefit of 
>> _the process of deploying DMARC_ gives to an organization: increased 
>> management and governance (enabled by the observability from the reports). 
>> In any case, the domain owner is motivated to deploy DMARC and gain the 
>> perceived benefits. If we are going to tell these motivated domain owners to 
>> MUST do something, at least make it something they might consider doing.
> 
> I don't think the way DMARC has been marketed is germane to discussions about 
> interoperability, which is what "MUST NOT" type language seeks to resolve.

So is that the difference with ADSP and DMARCbis?  Lacking ADSP language to 
forcibly say ESP-like domains MUST NOT use `DISCARDABLE` policy? DMARCbis will 
survive this ADSP dilemma by saying MUST NOT p=reject?  

Basically what we are authorizing now is permission for MDA, MLS and MTA, 
middle-ware, to do whatever they need to do that make sure mail is 
transportable and deliverable, including removing, masking the security wrapper.

Since we will never get this right with this WG and rewrite is the only 
solution, I now agree to use a MUST NOT. 

So I think it should be outlined what will expected to happen if a domain uses 
p=reject when they should not:

- risk interop issues,
- messages alterations to remove the DMARC security blanket.

—
HLS___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] DSAP "DKIM Sender Authorization Protocol" for DMARC

[Hector Santos]

Summary:

I would like to reintroduce the DSAP (DKIM Sender Authorization Protocol) as a 
DMARC extended tag extension -dsap. The original DSAP draft covered nine 1st vs 
3rd party signature policies from a verifier viewpoint, which addressed 
boundary conditions for DKIM signatures. The reintroduction aims to address 
concerns regarding 3rd party resigners.

Key changes proposed for DMARC integration:

o Introduce -dsap tag for DSAP support, covering a complete range of possible 
policies.

o Use -asl tag for inline list of authorized signer support.

o Implement -atps tag for ATPS support.

o Formalize the From rewrite logic with a -rewrite tag.

o Introduce -target tag to assist mail forwarders with authorized redirection 
of exclusive policies.

The proposal seeks to offer better integration with today's wide range of mail 
applications, building on the existing DMARC protocol and improving 3rd party 
authorization and reporting.


Background:

In 2006, I submitted an I-D DSAP “DKIM Sender Authorization Protocol” that 
covers the boundary conditions for 1st vs 3rd party signature expectations.  
There are nine 1st vs 3rd party signature policies in DSAP from a verifier 
viewpoint:

Original 1st Party Signature (OPS)
Not expected (-)
Expected (+)
Optional (~)

Third Party Signature (3PS)
Not expected (-)
Expected (+)
Optional (~)

Using these expectations, DSAP can cover most if not all possible Boundary 
Conditions for DKIM signatures.

I would like to re-propose DSAP but this time as a DMARC extended tag extension 
`-dsap` as I believe it can address our concerns regarding 3rd party resigners.

Here is the 2006 DSAP proposal I plan on updating to support DMARC and ATPS:

https://datatracker.ietf.org/doc/html/draft-santos-dkim-dsap-00

History:

The DKIM Policy Model began with SSP “Sender Signature Practices/Policy.” This 
image illustrates the overall process:




Many today do not realize the original DKIM included Signature Policy protocol 
called SSP.   It was spit into DKIM-BASE and DKIM-SSP to help speed up the 
process. DKIM was well defined but SSP was not.  SSP covered various signing 
scenarios, however, there were 3 policies missing which DSAP covered:



The DMARC protocol offers an exclusive only policy with p=reject|quarantine. 
This would be a -dsa=OP+,3P- policy With DMARC p=none, no other policy possible 
in terms of expectation other than an unhandled failed exclusive policy.  So 
DMARC is very limited making it a very to integrate with today’s wide range of 
mail applications.

DMARC also introduced two more takes that I would like use replaced with DMARC 
and ATPS.

For Reporting, DSAP provides tags for failure reports. This is now well-defined 
with DMARC. [DSAP only considered failure reports].

For 3rd party authorization, DSAP provided the -asl tag. The asl tag was an 
inline small domain list tag.  But it can also signify a check using ATPS for 
higher scale applications.  

Everything would be the same with DMARC and DMARCbis.   The change would be:

-dsap tag for DSAP support for the complete range of possible policies.

-asl for inline list of authorize signer support

-atps for ATPS support

I would also like to formalize the From rewrite logic with a tag:

-rewrite 

Which tells a resigner it may rewrite the From under certain conditions.  

-target is a new tag to help mail forwarders.

DMARC has considerations for SPF results with a strong alignment requirement. 
One scenario where a -dsap=op+,3p- is with SPF hard failure during mail 
forwarding.   The -target will allow a forwarder to resign as a 3rd party 
without -asl or -atps requirements. 

—
Hector Santos, CEO/CTO
Santronics Software, Inc,___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: questions about cron.daily

[Richard Hector]

On 7/04/23 10:54, Greg Wooledge wrote:

On Thu, Apr 06, 2023 at 05:45:08PM -0500, David Wright wrote:

Users (including root) write their crontabs anywhere they like,
typically in a directory like ~/.cron/.


Is that... normal?  I can't say I've ever seen anyone keep a private
copy of their crontab in their home directory like that.

Most people just use "crontab -e" to edit the system's copy of their
personal crontab...


Perhaps if they want to keep it in version control?

Richard

[Ubuntu-x-swat] [Bug 2004237] Re: Intel Raptor Lake-P support for intel-media-driver in jammy

[Hector CAO]

I did the test on a Raptorlake laptop

ubuntu@ubuntu-Latitude-7440:~$ inxi -G -display
Graphics:
  Device-1: Intel vendor: Dell driver: i915 v: kernel ports: active: eDP-1
empty: DP-1,DP-2,HDMI-A-1 bus-ID: :00:02.0 chip-ID: 8086:a7a0
class-ID: 0300
  Display: server: X.org v: 1.21.1.3 with: Xwayland v: 22.1.1
compositor: gnome-shell v: 42.5 driver: X: loaded: modesetting
unloaded: fbdev,vesa gpu: i915 tty: 207x115
  Monitor-1: eDP-1 model: AU Optronics built: 2022 res: 2560x1600 dpi: 216
gamma: 1.2 size: 301x188mm (11.9x7.4") diag: 355mm (14") ratio: 16:10
modes: 2560x1600
  Message: GL data unavailable in console. Try -G --display
Network:
  Device-1: Intel driver: iwlwifi v: kernel port: N/A bus-ID: :00:14.3
chip-ID: 8086:51f1 class-ID: 0280
  IF: wlp0s20f3 state: up mac: 14:75:5b:5c:6d:4a
  IP v4: 10.102.137.20/22 type: dynamic noprefixroute scope: global
broadcast: 10.102.139.255
  IP v6: fe80::9670:b220:3998:9dcf/64 type: noprefixroute scope: link
  Device-2: Realtek RTL8153 Gigabit Ethernet Adapter type: USB driver: r8152
bus-ID: 3-3:5 chip-ID: 0bda:8153 class-ID:  serial: 01
  IF: enx00e04c6805c6 state: up speed: 1000 Mbps duplex: full
mac: 00:e0:4c:68:05:c6
  IP v4: 10.102.154.191/22 type: dynamic noprefixroute scope: global
broadcast: 10.102.155.255
  IP v6: fe80::dc0b:18f2:2f69:6823/64 type: noprefixroute scope: link
  WAN IP: 211.75.139.217
Drives:
  Local Storage: total: 1.86 TiB used: 14.04 GiB (0.7%)
  SMART Message: Unable to run smartctl. Root privileges required.
  ID-1: /dev/nvme0n1 maj-min: 259:0 model: 2400A NVMe Micron 2048GB
size: 1.86 TiB block-size: physical: 512 B logical: 512 B speed: 63.2 Gb/s
lanes: 4 type: SSD serial: 22293B04CD0D rev: 24000800 temp: 26.9 C
scheme: GPT
  Message: No optical or floppy data found.
Partition:
  ID-1: / raw-size: 1.86 TiB size: 1.83 TiB (98.37%) used: 14.03 GiB (0.8%)
fs: ext4 dev: /dev/nvme0n1p3 maj-min: 259:3 label: UBUNTU
  ID-2: /boot/efi raw-size: 238.4 MiB size: 238.1 MiB (99.89%)
used: 6.1 MiB (2.5%) fs: vfat dev: /dev/nvme0n1p1 maj-min: 259:1 label: N/A
Sensors:
  System Temperatures: cpu: 26.0 C mobo: N/A
  Fan Speeds (RPM): N/A
ubuntu@ubuntu-Latitude-7440:~$ 

Try vainfo:

ubuntu@ubuntu-Latitude-7440:~$ vainfo
libva info: VA-API version 1.14.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_14
libva error: /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so init failed
libva info: va_openDriver() returns 1
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_10
libva error: /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so init failed
libva info: va_openDriver() returns -1
vaInitialize failed with error code -1 (unknown libva error),exit

Next step, i install only intel-media-driver from
https://ppa.launchpadcontent.net/tjaalton/ppa/ubuntu:

ubuntu@ubuntu-Latitude-7440:~$ apt policy libigdgmm12
libigdgmm12:
  Installed: 22.1.2+ds1-1
  Candidate: 22.1.2+ds1-1ubuntu0.1~ppa1
  Version table:
 22.1.2+ds1-1ubuntu0.1~ppa1 500
500 https://ppa.launchpadcontent.net/tjaalton/ppa/ubuntu jammy/main 
amd64 Packages
 *** 22.1.2+ds1-1 500
500 http://tw.archive.ubuntu.com/ubuntu jammy/universe amd64 Packages
100 /var/lib/dpkg/status


ubuntu@ubuntu-Latitude-7440:~$ apt policy intel-media-va-driver
intel-media-va-driver:
  Installed: 22.3.1+dfsg1-1ubuntu0.1~ppa1
  Candidate: 22.3.1+dfsg1-1ubuntu1
  Version table:
 22.3.1+dfsg1-1ubuntu1 500
500 http://tw.archive.ubuntu.com/ubuntu jammy-updates/universe amd64 
Packages
 *** 22.3.1+dfsg1-1ubuntu0.1~ppa1 500
500 https://ppa.launchpadcontent.net/tjaalton/ppa/ubuntu jammy/main 
amd64 Packages
100 /var/lib/dpkg/status
 22.3.1+dfsg1-1 500
500 http://tw.archive.ubuntu.com/ubuntu jammy/universe amd64 Packages

Now vainfo works !

ubuntu@ubuntu-Latitude-7440:~$ vainfo
libva info: VA-API version 1.14.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_14
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.14 (libva 2.12.0)
vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 22.3.1 ()
vainfo: Supported profile and entrypoints
  VAProfileNone   : VAEntrypointVideoProc
  VAProfileNone   : VAEntrypointStats
  VAProfileMPEG2Simple: VAEntrypointVLD
  VAProfileMPEG2Main  : VAEntrypointVLD
  VAProfileH264Main   : VAEntrypointVLD
  VAProfileH264Main   : VAEntrypointEncSliceLP
  VAProfileH264High   : VAEntrypointVLD
  VAProfileH264High   : VAEntrypointEncSliceLP
  VAProfileJPEGBaseline   : VAEntrypointVLD
  VAProfileJPEGBaseline   : VAEntrypointEncPicture
  

Re: [systemd-devel] creating device nodes

[Richard Hector]

Great, thanks - that seems to work:
/etc/tmpfiles.d/fuse.conf:

#Type Path   Mode User Group Age Argument
c! /dev/fuse  0666 root root  -   10:229

Mind you, I'm not entirely clear on what the '!' is for; I just put it 
in because the manpage said it was a good idea :-)


Now to replicate that with ansible for my other containers ...

Cheers,
Richard

On 5/04/23 20:22, Mantas Mikulėnas wrote:

.device units do not mknod, they only represent existing state.

/dev/fuse is usually created through tmpfiles.d (which gets its 
configuration via kmod-static-nodes.service).


# kmod static-nodes --format=tmpfiles

On Wed, Apr 5, 2023 at 11:13 AM Richard Hector <mailto:rich...@walnut.gen.nz>> wrote:


Hi all,

I want to create a device (/dev/fuse) in an LXC container. The kernel
bit works; I can mknod manually, but I'd rather use a systemd unit, and
make it a dependency of mounting filesystems from /etc/fstab.

It looks like .device units are supposed to be created automatically if
there's an appropriate udev rule with TAG+="systemd" - these lines
exists in /usr/lib/udev/rules.d/99-systemd.rules:

# Asynchronously mount file systems implemented by these modules as
soon
as they are loaded.
SUBSYSTEM=="module", KERNEL=="fuse", TAG+="systemd",
ENV{SYSTEMD_WANTS}+="sys-fs-fuse-connections.mount"

The comment seems to suggest it will cause the filesystems to be
mounted
when the device is created, which is kind of the reverse of what I'm
after. Do I need a different line?

Or do I need to create a .device unit file manually? I can't see much
info on doing that.

Cheers,
Richard



--
Mantas Mikulėnas

[systemd-devel] creating device nodes

[Richard Hector]

Hi all,

I want to create a device (/dev/fuse) in an LXC container. The kernel 
bit works; I can mknod manually, but I'd rather use a systemd unit, and 
make it a dependency of mounting filesystems from /etc/fstab.


It looks like .device units are supposed to be created automatically if 
there's an appropriate udev rule with TAG+="systemd" - these lines 
exists in /usr/lib/udev/rules.d/99-systemd.rules:


# Asynchronously mount file systems implemented by these modules as soon 
as they are loaded.
SUBSYSTEM=="module", KERNEL=="fuse", TAG+="systemd", 
ENV{SYSTEMD_WANTS}+="sys-fs-fuse-connections.mount"


The comment seems to suggest it will cause the filesystems to be mounted 
when the device is created, which is kind of the reverse of what I'm 
after. Do I need a different line?


Or do I need to create a .device unit file manually? I can't see much 
info on doing that.


Cheers,
Richard

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

[Hector Santos]

> On Apr 1, 2023, at 6:29 AM, Scott Kitterman  wrote:
> 
> I think that's not quite it.  
> 
> There is clearly a valid reason.  There are domains that value the security 
> properties of p=reject more highly than the negative effects to 
> interoperability.

For many years we knew this would happen and it took Yahoo.com 
 to wake everyone up on this.  Obviously they didn’t ’t care 
and for good reasons — receivers were beginning to flat-out block all yahoo.com 
as one of the spam pollutions around.  Same with aol.com , 
same with hotmail.com , etc.  Flat out just block them.

So yahoo going hard with SPF and ADSP and then DMARC was a good thing.  I began 
to tell old folks still using yahoo it is now safe to use yahoo.com for high 
value services (banking, etc).

But Yahoo needs to look at the ATPS resigners to support other domains in the 
market.


—
HLS___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

[Hector Santos]

> On Apr 1, 2023, at 11:33 AM, Dotzero  wrote:
> 
> 
> 
> On Sat, Apr 1, 2023 at 3:02 AM Barry Leiba  > wrote:
>> > If we use SHOULD NOT, as you suggest, there's an implication that there 
>> > might be a valid reason for
>> > non-transactional mail to use "p=reject".  Are we okay with that?
>> 
>> When do folks get to line up so they can plead the case for their reason?
>> 
>> I, for one, am not.  We often use "SHOULD NOT" incorrectly to mean
>> "MUST NOT, but we know it will be widely violated so we're saying
>> SHOULD NOT".  We need to stop doing that.
> 
> A "standard" which is widely violated is not a standard. To publish a 
> standard one knows is and will be widely violated is a bit of a fool's 
> errand, n'est-ce pas? We need to stop doing that.


Maybe because DMARC is not a standard.  Never was one. It is violated because 
it is protocol incomplete. It was not ready for prime time.  It’s an 
informational status document for reporting.  No reporting. No adoption. I 
would have a hard time supporting DMARCbis as a standard track item with it 
huge email problems and lacking an ATPS concept. (See ADSP)

Any node in the community can completely ignore SPF, DKIM, etc and survive.  If 
DMARC is trying to change that, I do not believe this is good with an ATPS 
concept.

What we need to drive home is the fact this is not a plug and play protocol.  
You can rest assured to have problems when using a strong 1st party only policy 
in public and now increasily, in private too when the ESP is not capable of 
supporting an authorized MTA forwarder.   It lacks the tools,  It needs ATPS.

DMARC firms need to do better job of making sure their customer’s domain are 
clean before using p=reject. The reporting will help determine if moving from 
p=none to p=reject/quarantine will not produce false positives, but even if the 
reporting is capable of exposing a false positive reject friendly resigner,  it 
is not capable of authorizing the friendly resigners. DMARC lacks ATPS support 
for ESPs to leverage.

—
HLS___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

[Hector Santos]

> On Apr 1, 2023, at 11:25 AM, Dotzero  wrote:

> Nobody forces a Sender to publish a DMARC record. Nobody forces a receiver to 
> validate DMARC. Nobody forces mailing lists to accept mail from domains which 
> publish a DMARC record let alone one which publishes  p=reject policy. But it 
> interoperates just fine once you make the effort. 


I would venture that many domain owners (including a few of customers) do not 
know anything about DMARC (despite the advanced marketing hype) and their mail 
host are increasingly providing DMARC services on their behalf.

—
HLS

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

[Hector Santos]

> On Apr 1, 2023, at 7:17 AM, Jim Fenton  wrote:
> 
> Not picking on Murray here, but his message was the most recent that talked 
> about p=reject with respect to non-transactional email:
> 
> On 1 Apr 2023, at 15:53, Murray S. Kucherawy wrote:
> 
>> If we use SHOULD NOT, as you suggest, there's an implication that there
>> might be a valid reason for non-transactional mail to use "p=reject".  Are
>> we okay with that?
> 
> We shouldn’t be assuming that mailing lists are the only cause of breakage 
> for DMARC, and that transactional email is unimpacted by a p=reject policy.
> 
> Some people use email forwarders so that they can have an email address 
> that’s consistent if they change the email provider where their email is 
> actually received. Sometimes they do this for “branding” reasons as well, 
> such as to indicate their association with an organization or alumni 
> association. Some of these email providers break DKIM signatures along the 
> way.

+1

> 
> I have several such forwarding addresses, one of which is @alum.mit.edu, 
> which breaks my DKIM signatures when I send a message to myself. If I used 
> that address to receive transactional email from a domain with p=reject, and 
> if my actual email provider enforced DMARC, I might not receive transactional 
> email.
> 

How many reader/writers (MUAs) do you use?  

I have almost scenario possible. With hosted domains, the owners like to use 
the MUA of an ESPi.e. gmail to consolidate their MUA activity under one 
reader/writer.  This means forwarding mail to the ESP for most immediate 
notification.   This was fine until the ESP began to honor DMARC restrictive 
policies and the forwarded mail is either rejected or put into a spam box.  The 
domain authorized MTA is now penalized with dubious and false positive/negative 
reputation blacklisting creating an increase cost on support and cleanup.  

Among solutions, advising a customer to move their domain hosting to their MUA 
ESP hosting services is an anti-trust, anti-competition non-starter.  Advising 
them to use their ESP mail pickup facility, i.e. pop3, is the solution — 
delayed delivery but it solves the problem for restrictive DMARC domains.

Among the top ESP domain policies:

hotmail.com p=none
yahoo.com   p=reject
gmail.com   p=none sp=quarantine
aol.com p=reject
outlook.com p=none sp=quarantine
msn.com p=none sp=quarantine
bellsouth.net   p=none sp=quarantine
verizon.net p=reject

Verizon.net, aol, bellsouth.net  are hosted by yahoo.com 
 as an MX and HTML MUA. 


—
HLS



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] 5322.From Header Rewrite specification

[Hector Santos]

Is there a specification for rewriting the 5322.From to help resolve DMARC 
p=reject redistribution problems?

What is the logic the IETF.ORG  list using?

Thanks in advance

—
HLS___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

[Hector Santos]

> On Mar 29, 2023, at 5:40 PM, Todd Herr 
>  wrote:
> 
> Colleagues,
> 
> Can someone please point me to a mailing list server or other indirect mail 
> flow that I might somehow engage with so that I can experience the pain of 
> not having a message reach its destination when sent with a policy of 
> p=reject?


Try to subscribe here:

 https://winserver.com/public/html-subscribe.wcx?list=winserver

First, the warning of the subscription restriction is shown. when you try, it 
will reject it.  When submissions come in,  it will be rejected as well.  

We don’t do a rewrite and thus keeping with your security wishes.  You didn’t 
tell us you want to use a restrictive domain with an unauthorized resigner.

Your list submission to ietf.org  is using From: address 
rewrite changing and destroying your original signature and author to a 
different address.

This drastic move is not welcome but that is what DMARC p=reject is requiring 
transport and mail handlers to do.

—
HLS

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

[Hector Santos]

> On Mar 30, 2023, at 10:16 AM, Todd Herr 
>  wrote:
> 
> My fear is that adding further text to DMARCbis that says "MUST NOT use 
> p=reject" along with the new language in Policy Enforcement Considerations 
> results in a spec that says:
> As a domain owner, you can request treatment for unauthenticated mail, but 
> your request may not (and probably will not) be honored, and by the way
> You mustn't request treatment anyway
> The next step in that path is a world where the p= tag loses its usefulness 
> as a proxy for where a domain owner is in its authentication journey, because 
> everyone's at p=none, because DMARCbis says so. 
> 
> At this point, DMARC becomes useless, because one of two things happen:
> Failed authentication loses its meaning as a signal because no one knows 
> whose authentication policies are thought to be solid and whose aren't, or
> Failed authentication is given more weight than it should be given because a 
> DMARC record becomes a de facto p=reject, because no one knows whose 
> authentication policies are thought to be solid and whose aren't
> Anyway, this is why I continue to support the idea of describing the 
> interoperability issues, but opposed to the idea of telling domain owners not 
> to use p=reject.
> 

A domain should not use a policy that will cause problems.  However, even for 
domains that are private, it may not have control of target mail MX, the 
hosting MSA, MTA, MLS involved nor what the final MDA will do.  The reputation 
of the MTA is hurt too with p=reject.  We have to clean the mess up of the 
domain p=reject mail senders in other to transport their mail.

DMARC policy model has been useless for the same reason ADSP — lack of a 3rd 
party (re)signer authorization.  Same problem.  We abandoned ADSP for this 
reason. The only key difference DMARC offered is reporting and imv, it’s the 
only reason it is still alive.   If its going to replace ADSP as far as policy 
is concern, then it should to fix the problem offer something more that deals 
with the problems and not just leaving hanging for the network to fix.

DMARCbis should come with a MUST NOT when additional information to help the 
receiver what to do when failure occurs is not available.

I propose two tags:

-rewrite

says if the first initiate signer succeeded and you need to resign, then you 
are allowed to rewrite the ADID.  This handles list distribution problems.
If a domain does not have -rewrite, a subscriber and list submission MUST be 
denied.

-atps

says if ADID does not equal SDID then do an SDID ATPS lookup at the ADID zone.  
This handles reception for all mail.  If a domain does not have -atps, then the 
receiver MUST honor the domain reject policy for failures.


This allows you to keep your strong DKIM Policy advocacy like many here are, 
like me. 

DMARC did one thing good.   

When we started all this in MARID, all the new DNS-based applications proposed, 
SPF, DKIM, ADSP and many other LMAP protocols explored, we all knew it will 
take many years before we can begin to measure the payoff with receivers 
performing the DNS Lookups we needed them to do.  With DMARC, I believe we know 
have the receiver lookup market penetration to justify an additional ATPS 
lookup piggybacking off the DMARC record lookup.

We can do a lot more to resolve many of the problems we had. 

But it always came to the question, why can’t reputation do this in lieu of 
policy?

Well for obvious reasons.  There is no standard and there are too many false 
positives and erroneous labeling of bad guys. Different receivers can have 
different assessment methods or none at all (most of us), making small systems 
targets of DKIM spoofs, replays.   The Batteries Required syndrome.

However, reputation is needed as a layer after the DKIM Policy is done. We have 
VBR.  What’s wrong with it?

Even providing a new DMARC extended tag 

-trust:acme-trust-service

Can tell the receiver to do a trust check on the signer domain. It does not 
mean the receiver would honor the trust results but maybe it could help systems 
with the mail handling.



—
HLS___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

[Hector Santos]

On 3/29/2023 9:16 PM, John Levine wrote:

It appears that Murray S. Kucherawy   said:


This is laid out in RFC 6377, Section 5.2, if it would be helpful to have
something published to reference.  Indeed, ADSP threatened the same damage
that DMARC "p=reject" causes, which I think was one of the reasons it never
got adopted.

It wasn't just a threat -- someone got bounced off an IETF list shortly
after the ADSP draft came out when some eager beaver implemented it.



I was the one who first reported the problem of what will happen when 
the SSP (DKIM Policy) was split from DKIM.  I was able to show this 
when the IETF was not yet supporting DKIM.


With the split, DKIM became DKIM-BASE and SSP became ADSP with all the 
3rd party (re)signer concepts from SSP removed.   It went from SSP 
policy which considered 3rd party signers:


   o=?  WEAK (signature optional, no third party)
   o=~  NEUTRAL (signature optional, 3rd party allowed)
   o=-  STRONG  (signature required, 3rd party allowed)
   o=!  EXCLUSIVE (signature required, no 3rd party)
   o=.  NEVER  (no mail expected)
   o=^  USER

to a very limited 1st party only policy.

   DKIM=DISCARDalways expect to be signed by the Author Domain
   DKIM=ALL  always expect to be signed but by who?

The only flexibility was DKIM=ALL.   We presumed it could allow for a 
3rd party signer and it would be useful by mailing list servers. 
Unfortunately, we could not resolve how to authorize the 3rd party 
signers and ATPS was said not to scale.


So in my view, its not ADSP, DMARC as the problem -- its a lack of a 
3rd Party Authorization model in the protocol.


I see more domains are being "dmarca-tized" without their domain owner 
knowledge of what the hosting system is doing nor how the MDA hosting 
will handle mail.   This is causing major problems that requires 
drastic mail handling actions.


I now have forwarding mail logic that determine the sender's DMARC 
policy.   If weak or none it can be forwarded. If strong, it stays for 
mail pickup.


I long had mailing list subscripting logic to stop a subscriber with a 
strong DMARC policy.


I will probably begin to add a From Rewrite but I would prefer if the 
DMARC record has a domain authorization to do so, with perhaps a 
`-rewrite` tag to signify any form of rewriting allowed.


I think we need to focus more on DMARC having extended tags that 
address many of the issues and ideas we have encountered. Receivers 
want to honor the author domain wishes for handling failure when 
various parts fail to meet their protocol-defined expectations.  But 
if honoring going to cause more problems, then we either abandon DMARC 
like we did with ADSP or we add 3rd party domain considerations.


Reject domain polices should support these ideas for handling outbound 
and inbound mail handling.


-p=reject -rewrite -atps

-rewrite

says if the first initiate signer succeeded and you need to resign, 
then you are allowed to rewrite the ADID.  This handles list 
distribution problems.If a domain does not have -rewrite, a 
subscriber and list submission MUST be denied.


-atps

says if we ADID does not equal SDID then we will do an SDID ATPS 
lookup at the ADID zone.  This handles reception for all mail.  If a 
domain does not have -atps, then the receiver MUST honor the domain 
reject policy for failures.


--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

[Hector Santos]

On 3/31/2023 12:49 AM, Barry Leiba wrote:

I don't see any hope that people will back away from the perceived security 
benefits of DMARC to
accommodate mailing lists, even if we publish Barry's language.

But here's where we're missing my main point, so I'll highlight it:

The spec needs to say what the right thing is for the protocol to do,
and what the right way to deploy it is to avoid damage to existing
services.  "MUST NOT use p=reject for a domain that hosts
general-purpose user email" is the right thing to say.  Saying the
right thing is not dependent upon whether some large senders will
decide not to abide by it -- they have the right to make their own
decisions, and whether they back away or not isn't the point of this
text.  We should not have an IETF proposed standard that can knowingly
break existing services without strong normative text that warns
against deploying it that way.


+1

I feel your frustration as well.  But if you really feel that way, we 
need to deprecate, begin the process of abandoning DMARC and begin 
focusing in other directions.  But there is a solution.


We can save DMARC by adding ATPS support to it. A simple tag -atps 
tell the verifier to check for a signer ATPS authorize record.  Alll 
ESPs can do a 2nd lookup.  Thats not a scaling issue.


ALL ESPs, like you said, can not be a strong DMARC domain for outbound 
mail because their end users are very loose with their domain usage.   
But Yahoo.com is doing it and I think it helps smaller domains not get 
hurt from bigger ESPs spam.  But this only works if they ALSO support 
ATPS on the receiving side as well!!!


What will a ATPS concept do?   I think if we want to finally end this 
near 20 year project:


-  DKIM-BASE, no changes
-  Add ATPS concept to DMARCbis
-  Add VBR concept because it is a reputation model as a function of 
ADID and SDID.
-  Push ARC aside.  It is not DKIM and way too much overhead and 
clearly, it can not be the replacement solution for not doing ATPS.


For most domains in the market, DKIM. DMARC and ATPS is enough for 
deterministic evaluation.  For most emails transported, a  DKIM VBR 
would address an IETF centralize reputation solution and also the 
potential business market as Levine wanted with VBR.  The DNS order 
lookup would be:


- SPF
- DKIM
- DMARC
- ATPS
- VBR


But we continue to have the reputation model being pushed over policy 
and we continue to have this problems.


In regards to the text,   I think MUST NOT is appropriate but it must 
explain why.  If you consider the above, then the text will change:


   MUST NOT if no 3rd party signer solution is in place.

Then reference ATPS in the IETF manner for a proposed experiment.

--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [Ietf-dkim] On the current state of DKIM and the replay problem

[Hector Santos]

> On Mar 28, 2023, at 1:36 PM, Michael Thomas  wrote:
> 
> Since the chair is threatening to ban me, I decided to write up my view of 
> things in a longer form.
> 
> https://rip-van-webble.blogspot.com/2023/03/on-dmarc-arc-and-dkim-replays.html
> 
> This has some technical aspects and meta aspects. The meta aspects can be 
> addressed in the blog comments itself instead of here.
> 
> Mike

Mike, 

I asked ChatGPT 4.0 to summarize your extensive blog post for me.

Summary:

The blog post discusses concerns related to DMARC, ARC, and DKIM Replays in the 
context of email security and the working group's efforts to address these 
issues. The author expresses confusion and skepticism about the necessity and 
effectiveness of the proposed solutions.

Top concerns and conflicts:

1. Unclear motivations and politics behind DMARC: The author questions the 
reasons behind DMARC's creation and its differences from ADSP, as well as the 
intentions of the working group members involved.

2. ARC's purpose and necessity: The author doubts the need for ARC, which 
recreates DKIM and Authentication-Results with minor tweaks, and its ability to 
solve mailing list traversal problems.

3. DKIM Replay problem and lack of clear solutions: The blog post raises 
concerns about the lack of consensus on how to address the issue of DKIM 
Replays, as well as the opacity of mailbox providers' practices.

4. Insufficient information and secrecy: The author argues that the lack of 
transparency from mailbox providers and the closed nature of industry groups 
like M3AAWG hinder the working group's ability to develop effective solutions.

5. Ineffective proposed solutions: The blog post criticizes the solutions 
proposed so far, arguing that they do not seem practical or likely to
work.

6. Unclear definition of success: The author points out that there is no clear 
goal for the working group to achieve, as the spam issue is not a matter of 
absolutes but rather probabilities.

7. Passive-aggressive working group chairs: The author criticizes the behavior 
of the working group chairs, suggesting that they may have
their own agendas or be uninterested in finding solutions.

8. Doubtful effectiveness of the rechartered working group: The author believes 
that the working group's track record, combined with the lack
of available tools and knowledge within the IETF community, makes success 
unlikely.


—
HLS



___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

[Kernel-packages] [Bug 2009815] Re: No HDMI audio anymore

[Hector Caez]

*** This bug is a duplicate of bug 2009136 ***
https://bugs.launchpad.net/bugs/2009136

Muchas gracias a las anteriores personas por informar la solución de
este problema que desde hace días tenía y no le encontraba solución,
puedo confirmar que eliminando el kerner 5.19.0-35 se arregla el
problema de sonido del hdmi

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2009815

Title:
  No HDMI audio anymore

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  lsb_release -rd
  Description:  Ubuntu 22.10
  Release:  22.10

  Wayland

  5.19.0-35-generic does not work
  5.19.0-32-generic does work

  If following messages occures during boot, no HDMI audio :
  hdaudio hdaudioC1D0: no AFG or MFG node found
  snd_hda_intel :01:00.1: no codecs initialized

  No HDMI Audio does mean : 
  Via lspci -nnk I get the following device :

  01:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Baffin 
HDMI/DP Audio [Radeon RX 550 640SP / RX 560/560X] [1002:aae0]
Subsystem: ASUSTeK Computer Inc. Baffin HDMI/DP Audio [Radeon RX 550 
640SP / RX 560/560X] [1043:aae0]
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel

  But this device will neither be indicated via pavucontrol nor via
  audio settings (mainsettings).

  Before I did installed the Ubuntu 22.10 on my system, I did test the
  live system. It did work without problems. And two audio devices, that
  is what I expect, will be indicated in the audio settings (one of
  them, the given above via lspci -nnk, is necessary to have audio via
  HDMI)

  ProblemType: Bug
  DistroRelease: Ubuntu 22.10
  Package: linux-image-5.19.0-35-generic 5.19.0-35.36
  ProcVersionSignature: Ubuntu 5.19.0-35.36-generic 5.19.17
  Uname: Linux 5.19.0-35-generic x86_64
  ApportVersion: 2.23.1-0ubuntu3
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  richard1402 F wireplumber
   /dev/snd/seq:richard1399 F pipewire
  CRDA: N/A
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Mar  9 10:11:41 2023
  InstallationDate: Installed on 2023-03-04 (4 days ago)
  InstallationMedia: Ubuntu 22.10 "Kinetic Kudu" - Release amd64 (20221020)
  IwConfig:
   lono wireless extensions.
   
   enp3s0no wireless extensions.
  MachineType: System manufacturer System Product Name
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=de_DE.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 amdgpudrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.19.0-35-generic 
root=UUID=df59b1c2-c5b9-483d-b033-7c6b2264dc75 ro quiet splash vt.handoff=7
  PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No 
PulseAudio daemon running, or not running as session daemon.
  RelatedPackageVersions:
   linux-restricted-modules-5.19.0-35-generic N/A
   linux-backports-modules-5.19.0-35-generic  N/A
   linux-firmware 20220923.gitf09bebf3-0ubuntu1.4
  RfKill:
   
  SourcePackage: linux
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 09/18/2013
  dmi.bios.release: 4.6
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 4802
  dmi.board.asset.tag: To be filled by O.E.M.
  dmi.board.name: P8H61-M PRO
  dmi.board.vendor: ASUSTeK COMPUTER INC.
  dmi.board.version: Rev x.0x
  dmi.chassis.asset.tag: Asset-1234567890
  dmi.chassis.type: 3
  dmi.chassis.vendor: Chassis Manufacture
  dmi.chassis.version: Chassis Version
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr4802:bd09/18/2013:br4.6:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnP8H61-MPRO:rvrRevx.0x:cvnChassisManufacture:ct3:cvrChassisVersion:skuSKU:
  dmi.product.family: To be filled by O.E.M.
  dmi.product.name: System Product Name
  dmi.product.sku: SKU
  dmi.product.version: System Version
  dmi.sys.vendor: System manufacturer

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2009815/+subscriptions


-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

[Hector Santos]

> On Mar 26, 2023, at 1:11 PM, Michael Thomas  wrote:
> My contention is that documenting what has failed in the problem statement 
> saves time eventually in the solution space as you can reference it when 
> somebody brings it up as to why it doesn't work. It would be just a cut and 
> paste for (3) along with other discussion of what was also considered and 
> rejected. For (4) it gives a basis of what not to suggest.
> 
Michael,  first, I want to express my thanks and support your stance.

Thank you for expressing the thoughts of the silent majority. I have been 
IETF-style silenced here because of my strong DKIM Policy model position.  It 
has never changed.  And history only continues to prove my concerns correct.

The DKIM and Reputation modeling has been long dreamed, but to this day - we 
have nada.  

The closest thing we have us VBR, It make an Author Domain (ADID) and SDID 
(Signer Domain) association.  So does ATPS.

Since MARID, it has been about associations of two or more identities.

With SPF, an LMAP concept, it was an Return-Path Domain::IP association.

With ADSP is was an Author Domain (ADID) and Signer Domain (SDID) association 
but we could  only work out the 1st party association with ADID equal SDID.  
This is DMARC.

With ATPS, it proposed an 1st party ADID and 3rd party SDID association.  We 
can add this to DMARC.

But someone said it does not scale and we stopped  They said Reputation is 
better!!  No Dependency on ADID!  We have nothing since 2005!!!

—
Has


___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

[Hector Santos]

> On Mar 26, 2023, at 6:13 AM, Murray S. Kucherawy  wrote:
> 
> On Sat, Mar 25, 2023 at 10:29 AM Michael Thomas  > wrote:
>> On 3/24/23 6:19 PM, Barry Leiba wrote:
>> > I don't agree with the premise.  I think what was tried and didn't
>> > work should be documented in the result that the working group comes
>> > out with, but not in the problem statement.
>> 
>> There isn't a place in the charter/milestones for that.
> 
> The charter identifies these possible outputs in some combination:
> 
> (1) a clear problem statement;


My understanding so far is this an ESP “Email Service Provider” only issue or a 
domain that allows for free sign-ups for email services using their domains. An 
ESP , i.e. example.esp, can be any size, high or low scale, it allows free 
sign-up service.

My understanding so far is the exploitation are free sign-up accounts using the 
domain to create a template message to some spammer box where the example.esp 
is signing the bound message.  The spammer then massages the message without 
damaging the signature and attacks downlink receivers who accepts the signer 
and/or always trust the example.esp domain.  The presumption is (imo erroneous) 
the receivers are using the same DKIM Reputation Lookup Server that example.esp 
is a member of and that these receivers are using the SDID (Signer Domain 
Identity) as input to a trust service there by bypassing spam security checks.

This is the classic “Batteries Required” syndrome that was predicted with the 
DKIM Reputation Model   With no standard, receivers do not have the tools so 
resolve this problem.

But ESP can do more control their users.   ESP can also make sure users can not 
create signed templates.

We can also finish the DKIM Policy Protocol and basically extend DMARC beyond 
its current limits.  A receiver can probably read a tag ‘-enabled.x’ that tell 
receivers to apply the signature expiration.

—
HLS


___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [dmarc-ietf] ARC Dependency?

[Hector Santos]

Wouldn’t it be far easier to add the trusted 3rd party domains in some DNS 
table or lookup, ala an ATPS-like protocol? The RFC5322 ARC overhead is 
horrendous. Never mind the complexity evolved to implement.

> On Mar 24, 2023, at 7:17 PM, Seth Blank  wrote:
> 
> Microsoft is using ARC quite heavily, and has reported on this list and at 
> M3AAWG of the impact it makes
> 
> Microsoft even has on their public roadmap that tools are being built for 
> their customers to enable per-customer sealers that they choose to trust: 
> https://www.microsoft.com/en-us/microsoft-365/roadmap?filters==dmarc
> 
> On Fri, Mar 24, 2023 at 5:06 AM Steven M Jones  > wrote:
>> On 3/24/23 3:48 AM, Douglas Foster wrote:
>> >
>> > Do we know if any entity other than Google is successfully using ARC 
>> > as an evaluation tool?
>> 
>> 
>> FWIW: In late 2021 a "German company" reported that it was able to 
>> "recover" about 10% of messages that had failed other authentication 
>> checks by validating ARC.
>> 

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [Ietf-dkim] Comments on draft-chuang-dkim-replay-problem

[Hector Santos]

+1.

ARC is not a solution, but it is a good part of the problem. It’s not hard to 
see how our fall back to defocusing, the de-emphasis of the DKIM Policy Model 
in lieu of Reputation Modeling creating this issue.

Every issue we have today is nearly 100% because of the lob-sided efforts to 
impose a DKIM Reputation Model on receivers when it was predicted during MARID 
and into early DKIM that if we do this, we will have issues related to the 
"Batteries Required" Syndrome.

- No standard Reputation Protocol
- No single repository of GOOD vs BAD domains
- To be somewhat effective, Batteries Requires (paid 3rd party service)
- Exploiters attacking those without Batteries.

This is why the original DKIM Charter tried really hard to focus on 
Deterministic Protocols rather than Heuristic Protocols based on the Author 
Domain. The original DKIM Charter considered “Reputation Modeling” out of scope.

Now it is in scope and we are dealing with issues that can not be solved — not 
without addressing the DKIM Policy Model for 1st and 3rd party signers.

If the group effort is to be able to write a PS for DKIM + Reputation Modeling, 
we should highly note it was all perpetuated by our defocus of DKIM Policy 
Modeling and the lack of will to fix DMARC.


—
HLS

> On Mar 24, 2023, at 1:42 PM, Michael Thomas  wrote:
> 
> 
> 
> On 3/24/23 10:22 AM, Murray S. Kucherawy wrote:
>> 
>> 
>> Fine with me, it's far from a showstopper overall.  I just made the 
>> suggestion.
>> 
> This wg should be concerned with DKIM problems, not other wg problems and 
> especially for experimental rfc's of dubious value and complete mysteries as 
> to what they have to do with their actual charter.
> 
> Mike
> 
> ___
> Ietf-dkim mailing list
> Ietf-dkim@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-dkim

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Koha] Koha mysql DBMS fix

[Hector Gonzalez Jaime]

You need to add a line to one of mysql's configuration files, you may 
create one just for this, the complete file would look like:


[mysqld]
init-file = /var/lib/mysql/init-file_library.sql

you may change "library" with your own libraries name.

And you must create that file, with the sql from the wiki.

from the error message, my guess is your sysadmin put this line outside 
the scope of a [mysqld] section.  [mysql] is not good enough, as it 
refers to mysql's CLIENT program, not your database server.



On 3/21/23 20:59, Decka David wrote:

Dear Koha Community,

Here is a problem that someone here in this community might come across or
know to share how to solve this problem; I talked with my ICT administrator
to solve this issue to have access to the koha mysql but was unable to do
so to fix the DBMS auto increment problem. The issue  of the "unknown
variable" in the script is;

*mysql: [ERROR] unknown variable
'init-file=/var/lib/mysql/init-file_koha_library.sql'*

I can do the mysqldump and run the backup on the test server but on the
production server, I have no access at all.
Looking into the past forum emails, wikis there is not much help.

Thanking everyone here in advance for their invaluable insight and pointing
me towards solving the problem.

Kind regards



*Decka David*
Matheson Librarian | PNG University of Technology | PMB | Lae, 411 | Morobe
Province | PAPUA NEW GUINEA
Alternate E: decka.da...@gmail.com | P: 657 4734353 <%28657%29%20473-4353> |
F: 675 4374363
___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha


--
Hector Gonzalez
ca...@genac.org

___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Canonical-hw-cert] [Merge] hwcert-jenkins-jobs:dev-kivu-update-job into hwcert-jenkins-jobs:master

[Hector CAO]

thanks ! see below

Diff comments:

> diff --git a/jobs/kivu/run-kivu.sh b/jobs/kivu/run-kivu.sh
> index 4dd109a..559336c 100644
> --- a/jobs/kivu/run-kivu.sh
> +++ b/jobs/kivu/run-kivu.sh
> @@ -42,14 +42,22 @@ cat > job.yaml <  mkdir -p artifacts
>  cp checkbox-launcher artifacts
>  
> +# stop auto-upgrades
> +_run sudo systemctl stop unattended-upgrades.service
> +_run sudo systemctl stop apt-daily-upgrade.service

thanks for the suggestion, that is great, right now, i would like to restart 
the upgrade at the end of the tests (see comment below - we will share some 
no-provisionable devices with cert team) so i will try not to remove the 
package completely, does that make sense for you ?

> +
>  echo "preparing the system..."
>  _run sudo add-apt-repository -y universe
>  _run sudo apt-get -qq update
> -_run sudo apt-get -qq install -y openssh-server pastebinit 
> intel-gpu-tools intel-media-va-driver-non-free gstreamer1.0-vaapi 
> gstreamer1.0-tools vainfo
> +_run sudo apt-get -qq install -y openssh-server pastebinit 
> intel-gpu-tools radeontop intel-media-va-driver-non-free gstreamer1.0-vaapi 
> gstreamer1.0-tools vainfo mpv gnome-screensaver ydotool
> +_run sudo apt-get -qq install -y wl-clipboard
> +_run sudo add-apt-repository -y ppa:kivuteam/ppa
> +_run sudo apt-get -qq update
> +_run sudo apt-get -qq install -y gfxi
>  _run sudo apt-get -qq upgrade -y
>  _run sudo snap install --channel beta/hwacc chromium
>  _run sudo snap install checkbox22
> -_run sudo snap install checkbox-kivu-classic --classic
> +_run sudo snap install --channel latest/edge checkbox-kivu-classic 
> --classic
>  
>  echo Starting
>  # DISPLAY=:0 to make sure graphic test jobs were tested expectedly 
> (not necessary in remote)
> @@ -66,6 +74,19 @@ cat > job.yaml <  mv submission.json artifacts
>  echo "Files in artifacts:"
>  ls artifacts
> +
> +# cleanup (do not remove everything because some package can be 
> already here ..)
> +_run sudo snap remove checkbox-kivu-classic
> +_run sudo snap remove checkbox22
> +_run sudo snap remove chromium
> +_run sudo apt-get remove -y gfxi
> +_run sudo add-apt-repository -d -y ppa:kivuteam/ppa
> +_run sudo apt-get remove -y wl-clipboard
> +_run sudo apt-get remove -y pastebinit intel-gpu-tools radeontop 
> intel-media-va-driver-non-free gstreamer1.0-vaapi gstreamer1.0-tools mpv 
> gnome-screensaver ydotool
> +
> +# restart auto-upgrades
> +_run sudo systemctl start unattended-upgrades.service
> +_run sudo systemctl start apt-daily-upgrade.service

you are right, the reason is there is just a temporary need of test cleanup 
because we will do tests on no-provisionable devices that are shared with the 
cert team,

>  EOF
>  
>  #Remove previous venv


-- 
https://code.launchpad.net/~hwcert-jenkins/hwcert-jenkins-jobs/+git/hwcert-jenkins-jobs/+merge/438932
Your team hwcert-jenkins is subscribed to branch hwcert-jenkins-jobs:master.


-- 
Mailing list: https://launchpad.net/~canonical-hw-cert
Post to : canonical-hw-cert@lists.launchpad.net
Unsubscribe : https://launchpad.net/~canonical-hw-cert
More help   : https://help.launchpad.net/ListHelp

Re: [Ietf-dkim] Welcome to the rechartered working group

[Hector Santos]

Took a moment to go over this purported problem with replays:

1.1.  The problem

   Since many domains (including those of bad actors) list DKIM records,
   receiving systems track the history of messages using a DKIM-based
   domain name, to formulate a reputation for the name, and then to
   classify incoming emails.  


The way this is phrased suggest it is a common practice for a receiving system 
to “track the history of messages using a DKIM-based domain name.”

I’m not doing any such thing nor is any installation of our package.  What 
domain(s) or package(s) are doing this? 

As I read more, I believe too much stake is put on reputation which causes a 
heighten concern for a self-created problem by an ESP.

While an ESP may be considered “High Value” as an enterprise, i.e. gmail.com, 
by no means, is the domain “reputation” is “good” as “high”.   I don’t consider 
any ESP domain having a level of good reputation purely based their domain 
name. 

I am leaning towards this is not a DKIM issue.  It’s an ESP issue.  They need 
to deal with the potentials of malicious users.

Since day one,  DKIM was about establishing a technical method to prove 
authentication by keeping message integrity intact.  When verification 
deviated, a point of failure and possible actions was considered using a DKIM 
Policy Add-on, not a Reputation Protocol add-on simply because there are none 
(standard method).   

Unfortunately we removed SSP (which was built into DKIM), separated as ADSP and 
replaced with very poor substitute DMARC  and we continue to have issues with 
3rd party signature models.

The concerns about ESP reputation replay abuse is because they have a 
proprietary DKIM domain-based method for reputation.   This can be addressed 
but it requires a greater adoption of a DKIM Policy Protocol that is above and 
beyond what DMARC offers with its limited concepts and crippling alignment 
restraints.

In short, DKIM is fine.  Only a system using a proprietary reputation model 
based on its ESP domain has a higher replay problem. Systems that do not use a 
reputation model do not have this problem.

But, via POLICY if the domain using reputation wishes a verifier to put more 
restrictions on a received signed domain, i.e.  enforce `x=` expiration tag, I 
am all for it.

Thanks

Hector Santos CEO/CTO
Santronics Software, Inc.

 

> On Mar 7, 2023, at 7:09 AM, Laura Atkins  wrote:
> 
> All
> 
> The DKIM working group is now active again (thanks Murray!).  The chairs 
> wanted to send out a short note to welcome everyone and talk about our next 
> steps.
> 
> Our first deadline is next month - to get a consensus problem statement 
> submitted on the IETF data tracker at https://datatracker.ietf.org/group/dkim/
> 
> There is a current problem statement at 
> https://datatracker.ietf.org/doc/draft-chuang-dkim-replay-problem/. Please 
> take a moment to read through it and provide feedback. This chair thinks we 
> should not be providing solutions in the problem statement. We should be 
> primarily describing what the issue is and why we think the issue is with the 
> protocol. We will deal with solutions in the actual document. 
> 
> There was also a DKIM replay session at the most recent M3AAWG meeting. As I 
> understand it, they’re working on a BCP in parallel with the IETF. Many folks 
> are active in both groups. 
> 
> Due to M3AAWG privacy requirements, we are constrained in what we can share 
> from the meeting itself. However, if you were here and were on the panel or 
> part of the discussions, feel free to share with us some of your thoughts on 
> the problem, possible solutions and what your organizations have done to 
> address the issue. 
> 
> One of the panel members has shared the following from what he said at the 
> session:
> 
> * RFC 6376 itself says "x=" is not a viable mechanism to deal with replay.
> * There may only be a best practices solution, and not a protocol solution.
> * DKIM has since the beginning kept itself completely separate from the 
> message transport.  Several of the proposed solutions (including mine) take 
> leaps of varying sizes into the realm of DKIM knowing something about the 
> transport; the lightweight ones connect the message to the envelope somehow, 
> and the more heavyweight ones mean DKIM filters have to learn about MXes and 
> whatnot.  We have to be absolutely certain that we want to break that wall if 
> we go this way, because once we do, there will be no turning back.
> 
> There was also a DKIM replay session at the most recent M3AAWG meeting. As I 
> understand it, they’re working on a BCP in parallel with the IETF. Many folks 
> are active in both groups. 
> 
> Due to M3AAWG privacy requirements, we are constrained in what we can share 
> from the meeting itself. However, if you were here and were on the 

Re: [Ietf-dkim] DKIM update - header tag

[Hector Santos]

-1.  The v= tag description is accurate.

There is no current DKIM design expectation for any other string value.  The 
current spec is `v=DKIM1`.  Any software writing `v=DKIM1.0` is technically 
“broken” and should not be encourage to exist or perpetuate.

IOW, software should not process the record if it’s not literally `v=DKIM1` and 
if the `v=` tag is missing, the default is `v=DKIM1`.

If software want to consider preparing for the future with different v= tag 
string values describing an extended DKIM specification, it is always possible 
to have this. But for the current spec and standard, `v=DKIM1` is the only 
expectation,  not `v=DKIM1.0` — there is no spec for this and the current spec 
is clear DKIM1 and DKIM1.0 are not the same,

Thanks

—
HLS


> On Mar 10, 2023, at 1:46 PM, Jan Dušátko  
> wrote:
> 
> Dear,
> I got recommendation to propose changes in that mailing group.
> My work depend on appropriate protection of our brand, however this tasks 
> require also management of records required for that protection. We have huge 
> problem with identification of selector records required by DKIM and also 
> this make for us problem with compatibility. We would like to strongly follow 
> RFCs, but sometimes v=DKIM1 tag are resolved like issue as well as sometime 
> missing of that tag do the same. This is a reason, why I would like to 
> propose mitigation of problem, caused by word RECOMMENDED in standard RFC 
> 6376:
> 
>v= Version of the DKIM key record (plain-text; RECOMMENDED, default
>   is "DKIM1").  If specified, this tag MUST be set to "DKIM1"
>   (without the quotes).  This tag MUST be the first tag in the
>   record.  Records beginning with a "v=" tag with any other value
>   MUST be discarded.  Note that Verifiers must do a string
>   comparison on this value; for example, "DKIM1" is not the same as
>   "DKIM1.0".
> 
> I would like to recommend change work RECOMMENDED to MANDATORY, where whole 
> article be after change
> 
>v= Version of the DKIM key record (plain-text; MANDATORY, default
>   is "DKIM1").  If specified, this tag MUST be set to "DKIM1"
>   (without the quotes).  This tag MUST be the first tag in the
>   record and this tag must exist.  Records beginning with
>   a "v=" tag with any other valueMUST be discarded.  Note that
>   Verifiers must do a string comparison on this value; for
>   example, "DKIM1" is not the same as "DKIM1.0".
> 
> 
> 

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re:[VOTE] KIP-911: Add source tag to MirrorSourceConnector metrics

[Hector Geraldino (BLOOMBERG/ 919 3RD A)]

+1 (non-binding)

From: dev@kafka.apache.org At: 03/15/23 07:08:33 UTC-4:00To:  
dev@kafka.apache.org
Subject: [VOTE] KIP-911: Add source tag to MirrorSourceConnector metrics

Hi,

I'd like to start the vote on KIP-911 to add the source cluster alias
as a tag on the MirrorSourceConnector metrics:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-911%3A+Add+source+tag+to+M
irrorSourceConnector+metrics

Thanks,
Mickael

[Canonical-hw-cert] [Merge] hwcert-jenkins-jobs:dev-kivu-update-job into hwcert-jenkins-jobs:master

[Hector CAO]

Hector CAO has proposed merging hwcert-jenkins-jobs:dev-kivu-update-job into 
hwcert-jenkins-jobs:master.

Commit message:
Update for kivu project

- Teardown cleanup
- Update system provisioning to Ubuntu 22.04.2
- Update according to latest release of checkbox-kivu-provider

KIVU-108


Requested reviews:
  hwcert-jenkins (hwcert-jenkins)

For more details, see:
https://code.launchpad.net/~hwcert-jenkins/hwcert-jenkins-jobs/+git/hwcert-jenkins-jobs/+merge/438932
-- 
Your team hwcert-jenkins is requested to review the proposed merge of 
hwcert-jenkins-jobs:dev-kivu-update-job into hwcert-jenkins-jobs:master.
diff --git a/jobs/kivu/checkbox.conf b/jobs/kivu/checkbox.conf
index 13ae237..ec98b3e 100644
--- a/jobs/kivu/checkbox.conf
+++ b/jobs/kivu/checkbox.conf
@@ -14,5 +14,8 @@
 [ui]
 type = silent
 
+[manifest]
+com.canonical.certification::has_camera = true
+
 [transport:c3]
 secure_id = \$HEXR_DEVICE_SECURE_ID
diff --git a/jobs/kivu/run-kivu.sh b/jobs/kivu/run-kivu.sh
index 4dd109a..5d456ed 100644
--- a/jobs/kivu/run-kivu.sh
+++ b/jobs/kivu/run-kivu.sh
@@ -9,7 +9,7 @@ cat > job.yaml < job.yaml < job.yaml <-- 
Mailing list: https://launchpad.net/~canonical-hw-cert
Post to : canonical-hw-cert@lists.launchpad.net
Unsubscribe : https://launchpad.net/~canonical-hw-cert
More help   : https://help.launchpad.net/ListHelp

[jira] [Commented] (KAFKA-14809) Connect incorrectly logs that no records were produced by source tasks

[Hector Geraldino (Jira)]

[ 
https://issues.apache.org/jira/browse/KAFKA-14809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17700372#comment-17700372
 ] 

Hector Geraldino commented on KAFKA-14809:
--

No that's perfect. Thanks [~ChrisEgerton]!

> Connect incorrectly logs that no records were produced by source tasks
> --
>
> Key: KAFKA-14809
> URL: https://issues.apache.org/jira/browse/KAFKA-14809
> Project: Kafka
>  Issue Type: Bug
>  Components: KafkaConnect
>    Reporter: Hector Geraldino
>Assignee: Hector Geraldino
>Priority: Minor
>
> There's an *{{if}}* condition when [committing 
> offsets|https://github.com/apache/kafka/blob/trunk/connect/runtime/src/main/java/org/apache/kafka/connect/runtime/WorkerSourceTask.java#L219]
>  that is referencing the wrong variable, so the statement always evaluates to 
> {*}true{*}.
> This causes log statements like the following to be spuriously emitted:
> {quote}[2023-03-14 16:18:04,675] DEBUG WorkerSourceTask\{id=job-0} Either no 
> records were produced by the task since the last offset commit, or every 
> record has been filtered out by a transformation or dropped due to 
> transformation or conversion errors. 
> (org.apache.kafka.connect.runtime.WorkerSourceTask:220)
> {quote}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (KAFKA-14809) Fix logging conditional on WorkerSourceTask

[Hector Geraldino (Jira)]

Hector Geraldino created KAFKA-14809:


 Summary: Fix logging conditional on WorkerSourceTask
 Key: KAFKA-14809
 URL: https://issues.apache.org/jira/browse/KAFKA-14809
 Project: Kafka
  Issue Type: Bug
  Components: KafkaConnect
Reporter: Hector Geraldino
Assignee: Hector Geraldino


There's an *{{if}}* condition when [committing 
offsets|https://github.com/apache/kafka/blob/trunk/connect/runtime/src/main/java/org/apache/kafka/connect/runtime/WorkerSourceTask.java#L219]
 that is referencing the wrong variable, so the statement always evaluates to 
{*}true{*}.

It's a subtle bug, which went undetected probably because its only used to log 
information about pending committable offsets.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (KAFKA-14809) Fix logging conditional on WorkerSourceTask

[Hector Geraldino (Jira)]

Hector Geraldino created KAFKA-14809:


 Summary: Fix logging conditional on WorkerSourceTask
 Key: KAFKA-14809
 URL: https://issues.apache.org/jira/browse/KAFKA-14809
 Project: Kafka
  Issue Type: Bug
  Components: KafkaConnect
Reporter: Hector Geraldino
Assignee: Hector Geraldino


There's an *{{if}}* condition when [committing 
offsets|https://github.com/apache/kafka/blob/trunk/connect/runtime/src/main/java/org/apache/kafka/connect/runtime/WorkerSourceTask.java#L219]
 that is referencing the wrong variable, so the statement always evaluates to 
{*}true{*}.

It's a subtle bug, which went undetected probably because its only used to log 
information about pending committable offsets.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: question about rc.local

[Richard Hector]

On 10/03/23 15:16, Corey Hickman wrote:



On Fri, Mar 10, 2023 at 9:44 AM > wrote:




I'm much happier with a "real" email client.




what real email client do you use? :)
I am using Mac as the regular desktop, Mac's Mail App is hard to use.
Though my server is debian system.


Thunderbird? Works on Debian as well, so you can keep using it when you 
upgrade :-)


Cheers,
Richard

Re:[ANNOUNCE] New Kafka PMC Member: Chris Egerton

[Hector Geraldino (BLOOMBERG/ 919 3RD A)]

Congratulations Chris! Well deserved

From: dev@kafka.apache.org At: 03/09/23 13:12:15 UTC-5:00To:  
dev@kafka.apache.org
Subject: [ANNOUNCE] New Kafka PMC Member: Chris Egerton

Hi, Everyone,

Chris Egerton has been a Kafka committer since July 2022. He has been very
instrumental to the community since becoming a committer. It's my pleasure
to announce that Chris is now a member of Kafka PMC.

Congratulations Chris!

Jun
on behalf of Apache Kafka PMC

[jira] [Assigned] (KAFKA-14059) Replace EasyMock and PowerMock with Mockito in WorkerSourceTaskTest

[Hector Geraldino (Jira)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-14059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hector Geraldino reassigned KAFKA-14059:


Assignee: Hector Geraldino

> Replace EasyMock and PowerMock with Mockito in WorkerSourceTaskTest
> ---
>
> Key: KAFKA-14059
> URL: https://issues.apache.org/jira/browse/KAFKA-14059
> Project: Kafka
>  Issue Type: Sub-task
>  Components: KafkaConnect
>Reporter: Chris Egerton
>Assignee: Hector Geraldino
>Priority: Minor
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: solution to / full

[Richard Hector]

On 2/03/23 06:00, Andy Smith wrote:

Hi,

On Wed, Mar 01, 2023 at 02:35:17PM +0100, lina wrote:

My / is almost full.

# df -h
Filesystem  Size  Used Avail Use% Mounted on
udev126G 0  126G   0% /dev
tmpfs26G  2.3M   26G   1% /run
/dev/nvme0n1p2   23G   21G  966M  96% /
tmpfs   126G   15M  126G   1% /dev/shm
tmpfs   5.0M  4.0K  5.0M   1% /run/lock
/dev/nvme0n1p6  267M   83M  166M  34% /boot
/dev/nvme0n1p1  511M  5.8M  506M   2% /boot/efi
/dev/nvme0n1p3  9.1G  3.2G  5.5G  37% /var
/dev/nvme0n1p5  1.8G   14M  1.7G   1% /tmp
/dev/nvme0n1p7  630G  116G  482G  20% /home


This is an excellent illustration of why creating tons of partitions
like it's 1999 can leave you in a difficult spot. You are bound to
make poor guesses as to what actual size you need, which leads later
situations where some partitions are hardly used while others get
full.


Of course you can also get into this situation if you had everything in 
one filesystem, and ran out of space, and had to split off /home, /var 
etc to save room ...


Richard

Re: [Koha] cron problem with automatic_checkin after update to 22.05

[Hector Gonzalez Jaime]

Thank you, the script found a lot of those.

On 3/1/23 03:44, Jonathan Druart wrote:
Make sure you have an item type for all your items. There is a script 
that can help you to catch them: 
misc/maintenance/search_for_data_inconsistencies.pl 
<http://search_for_data_inconsistencies.pl>


Le mar. 28 févr. 2023 à 22:36, Hector Gonzalez Jaime  
a écrit :


Hi, we recently updated our system to 22.05 and since then we
receive this error from cron:

/etc/cron.hourly/koha-common:
Can't call method "automatic_checkin" on an undefined value at
/usr/share/koha/lib/Koha/Checkouts.pm line 85.
kamoxtin: 11 status returned by
"/usr/share/koha/bin/cronjobs/automatic_checkin.pl
<http://automatic_checkin.pl>"

both files seem to be up to date.  Is this a known issue?  I can't
find any reference to it or reported bugs.

-- 
Hector Gonzalez

ca...@genac.org

___

Koha mailing list http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha


--
Hector Gonzalez
ca...@genac.org

___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

[Koha] cron problem with automatic_checkin after update to 22.05

[Hector Gonzalez Jaime]

Hi, we recently updated our system to 22.05 and since then we receive this 
error from cron:

/etc/cron.hourly/koha-common:
Can't call method "automatic_checkin" on an undefined value at 
/usr/share/koha/lib/Koha/Checkouts.pm line 85.
kamoxtin: 11 status returned by 
"/usr/share/koha/bin/cronjobs/automatic_checkin.pl"

both files seem to be up to date.  Is this a known issue?  I can't find any 
reference to it or reported bugs.

--
Hector Gonzalez
ca...@genac.org

___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

PostgreSQL optimizations for CoW FS

[HECTOR INGERTO]

Let’s say we have to run a PostgreSQL instance on top of a copy on write 
filesystem like ZFS or BTRFS. In adittion to set full_page_writes = off, what 
other optimizations can be done on the PostgreSQL side?

Regards,


Héctor

Re: [OS-BUILD PATCHv3] aarch64: enable zboot

[Hector Martin (via Email Bridge)]

From: Hector Martin on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2283#note_1277275063

I haven't tested it but I don't see why it wouldn't work.
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Non-Determinism in Table-API with Kafka and Event Time

[Hector Rios]

Hi Theo

In your initial email, you mentioned that you have "a bit of Data on it"
when referring to your topic with ten partitions. Correct me if I'm wrong,
but that sounds like the data in your topic is bounded and trying to test a
streaming use-case. What kind of parallelism do you have configured for
this job? Is there a configuration to set the number of slots per task
manager?

I've seen varying results based on the amount of parallelism configured on
a job. In the end, it usually boils down to the fact that events might be
ingested into Flink out of order. If the event time on an event is earlier
than the current watermark, then the event might be discarded unless you've
configured some level of out-of-orderedness. Even with out-of-orderedness
configured, if your data is bounded, you might have events with later event
times arriving earlier, which will remain in the state waiting for the
watermark to progress. As you can imagine, if there are no more events,
then your records are on hold.

As a test, after all, your events have been ingested from the topic, try
producing one last event with an event time one or 2 hours later than your
latest event and see if they show up.

Hope it helps
-Hector

On Mon, Feb 13, 2023 at 8:47 AM Theodor Wübker 
wrote:

> Hey,
>
> so one more thing, the query looks like this:
>
> SELECT window_start, window_end, a, b, c, count(*) as x FROM 
> TABLE(TUMBLE(TABLE
> data.v1, DESCRIPTOR(timeStampData), INTERVAL '1' HOUR)) GROUP BY
> window_start, window_end, a, b, c
>
> When the non-determinism occurs, the topic is not keyed at all. When I key
> it by the attribute “a”, I get the incorrect, but deterministic results.
> Maybe in the second case, only 1 partition out of the 10 is consumed at
> once?
>
> Best,
> Theo
>
> On 13. Feb 2023, at 08:15, Theodor Wübker 
> wrote
>
> Hey Yuxia,
>
> thanks for your response. I figured too, that the events arrive in a
> (somewhat) random order and thus cause non-determinism. I used a
> Watermark like this:"timeStampData - INTERVAL '10' SECOND*”* . Increasing
> the Watermark Interval does not solve the problem though, the results are
> still not deterministic. Instead I keyed the 10 partition topic. Now
> results are deterministic, but they are incorrect (way too few). Am I doing
> something fundamentally wrong? I just need the messages to be in somewhat
> in order (just so they don’t violate the watermark).
>
> Best,
> Theo
>
> (sent again, sorry, I previously only responded to you, not the Mailing
> list by accident)
>
> On 13. Feb 2023, at 08:14, Theodor Wübker 
> wrote:
>
> Hey Yuxia,
>
> thanks for your response. I figured too, that the events arrive in a
> (somewhat) random order and thus cause non-determinism. I used a
> Watermark like this: "timeStampData - INTERVAL '10' SECOND*”* .
> Increasing the Watermark Interval does not solve the problem though, the
> results are still not deterministic. Instead I keyed the 10 partition
> topic. Now results are deterministic, but they are incorrect (way too few).
> Am I doing something fundamentally wrong? I just need the messages to be in
> somewhat in order (just so they don’t violate the watermark).
>
> Best,
> Theo
>
> On 13. Feb 2023, at 04:23, yuxia  wrote:
>
> HI, Theo.
> I'm wondering what the Event-Time-Windowed Query you are using looks like.
> For example, how do you define the watermark?
> Considering you read records from the 10 partitions, and it may well that
> the records will arrive the window process operator out of order.
> Is it possible that the records exceed the watermark, but there're still
> some records will arrive?
>
> If that's the case, every time, the records used to calculate result may
> well different and then result in non-determinism result.
>
> Best regards,
> Yuxia
>
> - 原始邮件 -
> 发件人: "Theodor Wübker" 
> 收件人: "User" 
> 发送时间: 星期日, 2023年 2 月 12日 下午 4:25:45
> 主题: Non-Determinism in Table-API with Kafka and Event Time
>
> Hey everyone,
>
> I experience non-determinism in my Table API Program at the moment and (as
> a relatively unexperienced Flink and Kafka user) I can’t really explain to
> myself why it happens. So, I have a topic with 10 Partitions and a bit of
> Data on it. Now I run a simple SELECT * query on this, that moves some
> attributes around and writes everything on another topic with 10
> partitions. Then, on this topic I run a Event-Time-Windowed Query. Now I
> experience Non-Determinism: The results of the windowed query differ with
> every execution.
> I thought this might be, because the SELECT query wrote the data to the
> partitioned topic without keys. So I tried it again with the same key I
> used for the or

Bug#1029814: ixp4xx-microcode: no longer useful, ixp4xx support dropped in 2014

[Hector Oron]

Hello,

  This firmware was used by slugs or NSLU-2,
  https://www.cyrius.com/debian/nslu2/install/

  Those devices were great to bootstrap and play with armel port.

  Due to low ram and flash it is no longer capable to run Debian. Therefore
I agree this package can be marked for removal.

  Userland package was removed time ago:
  https://tracker.debian.org/pkg/nslu2-utils

Regards