[Ietf-dkim] Re: [Dcrup] [standards] [Editorial Errata Reported] RFC8463 (7930)

[Hector Santos]

> 
> |Because that's not actually accurate, due to the inclusion of the digest
> |OID in the signature payload in the "single" primitive.
> 
> ...but the above says "two hashes".  But despite that.
> An Ed25519 sign operation alone creates three SHA-512 digests
> which are incorporated into several further calculations.  Whereas
> for RSA it is, to the best of my knowledge, crucial to let it pass
> over as few bytes as possible (for encryption as such i think
> OpenSSL will refuse to do so after a certain limit), for EC with
> its embedded digests it may be more expensive but even beneficial
> to push more data rounds onto the embedded digests.
> So maybe, and in hindsight to the RFC that i would try to publish
> in fall if i am allowed to and if the email giants still have not
> moved towards this RFC 8463, it might make sense to adjust the
> data-hash in that it may come from hash-alg or be included via
> sig-alg.
> 
> --steffen

I don’t wish to oversimplify here,  but I wonder if the confusion is with the 
idea that in order to support RFC8463, a complaint implementation would have to 
sign two DKIM signatures for backward compatibility.   One DKIM signature using 
SHA256 and a second signature using Ed25519. 

No one will support exclusively Ed25519 unless dealing with highly direct 1 to 
1 comm I/O with a permission-based system. In other words, supporting this 
crypto enhancement requires a high overhead of two signatures, The ignorant 
RFC8463 system (the majority) is not ready for this. One SHA256 signature is 
sufficient,  I would not Ed25519 provides smaller keys that are more supportive 
by DNS Zone Managers. 

All the best,
Hector Santos




___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org

[dmarc-ietf] Re: WG Action: Formed Mail Maintenance (mailmaint)

[Hector Santos]

Thanks.  I am subscribed.   Based on the written charter, is re-introducing 
then ESMTP add-on,

https://datatracker.ietf.org/doc/html/draft-santos-smtpgrey-02
Reasonable?  Many years of operation, the ultimate two questions are:

1) Do greylistng servers support responses to drive greylisted clients? and
2) Do rermote clients honor the advanced response for Retry Times?

The above is an example only.  Another is ATPS re-introduction for a 
DMARC-based world.



All the best,
Hector Santos



> On May 10, 2024, at 1:53 PM, Murray S. Kucherawy  wrote:
> 
> FYI
> 
> -- Forwarded message -
> From: IESG Secretary  <mailto:iesg-secret...@ietf.org>>
> Date: Thu, May 9, 2024 at 1:01 PM
> Subject: WG Action: Formed Mail Maintenance (mailmaint)
> To: IETF Announcement List  <mailto:ietf-annou...@ietf.org>>
> Cc: mailto:i...@ietf.org>>,  <mailto:mailmaint-cha...@ietf.org>>,  <mailto:mailma...@ietf.org>>
> 
> 
> A new IETF WG has been formed in the Applications and Real-Time Area. For
> additional information, please contact the Area Directors or the WG Chair.
> 
> Mail Maintenance (mailmaint)
> ---
> Current status: Proposed WG
> 
> Chairs:
>   Kenneth Murchison mailto:mu...@fastmail.com>>
> 
> Assigned Area Director:
>   Murray Kucherawy mailto:superu...@gmail.com>>
> 
> Applications and Real-Time Area Directors:
>   Murray Kucherawy mailto:superu...@gmail.com>>
>   Orie Steele 
> 
> Mailing list:
>   Address: mailma...@ietf.org <mailto:mailma...@ietf.org>
>   To subscribe: https://www.ietf.org/mailman/listinfo/mailmaint
>   Archive: https://mailarchive.ietf.org/arch/browse/mailmaint/
> 
> Group page: https://datatracker.ietf.org/group/mailmaint/
> 
> Charter: https://datatracker.ietf.org/doc/charter-ietf-mailmaint/
> 
> Internet Messaging (“email”) is one of the oldest applications still
> supported by the IETF.  It consists of numerous layers and extensions that
> support the robust construction, transport, retrieval, and interpretation of
> messages.
> 
> (For the purposes of this charter, “email” starts in RFC 5321 which covers
> transport and RFC 5322 which covers message format, and extends into
> specifications based on those documents and their antecedents.  It also
> includes related protocols such as IMAP [RFC 9051] and JMAP [RFC 8620, et
> seq].)
> 
> >From time to time, new work in the email space is brought to the IETF for
> consideration and development.  Where there is enough critical mass to create
> a working group to develop and publish the work, this is the preferred case. 
> More often, however, a proposal is brought that lacks enough critical mass to
> independently support chartering of a working group, but would still be
> useful to publish as a standard.  Such projects must then either seek the
> assent of an Area Director willing to sponsor it as a standards track
> document, or support via the Independent Stream Editor (ISE) without
> standards track status.
> 
> The MAILMAINT (“Mail Maintenance”) working group will consider projects in
> the email space that are too small to warrant construction of a dedicated
> working group.  This will take advantage of a common community to consider
> these proposals rather than forming a series of disparate but related
> communities.
> 
> Work proposed for MAILMAINT may arrive via direct proposals, or it may be
> referred via one or more DISPATCH-style working groups.  Recorded Calls for
> Adoption are required for all work proposals.
> 
> Proponents of work that is not taken up within the IETF may, of course,
> decide to bring their proposal to the Independent Stream.  The working group
> should discuss such proposals with the ISE and share the results of the
> working group’s consideration.
> 
> Further, MAILMAINT will observe the following constraints when considering
> the adoption of new work directly:
> 
> * Prior to accepting any Standards Track document for development, there must
> be a commitment to implement the resulting proposed standard from at least
> two independent parties, as recorded on a related IETF mailing list.
> 
> * When deciding to send any Standards Track work to the IESG, there must
> first be produced a report documenting at least two (preferably more)
> independent implementations with at least partial interoperation based on the
> developed specification.
> 
> * The above constraints do not apply to documents that are not intended for
> the Standards Track.
> 
> * Chartering of a dedicated working group with a custom charter is strongly
> preferred when engaging any work that updates any base email do

Re: [dmarc-ietf] There is no pony, Overall last-call comments on DMARC

[Hector Santos]

My overall assessment as an early adopter and implementation:



DMARC SHOULD NOT be declared a Standard Track document.  We still have the 
potential to develop a sound 1st, 3rd party DKIM Policy model. Declaring 
DMARCBis a STD will only hamper future development.  Keep it experimental or 
informational. DMARC/Bis has represented a big IETF “Elephant In The Room” 
change in allowing External 3rd Party Organizations to put barriers of entry to 
correct the IETF protocol development.. 

Change is needed.  DMARCBis is not it. Is there is an Update Document minus the 
subjectives considerations.   It has been a fair process but a very high hurdle 
to correct a serious IETF protocol problem.



All the best,
Hector Santos



> On Apr 4, 2024, at 4:47 PM, Jim Fenton  wrote:
> 
> On 4 Apr 2024, at 13:31, John R. Levine wrote:
> 
>>> I don’t think it’s scope creep at all. The WG charter puts “Review and 
>>> refinement of the DMARC specification” in phase III, after “Specification 
>>> of DMARC improvements to support indirect mail flows”. It seems clear to me 
>>> that standards-track DMARC needs to incorporate those improvements.
>>> 
>>> IESG accepted ARC as an improvement to support indirect mail flows, and I 
>>> think a complete solution needs to incorporate that. I wish there were 
>>> better data to support advancing ARC to standards track, and not just from 
>>> Google (it has to work for smaller players as well).
>>> 
>>> But I am troubled by the possibility that ARC might require domain 
>>> reputation to avoid ARC header fields supporting From address spoofing. One 
>>> reason it might work for Google is because they’re big enough to derive 
>>> their own domain reputation. We’ve not had success with domain reputation 
>>> at internet scale.
>> 
>> No might about it -- ARC is only useful with domain reputation. Of course, 
>> DKIM is only useful with domain reputation, as were Domainkeys and IIM, so I 
>> don't see why it's a problem now.
> 
> Much of the objective of DomainKeys/IIM/DKIM was to provide a reliable domain 
> identifier that could be used by a reputation system. They avoided saying 
> that they were doing anything about spam and phishing. OTOH, DMARC is 
> explicitly saying that it’s there to do something about phishing.
> 
>> We've been going around and around for years now.  DMARC works pretty well 
>> for direct mail flows, so-so for simple indirect flows (forwarders) and 
>> really badly for mediated indirect flows (mailing lists.)  There is nothing 
>> better than ARC to mitigate those problems and this WG certainly isn't going 
>> to invent anything now.  I agree that at this point we don't have enough 
>> evidence to advance ARC, so we can punt the question of what or when to do 
>> with it to MAILMAINT or something.
>> 
>> Our choices are to say here's what DMARC does, it has these problems, here's 
>> how to use it for the situations where it works, here's how to sort of 
>> mitigate the ones where it doesn't.  Or we can stamp our feet and say DMARC 
>> is BAD and we will not endorse it and NOBODY should use it, and the rest of 
>> the mail world will say isn't that cute, the IETF is having a tantrum.
> 
> Or we can say that it’s not ready for standards track yet. The only time I 
> can think of in this space that we have stamped our feet and said something 
> is BAD was with ADSP. But I am troubled by the mandatory requirements imposed 
> by organizations citing an informational RFC, RFC 7489. It makes it seem like 
> standards track doesn’t mean as much as it should.
> 
> -Jim
> 
> ___
> 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: [Ietf-dkim] Testing a DKIM implementation

[Hector Santos]

On 3/22/2024 8:25 AM, David Harris wrote:

My thanks to Murray S. Kucherawy, who was most helpful in answering my
previous questions about specifics of RFC6376..

I now have my implementation complete: I was wondering if there is a
recommended way of testing it - for instance, a reference site that allows you
to send messages and then replies with information about the correctness of
your implementation, or an application that can generate signatures for data
you supply, showing its work product (the various hashes and canonicalized
forms) so you can compare it with your own.

Any pointers would be appreciated.

Thanks in advance for any assistance.


There are number of verifiers.   One such address is 
dkim-autoresp...@isdg.net will verify your DKIM signatures and apply 
DKIM Policies such as ADSP (deprecated), DMARC and report the result.


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






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

Re: [dmarc-ietf] DMARC exceptions

[Hector Santos]

Doug,  since of dawn of electronic messaging, a system local policy always 
prevails. When implementing the new SMTP filters such as SPF, the more powerful 
policy was one of detecting failure. The PASS meant nothing since it may not 
pre-empt any other checking.  For us, wcSPF was the exception in the wcSMTP 
suites of filters out of the box:

- Low Code Reject/Access rules
- DNS-RBL 
- SPF
- CBV

SPF would pre-empt the final CBV check for a matching source (pass).  An SPF 
Hard Fail is an immediate 550 rejection response.   A unknown continues with 
the CBV check.

When it comes to DKIM, we calculate all the valid signatures.

When it comes to a DKIM Policy Model - well, we have DMARC.   We apply the 
protocol rules without exceptions.  If a Local System does not honor the 
results for any reason, that is ok.  But I don’t think it can define a 
consistent Local Policy OverRide and expect systems to use same local 
overrides.  

Again, my Philosophy has been Failure Detection as the key filtering strength 
for all the DKIM Policies explored.  A PASS or worst unknown/neutral means 
nothing because good and bad can both apply.  Another “Trust” Layer is 
considered at the local level.   


All the best,
Hector Santos



> On Mar 15, 2024, at 1:46 AM, Douglas Foster 
>  wrote:
> 
> DMARC is an imperfect tool, as evidenced by the mailing list problem, among 
> others.  DMARCbis has failed to integrate RFC7489 with RFC 7960, because it 
> provides no discussion of the circumstances where an evaluator should 
> override the DMARC result.  I believe DMARCbis needs a discussion about the 
> appropriate scope and characteristics of local policy.  I have developed an 
> initial draft of proposed language for that section, which appears below
> 
> Doug Foster
> 
> 
> x. Exceptions / Local Policy
> 
> A DMARC disposition policy communicates the domain owner’s recommendation for 
> handling of messages which fail to authenticate. By definition, this 
> recommendation cannot take into consideration the local interest of specific 
> receivers, or the specific flow path of any specific message.   As a result, 
> evaluators should anticipate the need to implement local policy exceptions 
> that override the DMARC recommended disposition when appropriate.   These 
> exceptions can be considered in two groups:   policy overrides and 
> authentication overrides.   This section discusses some expected override 
> scenarios, without intending to be comprehensive, so that product 
> implementers can create appropriate exception structures for these and 
> similar possible situations.
> 
> x.1 Policy Overrides
> 
> x.1.1 Override p=none
> 
> A disposition policy of “none” indicates that the domain owner suspects that 
> some evaluators may receive some legitimate and wanted messages which lack 
> authentication when received.   The evaluator may reasonably conclude that 
> its risk of allowing a message which maliciously impersonates the domain is 
> much greater than the risk of hindering a legitimate-but-unauthenticated 
> message from the domain.   In such cases, the local policy will override 
> p=none and handle the domain with p=quarantine or p=reject.
> 
> x.1.2 Override missing PSL=Y
> 
> Some PSDs have implemented DMARC policies in accordance with RFC 9901, 
> without a PSL tag because that RFC assumed that organizational domain 
> determination would be provided by the PSL.   Particularly during the early 
> rollout of this specification, evaluators should use the PSL to identify 
> DMARC policies which are intended to be treated as PSL=Y even though the 
> PSD’s policy has not yet been updated to include the PSD=Y tag.
> 
> x.1.3 Override strict alignment
> 
> A domain may publish aspf=s or adkim=s incorrectly, which the evaluator will 
> detect when legitimate and wanted messages produce a DMARC Fail result, even 
> though they would produce Pass using relaxed alignment.   In this case, the 
> evaluator overrides the strict alignment rules in the published policy and 
> applies a local policy of relaxed alignment.
> 
> x.2 Authentication Overrides
> 
> An Authentication Override provides alternate authentication when a message 
> is acceptable but the DMARC algorithm produces a result of Fail.   To ensure 
> that the exception does not create a vulnerability, the rule should include 
> at least one verified identifier with a value that indicates the trusted 
> message source, often coupled with unverified identifiers with specific 
> values the further narrow scope of the rule.
> 
> x.2.1 Mailing List messages
> 
> Mailing Lists typically add content to the Subject or Body, and replace the 
> Mail From address, while forwarding a message.   As a result, the 
> RFC5322.From address of the author can no 

Re: [dmarc-ietf] DMARCbis WGLC Issue 132 - 5.5.1 and 5.5.2 SHOULD vs MUST (was Another point for SPF advice)

[Hector Santos]

> On Mar 14, 2024, at 4:02 PM, Todd Herr 
>  wrote:
> 
> On Thu, Mar 14, 2024 at 3:25 PM Hector Santos 
> mailto:40isdg@dmarc.ietf.org>> wrote:
>>> On Mar 14, 2024, at 10:09 AM, Todd Herr 
>>> >> <mailto:40valimail@dmarc.ietf.org>> wrote:
>>> To configure SPF for DMARC, the Domain Owner MUST choose a domain to use as 
>>> the RFC5321.MailFrom domain (i.e., the Return-Path domain) for its mail 
>>> that aligns with the Author Domain, and then publish an SPF policy in DNS 
>>> for that domain. The SPF record MUST be constructed at a minimum to ensure 
>>> an SPF pass verdict for all known sources of mail for the RFC5321.MailFrom 
>>> domain.
>> 
>> A major consideration, Todd, is receivers will process SPF for SPF without 
>> DMARC (payload) considerations.  IOW, if SPF is a hardfail, we have SMTP 
>> processors who will not continue to transmit a payload (DATA).
>> 
>> DMARCBis is making a major design presumption receivers will only use SPF as 
>> a data point for a final DMARC evaluation where a potentially high overhead 
>> payload was transmitted only to be rejected anyway,  
> 
> I don't necessarily think your assertion is true here, or at least I'd submit 
> that DMARCbis and RFC 7489 aren't approaching this subject any differently.
> 
> Section 10.1 from RFC 7489, titled "Issues Specific to SPF" had two 
> paragraphs, the second of which reads:
> 
>Some receiver architectures might implement SPF in advance of any
>DMARC operations.  This means that a "-" prefix on a sender's SPF
>mechanism, such as "-all", could cause that rejection to go into
>effect early in handling, causing message rejection before any DMARC
>processing takes place.  Operators choosing to use "-all" should be
>aware of this.

Yes, I agree.  I am only reminding the community SPF can preempt DMARC with a 
restrictive hardfail policy.   Does DMARCBis integrate the tag to delay SPF 
failures?


> 
> DMARCbis contains the same two paragraphs with no change to the text, other 
> than the section is now numbered 8.1.
> 
>> 
>>> In the ticket, I propose the following new text:
>>> 
>>> ==
>>> To configure DKIM for DMARC, the Domain Owner MUST choose a DKIM-Signing 
>>> domain (i.e., the d= domain in the DKIM-Signature header) that aligns with 
>>> the Author Domain.
>>> ==
>> 
>> In order to maximize security, the Domain Owner is REQUIRED to choose a ….. 
>> 
>> Is REQUIRED the same as MUST?   I think SHOULD or MUST is fine as long as we 
>> specify the reason it is required,
> 
> I'm not understanding the comment you're making here, as I don't see the word 
> "REQUIRED" in anything I wrote.

For any protocol, there are “Protocol Requirements,”   A MUST or SHOULD is a 
“Requirement” for proper support,  So I just wanted to just note that it can 
stated another way.  Developers need a Requirements Section that allow us to 
code the logic,

Its getting pretty confusing for implementors.

—
HLS

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

Re: [dmarc-ietf] DMARCbis WGLC Issue 132 - 5.5.1 and 5.5.2 SHOULD vs MUST (was Another point for SPF advice)

[Hector Santos]

> On Mar 14, 2024, at 10:09 AM, Todd Herr 
>  wrote:
> 
> 
> In the ticket, I propose the following replacement text:
> 
> ==
> Because DMARC relies on SPF [[RFC7208]] and DKIM [[RFC6376], in order to take 
> full advantage of DMARC, a Domain Owner MUST first ensure that either SPF or 
> DKIM authentication are properly configured, and SHOULD ensure that both are.

+1

> 
> To configure SPF for DMARC, the Domain Owner MUST choose a domain to use as 
> the RFC5321.MailFrom domain (i.e., the Return-Path domain) for its mail that 
> aligns with the Author Domain, and then publish an SPF policy in DNS for that 
> domain. The SPF record MUST be constructed at a minimum to ensure an SPF pass 
> verdict for all known sources of mail for the RFC5321.MailFrom domain.

A major consideration, Todd, is receivers will process SPF for SPF without 
DMARC (payload) considerations.  IOW, if SPF is a hardfail, we have SMTP 
processors who will not continue to transmit a payload (DATA).

DMARCBis is making a major design presumption receivers will only use SPF as a 
data point for a final DMARC evaluation where a potentially high overhead 
payload was transmitted only to be rejected anyway,  

> In the ticket, I propose the following new text:
> 
> ==
> To configure DKIM for DMARC, the Domain Owner MUST choose a DKIM-Signing 
> domain (i.e., the d= domain in the DKIM-Signature header) that aligns with 
> the Author Domain.
> ==

In order to maximize security, the Domain Owner is REQUIRED to choose a ….. 

Is REQUIRED the same as MUST?   I think SHOULD or MUST is fine as long as we 
specify the reason it is required,

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

Re: [dmarc-ietf] A.5 Issues with ADSP in Operation

[Hector Santos]

> On Mar 9, 2024, at 10:05 AM, Alessandro Vesely  wrote:
> 
> Hi,
> 
> as ADSP is historical, perhaps we can strike A5 entirely.  If not, we should 
> at least eliminate bullet 5:
> 
>   5.  ADSP has no support for a slow rollout, i.e., no way to configure
>   a percentage of email on which the Mail Receiver should apply the
>   policy.  This is important for large-volume senders.
> 
> (Alternatively, we could think back about pct=...?)
> 
> 

If anything, DMARCBis should assist (provide guidance) with ADSP to DMARC 
migration considerations.

There are still folks who don’t believe in DMARC and continue to have an ADSP.  
  ADSP has two basic policies: DISCARDABLE and ALL.

ALL means lways signed by anyone. DISCARDABLE means always signed by the Author 
Domain,

DMARCbis continues to use the term “Super ADSP” in section A5.  We may be 
beyond justifications of why DMARC replaced ADSP.   Help with migration would 
be useful.

While an ADSP DISCARD policy may translate to a DMARC p=reject, an ADSP ALL 
policy may not have any DMARC equivalent unless non-alignment was a defined 
policy (in DMARC) - I don’t there is.

All the best,
Hector Santos

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

Re: [dmarc-ietf] Inconsistencies in DMARC Aggregate Report XML Schema

[Hector Santos]

> On Mar 11, 2024, at 10:33 PM, Neil Anuskiewicz 
>  wrote:
> 
> Wow, the stat on how many domain operators move to enforcing reject policy 
> sans aggregate reports shocked me. Trust the force, Luke.

It should not be a surprise the client/server protocol concept of “email 
reporting” was always and I still believe is considered a taboo as it can be a 
form of abuse when not negotiated, requested or solicited. It is an 100% 
optional feature to provide a reporting address.

With DMARC policy publishing, for exploratory reasons only, I have reports sent 
to an email to newsgroup forum where I can privately review and so far, it has 
not provided any benefit beyond what is expected.  I have advocated for a 
straight text report but I probably have to write a translator. The current 
format expects JSON/XML readers. 

 Our wcDMARC verification processor does not have built-in support for 
reporting. 


All the best,
Hector Santos


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

Re: [dmarc-ietf] Another point for SPF advice

[Hector Santos]

I believe it is correct, SHOULD strive to trusted known sources.  The final 
mechanism SHOULD be one of (hard) failure.  This is what we (ideally) strive 
for.  I believe anything weaker is a waste of computational resources, causes 
confusion using neutral or even soft fails especially with repeated 
transactions. 

All the best,
Hector Santos



> On Mar 5, 2024, at 9:29 AM, Alessandro Vesely  wrote:
> 
> Hi,
> 
> in section 5.5.1, Publish an SPF Policy for an Aligned Domain, the last 
> sentence says:
> 
>   The SPF record SHOULD be constructed
>   at a minimum to ensure an SPF pass verdict for all known sources of
>   mail for the RFC5321.MailFrom domain.
> 
> As we learnt, an SPF pass verdict has to be granted to /trusted/ sources 
> only.  An additional phrase about using the neutral qualifier ("?") for 
> public sources might also be added.
> 
> 
> Best
> Ale
> --
> 
> ___
> 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] The sad state of SPF: research just presented at NDSS

[Hector Santos]

> On Feb 28, 2024, at 6:33 PM, Barry Leiba  wrote:
> 
> A paper was presented this morning at NDSS about the state of SPF, which is 
> worth a read by this group:
> 
> https://www.ndss-symposium.org/ndss-paper/breakspf-how-shared-infrastructures-magnify-spf-vulnerabilities-across-the-internet/
> 


Barry, Interesting.  Appreciate the security note.

Per document, 2.39% domains are the problem with CDN, HTTP Proxy, SMTP threat 
entry points.  Not an SPF issue.   If anything, add more SMTP command override 
support for immediate disconnect for GET, POST, etc, erroneous SMTP commands:

// Script:  Smtpfilter-GET.wcc:

// add code to block GetCalllerID()
Print “550 ”
HangUp()
End

// Script:  Smtpfilter-POST.wcc:

// add code to block GetCalllerID()
Print “550 ”
HangUp()
End


All the best,
Hector Santos

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

Re: [dmarc-ietf] DMARCbis WGLC Significant(ish) Issue - Section 7.6

[Hector Santos]

No rehashing, my technical opinion, clearly the semantics but both lead to:

“You SHOULD|MUST consider the documented conflicts before using the restricted 
policy p=reject”

Question. Is p=quarantine ok to use?  Or do we presume p=reject implies 
p=quarantine?’'



All the best,
Hector Santos



> On Feb 29, 2024, at 2:53 PM, Seth Blank  
> wrote:
> 
> I thought we landed on SHOULD NOT, there was strong resistance to MUST NOT
> 
> On Thu, Feb 29, 2024 at 2:48 PM Scott Kitterman  <mailto:skl...@kitterman.com>> wrote:
>> Okay.  I think 8.6 is the one in error.  You see how this is going to go, 
>> right?
>> 
>> Scott K
>> 
>> On February 29, 2024 7:45:15 PM UTC, Todd Herr 
>> > <mailto:40valimail@dmarc.ietf.org>> wrote:
>> >It is not my intent here to relitigate any issues.
>> >
>> >Rather, I believe that the text in 7.6 is wrong, likely due to an oversight
>> >on my part when the new text in 8.6 was published, and I just want to
>> >confirm that 7.6 is indeed wrong.
>> >
>> >On Thu, Feb 29, 2024 at 2:10 PM Scott Kitterman > ><mailto:skl...@kitterman.com>>
>> >wrote:
>> >
>> >> In what way is this a new issue that has not already been argued to death
>> >> in the WG?  I think for WGLC, we've already done this. We will, no doubt
>> >> get to have this conversation during the IETF last call, but for the
>> >> working group, this strikes me as exactly the type of relitigation of
>> >> issues we've been counseled to avoid.
>> >>
>> >> Scott K
>> >>
>> >> On February 29, 2024 6:54:57 PM UTC, Todd Herr > >> 40valimail@dmarc.ietf.org <mailto:40valimail@dmarc.ietf.org>> 
>> >> wrote:
>> >> >Colleagues,
>> >> >
>> >> >I've been reading DMARCbic rev -30 today with a plan to collect the first
>> >> >set of minor edits and I came across a sentence that I believe goes 
>> >> >beyond
>> >> >minor, so wanted to get a sanity check.
>> >> >
>> >> >Section 7.6, Domain Owner Actions, ends with the following sentence:
>> >> >
>> >> >In particular, this document makes explicit that domains for
>> >> >general-purpose email MUST NOT deploy a DMARC policy of p=reject.
>> >> >
>> >> >
>> >> >I don't believe this to be true, however. Rather, Section 8.6,
>> >> >Interoperability Considerations, says SHOULD NOT on the topic (e.g., "It
>> >> is
>> >> >therefore critical that domains that host users who might post messages 
>> >> >to
>> >> >mailing lists SHOULD NOT publish p=reject")
>> >> >
>> >> >Section 7.6 therefore should be updated to read "domains for
>> >> >general-purpose email SHOULD NOT deploy a DMARC policy of p=reject", yes?
>> >> >
>> >>
>> >> ___
>> >> dmarc mailing list
>> >> dmarc@ietf.org <mailto:dmarc@ietf.org>
>> >> https://www.ietf.org/mailman/listinfo/dmarc
>> >>
>> >
>> >
>> 
>> ___
>> dmarc mailing list
>> dmarc@ietf.org <mailto:dmarc@ietf.org>
>> https://www.ietf.org/mailman/listinfo/dmarc
> 
> 
> --
> Seth Blank  | Chief Technology Officer
> e: s...@valimail.com <mailto:s...@valimail.com>
> p:
> 
> 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] dmarc-dmarcbis: add "req=dkim"

[Hector Santos]

+1

With 5617 was the DKIM=ALL policy -  anyone can sign.  Offered no authorization 
protection.

dkim=discardable  offers 1st party signaing protection — just like DMARC offers.

Both failed in validating the 3rd party signer.


All the best,
Hector Santos



> On Feb 8, 2024, at 11:26 AM, Jim Fenton  wrote:
> 
> On 6 Feb 2024, at 14:47, Murray S. Kucherawy wrote:
> 
>> On Tue, Feb 6, 2024 at 2:33 AM Jeroen Massar > 40massar...@dmarc.ietf.org> wrote:
>> 
>>> `req=dkim`: requires DKIM, messages not properly signed are then to be
>>> rejected/quarantined based on 'p' policy.
>>> 
>> 
>> This sounds like what RFC 5617 tried to do, minus the constraint that the
>> signing domain be equal to the author domain, which is one of the key
>> pieces of DMARC.  Isn't this a pretty big scope expansion?
> 
> For the record, RFC 5617 did constrain the signing domain to be the author 
> domain. From Sec. 2.7:
> 
>> An "Author Domain Signature" is a Valid Signature in which the domain name 
>> of the DKIM signing entity, i.e., the d= tag in the DKIM-Signature header 
>> field, is the same as the domain name in the Author Address.
> 
> -Jim
> 
> ___
> 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: [Ietf-dkim] Headers that should not be automatically oversigned in a DKIM signature?

[Hector Santos]

Whoa!  I wondered about that!! Lock Icon was gone and it’s not a “switch” 
indication “options” icon.

You know, a good bit of the time is a programmer getting excited with a new UI 
API and switches to it!!  Imo, there was no need for that change,  Everything 
in the options was 100% about security and privacy related.  So what if the 
laymen didn’t know what it was. The default is set for unsecured 
communications. Focus on that, the secured defaults. The 10-20% experts that 
did know this intuitively with the lock icon was did not have an issue. 
Sometimes the first inclination is the best.  Go with your GUTS.  Always works 
in the long term.


All the best,
Hector Santos



> On Feb 5, 2024, at 8:50 PM, Dave Crocker  wrote:
> Om
> On 2/5/2024 2:08 PM, Jim Fenton wrote:
>> On 5 Feb 2024, at 14:02, Dave Crocker wrote:
>>> On 2/5/2024 1:56 PM, Jim Fenton wrote:
>>>> And you will also provide citations to refereed research about what you 
>>>> just asserted as well, yes?
>>> Ahh, you want me to prove the negative. That's not exactly how these things 
>>> go.
>> You said that the URL lock symbol failed. Asking for research to back that 
>> up is not asking for you to prove the negative. 
> 
> Ahh.  Defending by attacking.  Nice.
> 
> But actually, given what I said, yes it is being asked to prove the negative. 
>  
> 
> I said it's been a failure. Failure means that after many years, it has not 
> been a success.  Were the symbol successful, we'd see reductions in user 
> understanding, awareness and resistance abuse.  
> 
> Do we have serious data that it has been?  If so, where is it?  Do we even 
> have an anecdotal sense of widespread utility?  I think not.
> 
> But wait.  There's more...
> 
> All of the following are strong indicators of failure:
> 
> "In our study, we asked a cross-section 
> <https://techxplore.com/tags/cross+section/> of 528 web users 
> <https://techxplore.com/tags/web+users/>, aged between 18 and 86 years of 
> age, a number of questions about the internet. Some 53% of them held a 
> bachelor's degree or above and 22% had a college certificate, while the 
> remainder had no further education.
> 
> One of our questions was, "On the Google Chrome browser bar, do you know what 
> the padlock icon represents/means?"
> 
> Of the 463 who responded, 63% stated they knew, or thought they knew, what 
> the padlock symbol on their web browser meant, but only 7% gave the correct 
> meaning."
> 
> https://techxplore.com/news/2023-11-idea-padlock-icon-internet-browser.html
> 
> https://www.nextgov.com/cybersecurity/2019/06/fbi-warning-lock-icon-doesnt-mean-website-safe/157629/
> 
> 'In an alert published Monday <https://www.ic3.gov/media/2019/190610.aspx>, 
> the bureau’s Internet Crime Complaint Center, or IC3, warned that scammers 
> are using the public’s trust in website certificates as part of phishing 
> campaigns.
> 
> “The presence of ‘https’ and the lock icon are supposed to indicate the web 
> traffic is encrypted and that visitors can share data safely,” the bureau 
> wrote in the alert. “Unfortunately, cyber criminals are banking on the 
> public’s trust of ‘https’ and the lock icon.” '
> 
> https://theconversation.com/the-vast-majority-of-us-have-no-idea-what-the-padlock-icon-on-our-internet-browser-is-and-its-putting-us-at-risk-216581
> 
> https://www.sciencealert.com/theres-a-tiny-icon-on-your-screen-but-almost-nobody-knows-why
> 
> https://www.theverge.com/2023/5/3/23709498/google-chrome-lock-icon-web-browser-https-security-update-redesign
> 
> https://www.howtogeek.com/890033/google-chrome-is-ditching-the-lock-icon-for-websites/
> 
> 
> 
> d/
> 
> 
> -- 
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
> mast:@dcrocker@mastodon.social 
> <mailto:mast:@dcrocker@mastodon.social>___
> 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: [Ietf-dkim] Security indicators, not Headers that should not be automatically oversigned

[Hector Santos]

The "Report as Spam” button is always there.  They have normalized the practice 
for users to expect legitimate mail in spam boxes, thus causing more eyeballs 
around the junk. That is all spammers want.


https://www.wsj.com/articles/google-and-yahoo-are-cracking-down-on-inbox-spam-dont-expect-less-email-marketing-dd124c19
Google and Yahoo Are Cracking Down on Inbox Spam. Don’t Expect Less Email 
Marketing.
wsj.com


All the best,
Hector Santos



> On Feb 6, 2024, at 1:43 PM, John Levine  wrote:
> 
> It appears that Jim Fenton   said:
>> On 5 Feb 2024, at 14:02, Dave Crocker wrote:
>> 
>>> On 2/5/2024 1:56 PM, Jim Fenton wrote:
>>>> And you will also provide citations to refereed research about what you 
>>>> just asserted as well, yes?
>>> 
>>> 
>>> Ahh, you want me to prove the negative. That's not exactly how these things 
>>> go.
>> 
>> You said that the URL lock symbol failed. Asking for research to back that 
>> up is not asking for you to
>> prove the negative. I suspect there is research out there that backs up that 
>> statement, and I’m just
>> asking for the same amount of rigor that you are asking for.
> 
> In this case, Dave's right.  Here's a conference paper from Google saying 
> that only 11% of users
> understood what the lock meant.
> 
> https://research.google/pubs/it-builds-trust-with-the-customers-exploring-user-perceptions-of-the-padlock-icon-in-browser-ui/
> 
> The annual Usenix SOUPS conferences are full of papers about failed security 
> UI.  Here's this year's.
> Don't miss the one saying that Gmail's message origin indicator doesn't work, 
> 
> https://www.usenix.org/conference/soups2023/technical-sessions
> 
> R's,
> John
> 
> ___
> 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: [Ietf-dkim] Question about lone CR / LF

[Hector Santos]

On 2/5/2024 11:50 AM, Dave Crocker wrote:


(*) Lon ago, Knuth visited UCLA when I was there, and 'structured 
programming' was a hot topic.  He did a presentation to test a 
perspective that he later wrote up.  He observed that fully 
structured programs, without gotos, could sometimes make code 
/worse/.  He shows some code without any gotos that was correct but 
extremely difficult to read and understand.  Then he showed a 
version, with two loops -- one after the other -- and inside each 
was a goto into the other.  OMG.  But this code was clear, concise 
and easy to understand.


I recall an old corporate project SE coding guideline: usage of a GOTO 
LABEL was allowed if the LABEL is within the reader's page view, i.e. 
25 lines (using 25x80 terminal standards).


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



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

Re: [Ietf-dkim] Headers that should not be automatically oversigned in a DKIM signature?

[Hector Santos]

> On Feb 3, 2024, at 8:23 AM, Alessandro Vesely  wrote:
> 
> On Fri 02/Feb/2024 14:34:22 +0100 Hector Santos wrote:
>> Of course, the MUA is another issue.  What read order should be expected for 
>> Oversign headers?  Each MUA can be different although I would think streamed 
>> in data are naturally read sequentially and the first display headers found 
>> are used in the UI.
> 
> 
> Yeah, which is the opposite of DKIM specified order.


>>   Only To: is allowed to be a list.
> 
> 
> RFC 5322 specifies lists for From:, To:, Cc:, Bcc:, Reply-To:, Resent-From:, 
> Resent-To:, Resent-Cc: and Resent-Bcc:.


My comment was regarding the MUA and the order data is read. I wonder which 
MUAs will display a list for Display fields From: and Resent-*. If any.  Are 
all of these OverSign targets?  

if we go down this road, the recommendation might be to always sign all 
headers, including the missing, including ARC and trace headers and before 
signing, reorder specific headers to DKIM-ready MUA read-order standards, if 
any.

Are MUAs now doing verifications and filtering failures?  Or is it the backend, 
the host, the MDA, that is still generally responsible for doing the 
verification and mail filtering before passing it on to users?


All the best,
Hector Santos

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

Re: [Ietf-dkim] Question about lone CR / LF

[Hector Santos]

On 2/2/2024 12:03 AM, Murray S. Kucherawy wrote:

On Thu, Feb 1, 2024 at 10:03 AM John Levine  wrote:

It appears that Murray S. Kucherawy   said:
>-=-=-=-=-=-
>
>On Wed, Jan 31, 2024 at 5:44 PM Steffen Nurpmeso
 wrote:
>
>> But i cannot read this from RFC 6376.
>
>Sections 2.8 and 3.4.4 don't answer this?

Not really.  They say what to do with CRLF but not with a lone
CR or lone LF.


Ah, I misunderstood the question.

I agree that by the time you're talking to a DKIM (or any) filter, I 
expect that this has been handled somehow. CRLF ends a line, 
anything before that is part of the line, and WSP is just a space or 
a tab.  Past that, garbage in, garbage out.




+1.   5322/5321 EOL is CRLF



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

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

Re: [Ietf-dkim] Headers that should not be automatically oversigned in a DKIM signature?

[Hector Santos]

On 2/1/2024 6:38 AM, Alessandro Vesely wrote:

On Wed 31/Jan/2024 18:34:46 +0100 Hector Santos wrote:

If I add this feature to wcDKIM, it can be introduced as:

[X] Enable DKIM Replay Protection


That'd be deceptive, as DKIM replay in Dave's sense won't be 
blocked, while there can be other effects on signature robustness.



First, thanks to your and Murray's input.

I need to review Dave's "DKIM Replay" concerns.   Legacy systems have 
many entry points to create, import/export methods, transformation, 
filling missing fields, etc. Overall, I considered the potential 
"Replay" concern was about taking an existing signed message (from a 
purported "trusted signer" ) but MUA display fields, namely, To: and 
Subject: are missing or not signed.  These can potentially be replayed 
with tampered To:, Subject fields and exported.  The multiple 
5322.From headers MUA concern was highlighted many moons ago.  Easily 
Addressed with incoming SMTP filters rejecting multi-From messages.




A better sentence could be:

[X] Prevent further additions of this field


"This" meaning there is a header selection to monitor?    See below


Note that some packages allow choices such as

[ ] Sign and oversign only if present in the message
[ ] Oversign only if already present in the h= list
[ ] Oversign anyway 


Given how our package offer the signing defaults:

UseRequiredHeadersOnly = 1   # optional, 1 - use 
RequireHeaders
RequiredHeaders    = 
From:To:Date:Message-Id:Organization:Subject:Received*:List-ID
SkipHeaders    = 
X-*:Authentication-Results:DKIM-Signature:DomainKey-Signature:Return-Path
StripHeaders   = # optional, headers 
stripped by resigners


Basically, as the message to be signed headers are read in, each are 
checked again the RequiredHeaders (when enabled).  If missing, the 
header is not signed.  The exception is From: which is always 
signed.   Signed headers are added to the "h=" fields.


So how about this, if I follow this, new namespace fields:

OversignHeader.To = # default blank
OversignHeader.Subject =  # default blank
.
.
OversignHeader.Field-Name=   # future oversign header

This allows an oversign header to be signed if missing.  If correct, 
easily to update the code.


Of course, the MUA is another issue.  What read order should be 
expected for Oversign headers?  Each MUA can be different although I 
would think streamed in data are naturally read sequentially and the 
first display headers found are used in the UI.  Only To: is allowed 
to be a list.



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



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

Re: [Ietf-dkim] Headers that should not be automatically oversigned in a DKIM signature?

[Hector Santos]

> On Jan 19, 2024, at 8:41 PM, John R Levine  wrote:
> 
> Manfred said:
>> (Seems like "seal"ing would be a better term than "oversign"ing.)
> 
> We've called it oversigning for a decade now.
> 

Interesting.  

First time I have come across the term (“oversign”)  and it appears to be a 
feature with several products in the market. But checking the RFC, unless I 
missed it, it’s not a RFC defined term.  Replay is the term used.

To me, the term connotes “redundant signing” beyond what is necessary or 
desired for a particular signing rule.   If I add this feature to wcDKIM, it 
can be introduced as:

[X] Enable DKIM Replay Protection

The F1 help will indicate the addition of headers, i.e.  To:, Subject:, etc. as 
empty field values are used to enforce the hashing binding of these potentially 
missing headers to the signature. If enabled, then these specific headers 
MUST be included in the list of headers to be signed and the headers MUST 
exist.  If not, the headers with empty values will be hash bound to the 
signature.

Is that “Oversigning?”

Perhaps. Imo, it is redundant header(s) signing when it may not be required for 
certain DKIM signing routes.  

What is most important is what it is suppose to help address - DKIM Replay 
hacks.

All the best,
Hector Santos




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

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[Hector Santos]

> On Jan 19, 2024, at 10:19 AM, Todd Herr 
>  wrote:
> 
> 
> Perhaps the way forward for DMARC is to look for a Sender header when there 
> is more than one RFC5322.From domain and use that for DMARC processing, with 
> the stipulation that messages that don't contain such a Sender header are 
> invalid and should be rejected? 

Todd,  +1

I like this idea.  The 5322.Sender is required for a 2+ address Mailbox-list.

https://www.ietf.org/archive/id/draft-ietf-emailcore-rfc5322bis-09.html#section-3.6.2

This also feeds an RFC5322 validator with a new rule to make sure Sender exist 
for a 2+ address mailbox-list and also open the door to using Sender for DMARC 
purposes and if you could, reference RFC5322 section 3.6.2   

In the name of integration and codification of layered protocols, since 
RFC5322bis is still active, perhaps it can revisit the 5322.From ABNF and/or 
have something more strongly to say about it regarding 2+ address mailbox-list. 
 Perhaps it should be deprecated.  It would better match the current DMARCBis 
semantics and security-related concerns on 5322.From with multiple addresses.


All the best,
Hector Santos


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

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[Hector Santos]

Hi, 

As a long time implementer and integrator of IETF protocols, my mail 
engineering view ….

The thing is RFC 822, 2822 and 5322 allows for a single 5322.From header to 
have multiple addresses:

from = "From:" mailbox-list CRLF
mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list

So it is intentional? Obviously, there was a time and  mail “group-ware” 
application scenario where it applied so it was engineered and written into the 
822 specification. 

But were there any client MUA that supports it?   I (Santronics Software) never 
added it in any of my MUAs, which were USER and SYSOP-based.  Even if not, it 
is still technically possible to create a legally formatted RFC822, 2822, 5322 
message and send it via SMTP.

Now comes DKIM and its DKIM Policy Modeling add-ons…..

DKIM signing requires the hash binding of the entire content of the 5322.From 
header.   There is no modifications expected before signing.  Note:  While 
Rewrite is a kludge solution to a domain redirection problem, it is not the 
same but I can see where it can fit here.

ALL DKIM Policy Models (the add-ons over DKIM-BASE) starting with SSP, DSAP, 
ADSP and now DMARC provided guidelines to support 1st party signature. 
Unfortunately, they failed on the authorization of a 3rd party signer scenario. 

So it means, at least one of the authors domain should match/align with the 
signer domain per DMARC logic.

This sounds logical to me, albeit more complexity in the codes that reads and 
processes the headers.  We don’t have any MUAs or bots that have a need or 
support for multiple authors.  That need is called Mailing List.  But for DKIM 
Policy models, it should be allowed as long as there is an aligned/matching 
signer domain in the From header mailbox-list.

However, if I have been following this thread, DMARCBis was updated to ignore 
these multi-from messages for DMARC purposes because they (erroneously) 
presumed they should be rejected, i.e. never make it to a signer or verifier.

I am not sure that is correct.


All the best,
Hector Santos


> On Jan 18, 2024, at 10:59 AM, Emil Gustafsson 
>  wrote:
> 
> I have a data point.
> When we (Google) did an experiment/analysis of this a couple of years ago the 
> conclusion was
> a) multi-value From are relatively rare and mostly look like abuse or 
> mistakes rather than intentional.
> b) Users generally don't care about those messages if they end up in spam.
> 
> So...
> Is the volume measurable? -  yes but very small
> Are there legitimate emails? - yes but users don't seem to care about these 
> messages
> 
> Based on the data I have, I would be in favor of an update that essentially 
> makes multivalued From Invalid rather than a corner case that needs to be 
> handled.
> 
> /E
> 
> On Thu, Jan 18, 2024 at 12:41 AM Steven M Jones  wrote:
> On 1/17/24 2:56 AM, Alessandro Vesely wrote:
> > [ Discussion of  what to do with multi-valued From: in messages ]
> >
> > However, since DMARC bears the blame of banning multi-valued From:, it 
> > is appropriate for it to say something about the consequences and 
> > possible workarounds.
> 
> DMARC doesn't ban multi-valued From:, but the language of section 6.6.1 
> is confusing because we were documenting the practice of implementers up 
> to that time as much as being prescriptive. If anything, it highlights 
> the need for the clearer language that Todd quoted earlier in this thread.
> 
> Has a measurable volume of legitimate messages with multi-valued From: 
> headers been reported in the wild? Is there a real-world problem that 
> needs to be solved?
> 
> --Steve.
> 
> 
> ___
> 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

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

Re: [dmarc-ietf] DMARC session at IETF 118

[Hector Santos]

Hi Barry,

We not both?  A robust discussion on the mailing list coupled with a 
dedicated session at IETF 118. This issue has deep implications for 
everyone from small businesses to the large players in domain hosting 
like Microsoft, Google, and Yahoo.


While these major players hold a disproportionate amount of influence 
given their scale, it's crucial that the IETF remains committed to 
standards that serve the broader community. The far-reaching impact of 
decisions related to SPF, DKIM, and DMARC policies cannot be 
overstated. Moreover, I believe that discussing these issues in a more 
dynamic setting like IETF 118 can bring fresh perspectives into the 
fold, especially from those who may not be regular mailing list 
contributors but have substantial stakes in this.


Specifically, I want to draw attention to the idea of expanding our 
focus to include DKIM Policy Modeling. DMARC, a derivative of the 
incomplete ADSP/ATPS protocols, has its value but has also been 
commercialized to a degree that may not fully align with IETF 
standards.   Instead of introducing new proposals, my suggestion aims 
to refocus our current discussions. I believe we could benefit from 
considering DMARC as an Informational document. This would allow us to 
collectively examine existing standards more critically and possibly 
identify areas for improvement that better align with IETF principles.



Thank you for considering this perspective.

Best,
HLS



On 10/28/2023 1:38 PM, Barry Leiba wrote:

I'm starting this in a separate thread that I want to keep for ONLY
the following question:

Do we want to use the session we have scheduled at IETF 118 to talk
about the issue that clearly is still in discussion about adding a tag
to specify which authentication mechanism(s) to use when evaluating
DMARC?

Or shall I cancel the 118 session and just let the discussion continue
on the mailing list?

And being clear here: the "eliminate SPF entirely" suggestion is
definitely out, failing rough consensus.  We're *only* talking about
the suggestion to add a tag to specify what the sender wants.

Barry

___
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] DMARCbis way forward: Do we need our session at IETF 118

[Hector Santos]

Fwiiw, Lurker opinion:

I ideally vote to make DMARCBis Experimental Status and begin to explore the 
“required” integration between envelope (5321 only) protocols and payload 
(5322) protocols. Specifically, work on a “proper” DKIM+SPF Policy Modeling 
with 3rd party signature support. 

But realistically, we should finish DMARCBis as is, as Levine desires.  
However, imto, keeping it a Standard Track will increase the ignorance.  I 
don’t see any new gains for current my package implementation.  At best, the 
industry is acknowledging a big integration problem. Domains who can’ get past 
sending mail the large Mall Hosting domains and managed domains DMARC 
processing are learning to relax their policies. 

PS:  I don’t plan any appeal 

—
HLS


> On Oct 28, 2023, at 12:49 PM, Murray S. Kucherawy  wrote:
> 
> On Sat, Oct 28, 2023 at 8:28 AM Richard Clayton  > wrote:
>> Paying attention to the (sometimes inferred) age of a signature is also
>> important for reducing the opportunity for replay, viz: it would be a
>> Good Thing for senders to set appropriately short expire times.
> 
> Why does it have to be inferred sometimes?  Have you found "t=" values to be 
> occasionally inaccurate?
> 
> The DKIM standard advises against using "x=" to combat replay attacks.  We 
> could always update that advice, but we might also want to review why it was 
> put there in the first place.  I remember the reason being a good one.
> 
> I think there's also been discussion around the reliability of "x=" across 
> implementations.  Since it's not mandatory to support, it doesn't seem to be 
> very common to produce without the expectation of consumers.
> 
> -MSK, participating
> ___
> 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] DMARCbis way forward: Do we need our session at IETF 118

[Hector Santos]

On 10/24/2023 2:15 PM, Barry Leiba wrote:

Now that we have a consensus call on the main issue that has remained open:

1. Do we need to retain our session at IETF 118 and discuss this (or
something else) further?

...or...

2. Do we have what we need to finish up the DMARCbis document, and
should the chairs cancel the session at 118?


I think #2  is best, imto.DMARC and DMARCbis will remain a processing 
overhead for logging, but no honoring of policies. I have yet to see 
any consistency. No faith in this protocol. It can not be considered a 
deterministic protocol. With all the debate on lookup, I still don't 
understand what is expected. Would be nice to see some simple pseudo 
code for the new logic. But why? Nothing deterministic about it to say 
- REJECT with confidence.


SPF is still king here though .


Oh, and...

3. Is there something else (such as the reporting documents) that we
should use the time at 118 to discuss?  Or can we continue with those
on the mailing list for now?  My sense is that aggregate reporting, at
least, is just about ready to go and doesn't need the face-to-face
time.


Primary technical problem is inconsistency in reading the report formats.

I want to know the following in a report:

Which domain? Who try to use it?  What was return path, the IP and 
principle DKIM identities, if you got that far?


I still won't know what I will gain but I do hope the receivers honor 
my policies especially for SPF because I am honoring SPF rejects on 
the receiver side.


SPF remains the only protocol I honor 100% and according to my 
business site sites, this month total rejects are 34% SPF!


If anything, I get DMARC reports but I learn nothing from them.

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

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

[Hector Santos]

I have been “militantly” against Authorship destruction.  But fast forward to 
today, I am willing to support it IFF it can be officially sanctioned by the 
IETF using a well-defined Rewrite protocol for List Systems.

Overall, I believe if the middle ware performs a rewrite due to an author’s 
restrictive policy, we should consider these technical concepts:

1) Applicable to p=reject or p=quarantine only,
2) A domain rewrite SHOULD match the original domain security.

For example,  for this list,  the IETF list manager rewrites my address:

hsantos@isdg,net

to

hsantos=40isdg@dmarc.ietf.org <mailto:hsantos=40isdg@dmarc.ietf.org>

I believe any domain transformation should retain the p=reject isdg.net 
<http://isdg.net/> policy security level.  In this case, p=reject was weaken to 
p=none with the domain change.

So I can support rewrites iff the domain security can be retained.

All the best,
Hector Santos



> On Sep 14, 2023, at 5:27 PM, Wei Chuang  
> wrote:
> 
> 
> 
> On Sun, Sep 10, 2023 at 11:34 AM Scott Kitterman  <mailto:skl...@kitterman.com>> wrote:
>> On Thursday, September 7, 2023 12:28:59 PM EDT Wei Chuang wrote:
>> > We had an opportunity to further review the DMARCbis changes more broadly
>> > within Gmail.  While we don't see any blockers in the language in DMARCbis
>> > version 28
>> > <https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-dmarcbis-28> and
>> > can live with what is there, we wanted to briefly raise some concerns
>> > around some of the changes.  Two points.
>> > 
>> > Regarding the languages in section 8.6 "It is therefore critical that
>> > domains that host users who might post messages to mailing lists SHOULD NOT
>> > publish p=reject.  Domains that choose to publish p=reject SHOULD implement
>> > policies that their users not post to Internet mailing lists", we wanted to
>> > point out that this is impossible to implement.  Many enterprises already
>> > have "p=reject" policies.  Presumably those domains were subject to some
>> > sort of spoofing which is why they went to such a strict policy.  It would
>> > be unreasonable to tell them to stop posting to mailing lists as many
>> > likely already use mailing list services and will want to continue to use
>> > them.  The one thing that makes this tractable is the SHOULD language as we
>> > may choose not to not follow this aspect of the specification.  Our
>> > suggestion is that there is not a lot of value in including this language
>> > in the bis document if the likely outcome is that it will be ignored, and
>> > rather more effort should be placed with a technical solution for interop
>> > with mailing lists.
>> 
>> It might be helpful if you could describe this technical solution from your 
>> perspective.
>> 
>> If there were a reasonable technical solution available, I think this would 
>> be 
>> a much easier change to support (in my opinion, and a believe a substantial 
>> number of others, rewriting From is not a reasonable technical solution).
>> 
>> Scott K
> 
> Apologies for the delay in getting back to this. 
> 
> So yes I believe there are two possible technical approaches broadly speaking 
> 1) Support rewriting From and being able to reverse it along with message 
> modifications to recover the original DKIM message hash to validate the 
> original DKIM signature.  2) Create a new message authentication method that 
> is tolerant of message modifications and message forwarding, and supported by 
> DMARC.  From header rewriting would not be necessary in this scenario.  
> Beyond the complexity of supporting either method, another tricky thing in 
> both cases is supporting an ecosystem with diverse adoption of said 
> technique.  More concrete proposals for 1) and 2) are 1) 
> draft-chuang-mailing-list-modifications 
> <https://datatracker.ietf.org/doc/draft-chuang-mailing-list-modifications/> 
> and 2) draft-chuang-replay-resistant-arc 
> <http://draft-chuang-replay-resistant-arc/>.  And there are other I-Ds out 
> there particularly for the first approach.
> 
> -Wei
> 
> ___
> 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] Some Gmail comments on DMARCbis version 28

[Hector Santos]

Hello esteemed colleagues,

I'm sure we're on the cusp of a future where only "Authenticated Mail of the 
Fifth Kind" will reign supreme—much like the exclusive club of Submission 
Protocol requiring ESMTP AUTH on the ultra-special port 587. And surely, the 
ever-trusted port 25 will forever stand as a beacon of hope, right? Because how 
could we possibly survive without unsolicited, unauthenticated messages? 

Perhaps, just perhaps, in this utopian future, every sender will be upstanding 
citizens with impeccable SPF and DKIM policies. But of course, if any domain 
dares to relax these stringent policies, the noble and always compliant 
receivers will swoop in to defend the realm. And heaven forbid the receivers 
falter, for the all-seeing MAEA "Mail Authentication Enforcement Agency" is 
ever watchful, ready to unleash a fine.

And maybe, just maybe, we'll live in a world where the almighty MAEA gets to 
play tax collector, ensuring every sender pays their dues. Ah, but not the 
Fidonet and QWK loyalists! They'll be cruising without a care, exempt from the 
MAEA's grasp.

All in jest, of course, but it's food for thought!

Best regards,
Hector Santos


> On Sep 16, 2023, at 11:18 PM, Barry Leiba  wrote:
> 
> I believe, with you, that there's likely to be a time when
> unauthenticated mail simply will not be delivered by most receiving
> domains.  I similarly believe (as the owner of a Tesla) that there
> will be a time when cars will be self-driving in the vast majority,
> and that that will make the roads both safer and more efficient.
> 
> Neither of those situations is here yet, though, and neither is likely
> to arrive very soon.  Some day, yes.  Not yet, and not soon.
> 
> While we can certainly discuss the former -- particularly with a focus
> on what needs to happen before that situation can be realised -- we
> need to first make sure that we resolve the few remaining issues in
> the DMARCbis and reporting documents and get them published.
> 
> Barry
> 
> On Sat, Sep 16, 2023 at 6:56 AM Douglas Foster
>  wrote:
>> 
>> Yes, I suspected awhile back that I was the only one in the world 
>> implementing mandatory authentication.   This group has confirmed it.
>> 
>> But I hold out hope thst others will see the opportunity that it provides.  
>> Perhaps someone will read my Best Practices draft and sponsor it as an 
>> individual contribution or experimental draft.
>> 
>> Doug
>> 
>> 
>> On Fri, Sep 15, 2023, 9:26 AM Barry Leiba  wrote:
>>> 
>>>> Content filtering creates a need for whitelisting
>>>> Any domain may require whitelisting, regardless of sender policy.
>>>> Whitelisting is only safe if it is coupled with an authentication 
>>>> mechanism which prevents impersonation.
>>>> Therefore, sender authentication, by a combination of local policy and 
>>>> sender policy, needs to be defined for all possible messages.
>>> 
>>> The last statement there is where things go off the rails.  No,
>>> nothing has to work perfectly here, and mechanisms are useful and can
>>> well be standardized even when they don't work in "all possible"
>>> situations.
>>> 
>>> It's really important that we stop insisting on perfection or nothing,
>>> as that's a false dichotomy.  What we have now is demonstrably useful
>>> as *part of* an overall system.  We need to move forward with
>>> finishing the document.
>>> 
>>> Barry
>> 
>> ___
>> 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



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

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

[Hector Santos]

> On Sep 14, 2023, at 10:39 AM, Murray S. Kucherawy  wrote:
> 
> On Wed, Sep 13, 2023 at 6:01 PM Douglas Foster 
>  <mailto:dougfoster.emailstanda...@gmail.com>> wrote:
>> 
>> The coverage problem is aggravated if we assume rational attackers.   With a 
>> plethora of domains available for impersonation, attackers are least likely 
>> to use domains that are protected with p=reject.  Therefore the reference 
>> model implementation protects an evaluator where attacks are least likely, 
>> and fails to protect an evaluator where attacks are most likely.
> 
> So you're saying DMARC fails to protect domains that don't set "p=reject"?  
> That claim has the appearance of a tautology.
> 


Firs, I agree with your thoughts here.

I always considered these new DNS-based Apps that offered policies, their 
highest payoff is the most restrictive policy, the partials policies like SPF 
soft fail or unknown policies or DMARD p=none policies is technically overhead 
and redundancy if every query is always a “well I don’t know” do what you wish. 
 DNS and processing overhead.

The highest payoff for SPF is -ALL and then highest payoff for DMARC is 
p=reject despite its faulty authorization or restrictive algorithm,

All the best,
Hector Santos

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

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

[Hector Santos]

> On Sep 14, 2023, at 7:36 AM, Dotzero  wrote:
> 
> On Wed, Sep 13, 2023 at 9:21 PM Hector Santos  <mailto:hsan...@isdg.net>> wrote:
>> 
>>> On Sep 13, 2023, at 8:51 PM, Dotzero >> <mailto:dotz...@gmail.com>> wrote:
>>> 
>>> DMARC does one thing and one thing only. It mitigates against direct domain 
>>> abuse in a deterministic manner, nothing else. It doesn't stop spam and it 
>>> doesn't depend on or involve reputation. It is but one tool among a number 
>>> of tools that various parties can choose from. A message passing DMARC 
>>> validation does not mean the message is "good". There is no question of 
>>> fault. Perhaps you should recommend changes to incorporate a blame game if 
>>> your goal is to determine fault. 
>> 
>> Deterministic means there is no question -  you follow the protocol. Your 
>> (speaking in general) opinions don’t matter. 
> 
> It means that the output of the algorithm is deterministic. It does not mean 
> that the receiver blindly act on that output. As has been stated many times 
> by many people, a policy assertion is a request by the sending domain 
> administrator/owner, not a mandate. That is why local policy on the part of 
> the receiver overrides a sender policy assertion.
> 


Over the years, as a supporter of SPF and DKIM Policy, and being the DSAP's 
author, I've witnessed how deterministic protocols like SSP, DSAP, ADSP, and 
DMARC pave the way for policy-driven rejections. They operate without 
subjectivity. But the inclusion of local policies can lead to diverse behaviors 
among platforms. While Site A might conform strictly to a policy, Site B might 
diverge.

The introduction of RFC 5016, Section 5.3, Item 10 underlines the primacy of 
local policies. This was especially pertinent for Mailing List systems, which 
often tampered with the original DKIM author's signature integrity. These 
systems then re-signed the altered message for list distribution as a 3rd 
party. At that time, a gap existed as we lacked a deterministic policy catering 
to these 3rd parties, which could work alongside SSP,  ADSP and now DMARC's 1st 
party only signer algorithm.

DMARC has amplified the significance of local policies, given the high 
likelihood of false positives. The introduction of local policies has somewhat 
diluted the effectiveness of deterministic protocols. We're still navigating 
these nuances, even after 15+ years.

All the best,
Hector Santos



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

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

[Hector Santos]

All the best,
Hector Santos



> On Sep 13, 2023, at 8:51 PM, Dotzero  wrote:
> 
> 
> 
> On Wed, Sep 13, 2023 at 5:28 PM Hector Santos  <mailto:hsan...@isdg.net>> wrote:
>>> On Sep 11, 2023, at 9:24 AM, Dotzero >> <mailto:dotz...@gmail.com>> chastised Douglas Foster
>>> 
>>> Absolutely incorrect. DMARC is a deterministic pass|fail approach based on 
>>> validation through DKIM or SPF pass (or if both pass). It says nothing 
>>> about the acceptability/goodness/badness of a source. 
>> 
>> So why are we here?
> 
> Because you care? 

I do. 

>> 
>> Correct or incorrect, a published p=reject has to mean something to the 
>> verifier who is doing the domain a favor by a) implementing the protocol and 
>> b) the goal of eliminating junk.   If there are false negatives, whose fault 
>> is that?  The Domain, The Verifier or the Protocol?
> 
> DMARC does one thing and one thing only. It mitigates against direct domain 
> abuse in a deterministic manner, nothing else. It doesn't stop spam and it 
> doesn't depend on or involve reputation. It is but one tool among a number of 
> tools that various parties can choose from. A message passing DMARC 
> validation does not mean the message is "good". There is no question of 
> fault. Perhaps you should recommend changes to incorporate a blame game if 
> your goal is to determine fault. 

Deterministic means there is no question -  you follow the protocol. Your 
(speaking in general) opinions don’t matter. 

>> 
>> Please try to be more civil with people’s views or position with this 
>> problematic protocol.
> 
> Thank you for sharing your opinion. I'm truly and deeply sorrowful if I have 
> offended your sensibilities. I will consider including trigger warnings on 
> future posts. 

Share that with Douglas Foster.

>> 
>> Thanks
> 
> You are welcome.

My Pleasure.

—
HLS

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

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

[Hector Santos]

> On Sep 11, 2023, at 9:24 AM, Dotzero  chastised Douglas 
> Foster
> 
> Absolutely incorrect. DMARC is a deterministic pass|fail approach based on 
> validation through DKIM or SPF pass (or if both pass). It says nothing about 
> the acceptability/goodness/badness of a source. 

So why are we here?

Correct or incorrect, a published p=reject has to mean something to the 
verifier who is doing the domain a favor by a) implementing the protocol and b) 
the goal of eliminating junk.   If there are false negatives, whose fault is 
that?  The Domain, The Verifier or the Protocol?

I think it’s the protocol but thats my opinion as one of early DKIM POLICY 
adopters and an advanced and costly implementation. If policy does not help 
protect a domain and also the receiver with failure hints or better said 
negative classification of a source per the domain policy, then what is the 
point of the work here or lack of there? 

Same is true with SPF.

Please try to be more civil with people’s views or position with this 
problematic protocol.

Thanks

All the best,
Hector Santos


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

Re: [dmarc-ietf] p=interoperability p=compliance p=orgname:policyname

[Hector Santos]

We have many considerations and if we “are [near] finish” then please publish a 
new draft to see where are at.  With so many unknowns, its fertilizes 
uncertainty, “desperate questions” and ignored suggestions and proposals.

I believe an update is warranted.

All the best,
Hector Santos



> On Aug 23, 2023, at 4:10 PM, Barry Leiba  wrote:
> 
> Apart from "never finish", I would contend that changes of that nature
> violate the "preserve interoperability with the installed base of
> DMARC systems" clause of our charter.  We *can* make changes such as
> this if we have a reason that's compelling enough, but as we talk
> about changing the strings that we use for "p=", the arguments are
> more cosmetic than truly functional, and I certainly don't see them as
> compelling.
> 
> Barry
> 
> On Wed, Aug 23, 2023 at 12:11 PM John Levine  wrote:
>> 
>> It appears that Jesse Thompson   said:
>>> I'm beginning to think that a solution to this problem is "other channels"
>>> 
>>> Let's discuss p=interoperability, p=compliance, or p=orgname:policyname
>> 
>> Please, no.  This WG has already run a year past its sell-by date.  Stuff
>> like this will just tell the world that we'll never finish.
>> 
>> R's,
>> John
>> 
>> ___
>> 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

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

[dmarc-ietf] Current Status of DMARCBis

[Hector Santos]

I am interested in understanding what is the current consensus for the key 
changes in DMARCbis. Anxious to begin exploratory coding, I am personally 
focused on integration algorithms to apply dynamically processed results for 
SPF, DMARC,Alignment and the “relaxer” auth= tag.

spf=pass
spf=hardfail
spf=softfail
spf=neutral
spf=unknown

dmarc=Pass
dmarc=Reject 
dmarc=Quarantine
dmarc=None

alignment=pass
alignment=fail

auth=spf
auth=dkim
auth=spf,dkim

With no judgement.

Of course, the issue has been there are too many false negatives with p=reject 
and p=quarantine applications.

Are we considering results for ARC?  I don’t know the ARC state conditions to 
state here, but I presume it provides a "trusted” or “self-signed” solution to 
correct broken 1st party signatures?

I would also like to see an updated DMARCBis protocol lookup procedure or 
algorithm when considering the proposed optional process parameter “auth=“ 
value.

An updated draft would be the ideal for the most current consensus.

Thanks

—
HLS

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

Re: [dmarc-ietf] Proposal for additional Security Considerations for SPF Upgrade in draft-ietf-dmarc-dmarcbis

[Hector Santos]

> On Aug 5, 2023, at 5:37 PM, Scott Kitterman  wrote:
> 
> On Saturday, August 5, 2023 3:59:02 PM EDT John Levine wrote:
>> It appears that Scott Kitterman   said:
 When receivers apply the "MUST NOT reject" in Section 8.6 to accept
 unauthenticated messages as quarantined messages, receivers SHOULD
 carefully review how they forward mail traffic to prevent additional
 security risk.  That is, this downgrade can enable spoofed messages that
 are SPF DMARC authenticated with a fraudulent From identity despite having
 an associated strong DMARC policy of "p=reject". ...
>> 
>> We all realize that SPF has problems, but I really do not want to fill
>> up the DMARC document with text that says "you can authenticate with
>> SPF, hahaha no just kidding."
>> 
>> The way to fix Microsoft's forwarding SPF problem is for Microsoft to put
>> the forwarding user's bounce address on the message, not for us to tell
>> the entire world to use kludgy workarounds.
> 
> I agree.  We need to be careful to solve protocol problems in the protocol 
> and 
> leave fixing implementation problems to implementers.  We aren't going to 
> protocol our way out of bad implementation decisions.

Taken within the good-intention, protocol-compliant implementations, which one 
do we add as “Implementations Notes?”  Which or rather What are “Current 
Practice”behavior can we note?  

—
HLS




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

Re: [dmarc-ietf] Idle Musings - Why Is It DMARC and not DMARD?

[Hector Santos]

On Aug 5, 2023, at 12:57 PM, Benny Pedersen  wrote:
> 
> Dave Crocker skrev den 2023-08-05 18:49:
> 
>>> Governance seems like the best word to me, since Governance is what 
>>> Reporting has provided to ADs in Monitoring Mode, but I do not want to say 
>>> DMARG out loud either :-)
>> Here, too, the domain owner does not govern the platform receiver.
> 
> good news for paypal phishers, sadly
> 
> the recipient should newer recieve mail that is with credit card info by 
> dmarc is unaligned to the dmarc policy, when policy is basicly ignored we 
> have the underlaying problem dmarc should solve, but as is does not
> 

As a receiver,  I don’t wish to be inundated with spam or spoofs. I will honor 
incoming mail domain policies with deterministic rules.  As a sender, I want 
other receivers to also honor and protect my domains as well.  It’s a win-win. 

SPF -ALL has proved to help with an average of ~5% rejects since its 
introduction.  The growth was slow and it has come with its irritating small 
amount of well-known forwarding problems.  With DMARC, we just have not enabled 
p=reject failures yet.  We need more persistent deterministic DMARC “rules” 
before flipping this switch.

SPF and DKIM Policy models since SSP has been about informing receivers about 
Domain Mail Operational expectations.  This has been good. Receiver Local 
Policy always prevails but a “hint” can help decide things especially when it 
comes to failures.   

—
HLS



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

Re: [dmarc-ietf] Reflections on IETF 117 Conference and DMARC Meeting

[Hector Santos]

Overall, DMARCbis has a “SPF comes before DMARC” conflict where SPF can 
“preempt” DMARC.  

The implementation suggestion is leveraging an existing ESMTP extension 
capability to obtain the DMARC policy at SMTP for one reason - to help DMARC 
fit better with SMTP-level SPF processing.  Otherwise DMARC has an 
implementation design presumption that SPF+DMARC will always be processed 
together and this is not always true.   

The SUBMITTER/PRA was a patented (donated to the IETF Trust) optimizer for the 
payload version of SPF called SenderID by passing the extracted PRA “Purported 
Responsible Address” with the reverse-path. I know this. Enable the ESMTP 
extension and your receiver will see many transactions come in submitter 
information.  So it is still being used.

Does have both data points (Reverse-Path, PRA)  available at SMTP MAIL FROM 
state help?   

I was not thinking using it for SenderID (SPF is sufficient, long decided) but 
using it for DMARC purposes.

Currently,  my mailer has a SPF Reject Before Data out of the box logic.  To 
support DMARC,  do I delay SPF rejection?   One way for me to support existing 
operations and DMARCbis would be to get the DMARC policy, if any, to see if 
there is an overriding “auth=dkim” tag or maybe a “p=none” thus overriding the 
SPF reject at SMTP and continue with the payload transfer overhead where DKIM 
can be evaluated.   

That is basically it.  

DMARC has an implicit design, "To be compliant with DMARC,  Receivers SHOULD 
NOT reject with SPF before DMARC can be evaluated.”  It is predictably ignored 
by many receivers, in particular by systems long existing with SPF and have not 
put all their marbles in an DMARC yet. 

Fortunately, DMARCbis already mentions the possibility for DMARC domains to be 
aware of - SPF can be processed first and preempt any DMARC processing.  I 
believe it is sufficient and there is no real need to go further with a 
possible implementation note for adventurous explorers.

Thanks

—
HLS



> On Aug 4, 2023, at 5:27 AM, Alessandro Vesely  wrote:
> 
> On Thu 03/Aug/2023 21:15:57 + Murray S. Kucherawy wrote:
>> On Thu, Aug 3, 2023 at 10:39 AM Hector Santos > <mailto:hsan...@isdg.net>> wrote:
>>> [...]
>>> 
>>> However, at present, the most plausible use-case appears to be the addition 
>>> of delayed SPF rejection scenarios through DMARC evaluation. Essentially, 
>>> SUBMITTER/PRA serves as an optimizer and a mechanism to soften the impact 
>>> of SPF -ALL policies.
> 
> 
> I agree with Mike about SUBMITTER/PRA.  However, while I disagree with Dave's 
> proposal to use Sender: instead of From:, some kind of advice could still be 
> derived therefrom.
> 
> 
>>> The approach might work as follows:
>>> 
>>> - If SPF fails and the Submitter indicates p=reject, then reject (comes 
>>> with its acceptable problems)
>>> 
>>> - If SPF fails, the Submitter specifies p=reject and auth=dkim, then
>>> proceed to transfer the payload and evaluate DKIM
>>> 
>>> - If SPF fails and the Submitter signifies p=none, then continue with
>>> payload transfer
> 
> 
> That seems gratuitous (assuming Submitter=Sender:'s domain).  If I publish 
> p=none but SPF -all it still means reject (up to whitelists) unless the 
> receiver follows DMARC advice of disregarding SPF policy, but then that's 
> based on From:, not Sender:.
> 
> 
>>> - If SPF fails and the Submitter designates p=quarantine, then proceed
>>> with payload transfer
>>> 
>>> SUBMITTER may help align SPF with its original DMARC purpose—combining
>>> SPF+DKIM results while keeping with some level of optimization.
>> Ah, interesting.
>> I don't think this should go in the base document, since the research we
>> did for RFC 6686 suggests that deployment of SUBMITTER, at least as of that
>> document's publication, wasn't very broad.  However, if the size of the
>> problem is substantial, and this solution turns out to be potentially
>> effective, this might be fodder for the applicability statement or usage
>> guidelines document that this WG has discussed producing in the past as a
>> possible enhancement.
>> Collecting some data and doing some experimentation would be really helpful
>> toward determining the right path here, if any.
> 
> 
> Evaluating Sender: doesn't help whitelisting rejection before DATA.
> 
> The message I'm replying to has:
> 
> Return-Path: mailto:dmarc-boun...@ietf.org>>
> Sender: "dmarc" mailto:dmarc-boun...@ietf.org>>
> 
> To find the added value of Sender:, we'd be looking for a class of 
> forwarders, not mailing lists, where these identifiers differ.
> 
> 
> Best
> Ale
> -- 
> 
> 
> 
> 
> 
> 
> 
> ___
> 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] Reflections on IETF 117 Conference and DMARC Meeting

[Hector Santos]

On 8/3/2023 2:07 AM, Murray S. Kucherawy wrote:
On Mon, Jul 31, 2023 at 9:47 AM Hector Santos 
<mailto:40isdg@dmarc.ietf.org>> wrote:


   - I mentioned using the deprecated SUBMITTER/PRA
(RFC4405/RFC4407)
protocols as an implementation detail to access the author's DMARC
policy at the SMTP "MAIL FROM" stage. Wei expressed interest in
this
idea. This could also enhance the "auth=" idea to help manage local
policy SPF -ALL handling. Should SMTP immediately reject? The
PRA at
SMTP could aid this decision for SPF -ALL policies. Based on many
years of implementation, it's evident that many mailers are either
identical or are using the same software that supports
SUBMITTER/PRA,
possibly due to ongoing support for the deprecated SenderID
(RFC4406)
protocol.  [...]


Can you or Wei spell this out a little more?  What could a list 
subscriber do with this algorithm that we don't have today?


The issue we're facing in a DMARC world isn't determining who the 
original sender is, but rather that with broken signatures, we can't 
prove it to DMARC's satisfaction.  I'm not clear on how your idea 
fixes that.




The utilization of SUBMITTER/PRA protocols possibly can help manage 
situations where SPF fails before any DKIM information is accessible. 
This strategy provides SPF processors with preliminary DMARC policy 
data, potentially mitigating the impact of SPF hard-fail situations. 
The advantages of this approach are especially clear when SPF fails, 
but DMARC can help to temper the initial rejection.


Through the SUBMITTER/PRA, it's possible to ascertain the presence of 
a DMARC p=none or an auth=dkim, giving operators the choice to delay 
immediate rejection and verify DKIM instead.


In the context of a mailing list, using a SUBMITTER in the 
distribution can prove useful. For instance, a list might not need to 
rewrite if it identifies an auth=spf for the domain, allowing it to 
function as a resigner although the original domain integrity was 
broken.   There might be a  auth=arc which ARC is needed for pass 
broken 1st party signature.


I know this is out of scope, but legacy scenarios may included 
checking for the 'atps=y' tag and check for an ATPS DNS authorization 
record for the resigner domain. There still many domains who don't use 
DMARC but instead still have ADSP dkim=all to expose a mail policy - 
"Expect all my mail to be signed."


However, at present, the most plausible use-case appears to be the 
addition of delayed SPF rejection scenarios through DMARC evaluation. 
Essentially, SUBMITTER/PRA serves as an optimizer and a mechanism to 
soften the impact of SPF -ALL policies.


The approach might work as follows:

- If SPF fails and the Submitter indicates p=reject, then reject 
(comes with its acceptable problems)


- If SPF fails, the Submitter specifies p=reject and auth=dkim, then 
proceed to transfer the payload and evaluate DKIM


- If SPF fails and the Submitter signifies p=none, then continue with 
payload transfer


- If SPF fails and the Submitter designates p=quarantine, then proceed 
with payload transfer


SUBMITTER may help align SPF with its original DMARC purpose—combining 
SPF+DKIM results while keeping with some level of optimization.


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



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

Re: [dmarc-ietf] Another p=reject text proposal

[Hector Santos]

*Note: The following is a general rule of thumb for me.*

From my functional specification protocol language coding standpoint:

MUST --> NO OPTION. Technically enabled with no switch to disable.
SHOULD -> OPTIONAL, Default is ON, enabled
MAY -->  OPTIONAL, Default is ON or OFF depending on implementation

With the special RFC documentation format designed/written for a very 
wide audience from managers, system admins, coders, engineers, etc, it 
offers semantics with lower and upper case guidelines. sometimes 
purposely ambiguous (to keep it open ended) and in the IETF  RFC, we 
have used the UPPER CASE language as a way to create code especially 
with standard track items.


Those who choose to ignore the UPPER CASE interop advice often risk 
having the proverbial book thrown at them.


With lower case semantics, this has been my overall implementation 
methods:


may, should --> may be implemented as options as with upper case

must --> may be implemented and enabled with hidden option to disable.

--
HLS


On 7/8/2023 12:49 PM, Richard Clayton wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

In message, Murray S. Kucherawy  writes


Some of my IETF mentors (ahem) taught me some stuff about the use
of SHOULD [NOT] that have stuck with me, and I'm going to pressure
test this against that advice.� Let's see how this goes.� :-)

"SHOULD" leaves the implementer with a choice.� You really ought to
do what it says in the general case, but there might be
circumstances where you could deviate from that advice, with some
possible effect on interoperability.

I noted that one of the earlier messages which endorsed MUST NOT said
that of course some people might know better -- which is what I always
understood SHOULD NOT was for !


  � If you do that, it is
expected that you fully understand the possible impact you're about
to have on the Internet before proceeding.� To that end, we like
the use of SHOULD [NOT] to be accompanied by some prose explaining
when one might deviate in this manner, such as an example of when
it might be okay to do so.

not so much "OK" as "necessary".  Yahoo's original statement (I'm
prepared to name names rather than pussyfoot around this) on the
deployment of p=reject is discussed here:

  https://wordtothewise.com/2014/04/yahoo-statement-dmarc-policy/

and I believe it is widely understood that it was particularly deployed
to counter the "address book spammers" of the time. These bad guys
originally persuaded people to open their email by forging it to appear
to come from their friends (having compromised relevant address books).

They then moved on to just using random identities from the same domain
as the recipient. This led a great many Yahoo users to believe that a
great many other Yahoo users had been compromised, leading to a
significant loss of faith in the integrity of the platform.


Does anyone have such an example in mind that could be included
here?� Specifically: Can we describe a scenario where (a) a sender
publishes p=reject (b) with users that post to lists (c) that the
community at large would be willing to accept/tolerate?

So the example you seek might be phrased along the lines of when failing
to set p=reject means that significant quantities of forged email will
be delivered and this will cause damage.

Personally (not a $DAYJOB$ opinion) I think SHOULD NOT is still too
strong, mailing lists (and other forwarders that mangle email) have been
coping with p=reject for nearly a decade -- so that trying
(ineffectually in practice) to make their lives easier at this point is
a snare and a delusion.

- -- 
richard   Richard Clayton


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




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


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

Re: [dmarc-ietf] Another p=reject text proposal

[Hector Santos]

Barry, 

I did a quick review and comparison for changes.  

Overall, it appears this document is more clear in key specific areas but also 
more complex.  At this point, DMARCbis is about Local Policy, System 
Administrative choices and suggested guidelines, codified and/or new.  As such, 
 I don’t think this document is a "Standard Track" material with its many 
ambiguous considerations and changes.

Consider the following:

Is this document backward compatible with existing DMARC1 behavior?  If not, 
what are the key protocol changes implementers need to consider for updating 
DMARC1 to DMARCbis?  Can this be summarized?  

Thanks

—
HLS


> On Jul 7, 2023, at 9:17 AM, Barry Leiba  wrote:
> 
> I, too, prefer MUST to SHOULD there, but it was clear to me that we
> will not reach rough consensus on MUST, but that we can reach rough
> consensus on SHOULD.
> 
> I do like your suggestion of silent discard rather than bounce, and I
> would want to see that change made -- perhaps with a note that
> aggregate reports will still include information about those discards.
> 
> Barry
> 
> On Fri, Jul 7, 2023 at 9:03 AM Baptiste Carvello
>  wrote:
>> 
>> Hi,
>> 
>> I consider this a step backwards. The MUST requirement on the author
>> domain finally made it clear, after a lost decade, *who* is responsible
>> for solving the breakage of indirect mailflows. Problem solving starts
>> with acknowledging one's responsibilities.
>> 
>> This proposal goes back to a muddy shared responsibility between the
>> author domain and the mail receiver. This is the best way to make sure
>> nothing changes, as each waits for the other to act. Mailing lists can
>> expect to suffer for more long years. No wonder the From-munging
>> proponents are rejoicing!
>> 
>> If this goes in, at least something has to be done to reduce bounces,
>> such as:
>> 
>> — Section 8.3 —
>> 
>> ADD
>> The Mail Receiver MUST reject with "silent discard" when rejecting
>> messages with a List-Id header.
>> END
>> 
>> That way, each party's choices will mostly impact their own messages.
>> Mailing list operators can then take a step back, undo any ugly
>> workarounds, and let DMARC participants decide between themselves, on a
>> case by case basis, how they solve *their* deliverability problems.
>> 
>> Cheers,
>> Baptiste
>> 
>> Le 06/07/2023 à 16:55, Barry Leiba a écrit :
>>> I had some off-list discussions with Seth, who was very much against
>>> my original proposed text, and he suggested an alternative
>>> organization that would be more palatable to him.  I've attempted to
>>> set that out below.  The idea is to remove the normative requirements
>>> about using p=reject from Sections 5.5.6 and 5.8, and instead put a
>>> broader discussion of the issues, along with the normative
>>> requirements, into a new "Interoperability Considerations" section.
>>> This makes it explicitly clear that any MUST/SHOULD stuff with regard
>>> to using and honoring p=reject is an issue of interoperating with
>>> existing Internet email features.  I can accept that mechanism also,
>>> and so, below is my attempt at writing that proposal up.
>>> 
>>> Barry
>> 
>> 
>> ___
>> 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



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

Re: [Ietf-dkim] DMARC's auth=dkim+spf tag

[Hector Santos]

> On Jul 3, 2023, at 10:06 AM, Barry Leiba  wrote:
> 
>> Anyway, discussing whether spf+dkim verification can mitigate DKIM replay
>> belongs to the ietf-dkim list.  (In case, it could also be expressed outside
>> DMARC, for example by an additional DKIM tag.)
> 
> I do agree with this, yes.
> 

+1

There may be additional integrated protocol considerations for ESMTP, SPF and 
DKIM that may go beyond what DMARCbis is willing to consider.

—
HLS








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

Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

[Hector Santos]

A small follow up about my DMARC view:

> On Jun 30, 2023, at 4:02 PM, Hector Santos 
>  wrote:
> 
> Overall, imo, it is never a good idea to exerted changes on domains with bis 
> specs, requiring them to change their current DMARC record to reinforce the 
> security level they want using SPF in DMARC evaluation. 
> 


I don’t want surprises. Higher support cost.   But is DMARC that “messed up?”   
I mean, just like ADSP, it is abandonment material, honestly, easy.

But DMARC is big and it did one thing for the mail industry — the Lookup added 
to the SMTP process.  Moat SMTP receivers will do the the _dmarc.from-domain 
lookup.

DMARC is the #1 lookup record for this purpose,  a DKIM Policy Model.

We said very early on that but will take a while to get traction for a DKIM 
Policy model where lookups come with a good payoff, otherwise it is just wasted 
calls. 

Let’s leverage the lookup using a protocol language for a wide security 
coverage that offers dynamic rejection to clean the mail stream before passing 
it to local proprietary reputation databases.

Happy July 4th, Be safe.

—
HLS

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

Re: [dmarc-ietf] Idle Musings - Why Is It DMARC and not DMARD?

[Hector Santos]

Great question.

I’ve been around since the beginning as a very strong DKIM Policy advocate, 
watching everything, my dumb attempt to summarize:

1) The idea of “reporting” was considered a testing thing.  Redundant,. 
DomainKeys and DKIM had -t test keys.  I believed and others as well, felt 
reporting was an attack vector. I included reporting ideas in DSAP but the 
format was not defined. The section was left TBD.

2) Murray was working on reporting methods with a format.  He was obviously 
filling a need out there.

3) I did not hear of anyone honoring ADSP rejects because of the known indirect 
mail problems.

4) ADSP was abandoned and replaced with Super ADSP aka DMARC which introduced a 
reporting and compliance concept.  It had a strong policy idea.

5) I totally under estimated the administrator direct for reports.  But I still 
didn’t believe it in.  It’s for testing only, right? 

6) I did not hear of anyone rejecting on DMARC p=reject. So it was just about 
Reporting & Conformance.

7) Then YAHOO.COM , the patented inventor of this all this 
starting with DomainKeys, the first with a built-in `o=` tag policy concept, 
was the first big system to honor published DMARC strict policies.

8) Now DMARC become about Handling and proper SMTP integration with SPF.

The end!

Happy July 4th Weekend. Be safe!!

—
HLS




> On Jun 30, 2023, at 2:22 PM, Todd Herr 
>  wrote:
> 
> Genuine curiosity question here for those who were around at the beginning...
> 
> Why is the mechanism called "Domain-based Message Authentication, Reporting, 
> and Conformance" and not "Domain-based Message Authentication, Reporting, and 
> Disposition"? Perhaps a better question, why is "conformance" in the name of 
> the mechanism?
> 
> I ask because I'm writing up some stuff for internal use, and I got curious 
> as to how conformance is defined or explained in RFC 7489, and well, it's 
> not. The word appears five times in RFC 7489, and each occurrence is in the 
> context of spelling out the full name of the mechanism.
> 
> I am not looking to change the name of the mechanism; I'm just genuinely 
> curious how the name was arrived at.
> 
> -- 
> Todd Herr  | Technical Director, Standards & Ecosystem
> e: todd.h...@valimail.com 
> p: 703-220-4153
> 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] easier DKIM, DMARC2 & SPF Dependency Removal

[Hector Santos]

> On Jun 30, 2023, at 3:32 PM, Murray S. Kucherawy  wrote:
> 
> On Fri, Jun 30, 2023 at 12:21 AM Jan Dušátko 
> mailto:40dusatko@dmarc.ietf.org>> 
> wrote:
>> Scott, Barry,
>> as far as I understand, SPF are historic technology,
> 
> Not in any official capacity.  RFC 7208 is a Proposed Standard.  In fact, in 
> IETF terms, it enjoys higher status than DMARC does right now.
> 
> The status of these protocols is not under discussion.  The only question is 
> whether DMARC should continue to factor SPF results into its output.


If I am reading the group right, using the suggested `auth=` tag for 
explanation, it appears the editor wants the new DMARCbis default to be:

auth=dkim

And it would required an explicit tag like;

auth=spf,dkim

to express a desire for spf to be in the evaluation.  This offers DMARCbis 
backward compatibility.   This would be the one “upgrade” change a domain would 
need to make, an optional “extended behavior” to make it behave like DMARC 
today.  The default behavior today is auth=spf,dkim.  DMARCbis’s default would 
be auth=dkim.

I am saying it sounds like this.  

Overall, imo, it is never a good idea to exerted changes on domains with bis 
specs, requiring them to change their current DMARC record to reinforce the 
security level they want using SPF in DMARC evaluation. 

—
HLS

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

Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

[Hector Santos]

Doug,  this is Wildcat! SMTP - one of the oldest SMPT packages around. Summary 
here:

Without some signal at wcSMTP about DMARC,  SPF will most likely remain a hard 
rejection at WCSAP/SMTP (at RCPT state) before DMARC at DATA

Background:

Since 2003, out of the box, Wildcat! SMTP with add-on tools, wcSAP and wcDKIM, 
the mail flow is:

(Note: for the record, email is a small part of winserver.com, but a supportive 
part for many customer operations)

At SMTP, starting with remote client connection:

1) If Enabled, Check for DNS-RBL IP check, respond at step 8 in order to 
collect envelope data.
2.0) Check for smtpfilter-connect.wcx script, run it if found
2.1) Check for Geo-Location IP Blocks, very unethical practice.
3) HELO/EHLO: Check EHLO/HELO on technical merit like IP Literal matching 
Connect IP (CIP)
4) MAIL FROM: Check for Local domain MAIL FROM spoof
5) MAIL FROM: Accept 250 pending RCPT validation
6) RCPT TO: not valid 550 
7) RCPT TO: Valid starts WCSAP.WCX (p-code) Wait for Response.

At WCSAP (Wildcat! Sender Authorization Protocol):

8)  WCSAP: Record if DNS-RBL IP blocked at 1, exit response 55z
9) WCSAP: Run sysop-defined text-based simple White/Block Accept/Reject If rules
10) WCSAP: Run SPF.  Failure return 55z or 45z
11) WCSAP: Run CBV,  Failure return 55z or 45z
12) WCSAP: return 250

Back to WCSMTP RCPT state

8) RCPT response provided, reject 55z/45z or 250 continue, Receiver-SPF header 
prepended.
9) DATA is transferred, Received: trace line prepended.
10 Before DATA response, run stack of SMTP mail filters written in-house or 3rd 
party:

At  SMTPFILTER-xxx.wcx, specifically SMTPFILTER-DKIM-VERIFY.WCX

11) Check for ADSP + ATPS
12) Check For DMARC + ATPS
13) Record Authentication-Results
14) DMARC Rejection Failures are DISABLED. Auth-Res Prepended.
15) Return any 55z, 45z or 250 based on SMTPFILTER-,wcx filters.

Back to DATA, 

16) DATA response is provided.
17) 250 mail is accepted, router signaled for MDA import or MTA forwarding.
18) Wait 30 seconds for client new transaction command, QUIT and/or DROP

Pretty much it.  

We have too much invested in our integrated Wildcat! Internet Net Server mail 
platform — one of the oldest platforms since the 80s. 

My long time customers, sysops, sysadms, love the flexibility and  p-code and 
low code programmability for operators and 3rd party developers!  

I have provided the DMARC option to the SMTPFILTER-DKIM-VERIFY.WCX to return 
55z response for DMARC p=reject but it is compiler disabled.  However, anyone 
can write a new mail filter script to run at DATA for DMARC, but it has yet to 
happen.  Not surprise there.   If we don’t provide it, I don’t expect them to 
do it.

In WCSAP, the SPF handling of the result can be set to not reply with 55z for a 
SPF hard failure.  

This will allow SMTPFILTER-DKIM-VERIFY.WCX to see a SPF=fail Received-SPF 
header. But at the moment, out of the box, DMARC will never see a SPF reject.

From an innocent IETF implementor, my integration enhancement for DMARC might 
be:

With SUBMITTER enabled, you will MOST DEFINITELY see this from supportive 
clients:

C: MAIL FROM: SUBMITTER=pra 

where pra is Purported Responsible Address, normally 5322.From,  Low volume or 
not, you will see it.

I plan to use the PRA to get DMARC information. 

First I will assume the signer is aligned so the next check is for return-path 
alignment.  

Second, if auth=dkim tag exist,  I could offer an option to relax SPF in both 
WCSAP.WCX and SMTPFILTER-DKIM-VERIFY.WCX.

Without some signal at wcSMTP about DMARC,  SPF will most likely remain a hard 
rejection at WCSAP/SMTP (at RCPT state) before DMARC at DATA.

—
HLS

> On Jun 27, 2023, at 7:58 AM, Douglas Foster 
>  > wrote:
> 
> Ale, here is an attempt at a formal model.   Application to the current 
> question is at the very end.
> 
> Any test (DKIM, SPF, ARC) has these result possibilities:
> Pass
> No data or uncertain result
> Fail
> 
> The test results are imperfect, so we have to consider these probabilities
> 
> Probability that PASS is a correct result
>Probability that a false PASS will be whitelisted or not blocked in 
> content filtering
>  Net result that a false PASS is delivered to the user
> 
> Probability that a NoData / Uncertain result is correct (presumed 100%).
>   Probability that an Uncertain message is wanted or unwanted.
>   Probability that an unwanted message is or is not blocked by 
> content filtering
>Net probability that an unauthenticated and unwanted message 
> is delivered to the user
> 
> Probability that FAIL is a correct result
>   Probability that a FAIL result is blocked by local policy (presumed 
> 100%)
>Probability that a false FAIL is actually wanted
>   Net probability that false FAIL blocks a wanted message
> 
> My strategy is documented in my "Best Practices" draft submission.   To 
> 

Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

[Hector Santos]

+1

> On Jun 27, 2023, at 11:06 AM, Tobias Herkula 
>  wrote:
> 
> Signing That, nothing to add.
> 
> -Original Message-
> From: dmarc  On Behalf Of Barry Leiba
> Sent: Tuesday, June 27, 2023 4:24 PM
> To: Alessandro Vesely 
> Cc: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal
> 
> I don't understand how most of your message fits into this discussion:
> you're comparing SPF's policy points with DMARC policy.  we're talking about 
> SPF as an authentication mechanism together with DKIM (not
> DMARC) as an authentication mechanism... and then using those authentication 
> results in DMARC policy evaluation.
> 
> But here: I've said all this before in separate places, so I'll put it in one 
> place, here, one more time:
> 
> Given that SPF and DKIM are both configured properly:
> 1. If SPF passes, DKIM will always pass.
> 2. If DKIM fails, SPF will always fail.
> 3. In some scenarios, DKIM will pass when SPF fails.

Yes, since SPF comes first, by far, in my empirical field experience, if SPF 
fails, odds are good DKIM will fail.   But if DKIM passes, then it can be 
interesting to see if this can fix a false positive with SPF.

—
HLS

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

Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

[Hector Santos]

Since 2003, here is my out of the box, Wildcat! SMTP with wcSAP and wcDKIM 
add-on support, mail flow: 

(Note: for the record, email is a small Part, but a supportive part for many 
customer operations)

At SMTP, starting with connection

1) If Enabled, Check for DNS-RBL IP check, respond at step 8
2.0) Check for smtpfilter-connect.wcx script, run it if found
2.1) Check for Geo-Location IP Blocks, very unethical practice.
3) HELO/EHLO: Check EHLO/HELO on technical merit like IP Literal matching 
Connect IP (CIP)
4) MAIL FROM: Check for Local domain MAIL FROM spoof
5) MAIL FROM: Accept 250 pending RCPT validation
6) RCPT TO: not valid 550 
7) RCPT TO: Valid starts WCSAP.WCX (p-code) Wait for Response.

At WCSAP:

8)  WCSAP: Record if DNS-RBL IP blocked at 1, exit response 55z
9) WCSAP: Run sysop-defined text-based simple White/Block Accept/Reject If rules
10) WCSAP: Run SPF.  Failure return 55z or 45z
11) WCSAP: Run CBV,  Failure return 55z or 45z
12) WCSAP: return 250

Back to WCSMTP RCPT state

8) RCPT response provided, reject 55z/45z or 250 continue, Receiver-SPF header 
prepended.
9) DATA is transferred, Received: trace line prepended.
10 Before DATA response, run stack of SMTP mail filters written in-house or 3rd 
party:

At  SMTPFILTER-xxx.wcx, specifically SMTPFILTER-DKIM-VERIFY.WCX

11) Check for ADSP + ATPS
12) Check For DMARC + ATPS
13) Record Authentication-Results
14) DMARC Rejection Failures are DISABLED. Auth-Res Prepended.
15) Return any 55z, 45z or 250 based on SMTPFILTER-,wcx filters.

Back to DATA, 

16) DATA response is provided.
17) 250 mail is accepted, router signaled for MDA import or MTA forwarding.
18) Wait 30 seconds for client new transaction command, QUIT and/or DROP

Pretty much it.  

We have too much invested in the integrated Wildcat! Internet Net Server 
platform — one of the oldest platforms since the 80s.

My long time customers, sysops, sysadms, love the flexibility and  p-code and 
low code programmability for 3rd party developers!  

I have provided the DMARC option to the SMTPFILTER-DKIM-VERIFY.WCX to return 
55z response for DMARC p=reject but it is compiler disabled.  However, anyone 
can write a new mail filter script to run at DATA for DMARC, but it has yet to 
happen.  Not surprise there.   If we don’t provide it, I don’t expect them to 
do it.

In WCSAP, the SPF handling of the result can be set to not reply with 55z for a 
SPF hard failure.  

This will allow SMTPFILTER-DKIM-VERIFY.WCX to see a SPF=fail Received-SPF 
header. But at the moment, out of the box, DMARC will never see a SPF reject.

From an innocent IETF implementor, my integration enhancement for DMARC might 
be:

With SUBMITTER enabled, you will MOST DEFINITELY see this from supportive 
clients:

C: MAIL FROM: SUBMITTER=pra 

where pra is Purported Responsible Address, normally 5322.From,  Low volume or 
not, you will see it.

I plan to use the PRA to get DMARC information. 

First I will assume the signer is aligned so the next check is for return-path 
alignment.  

Second, if auth=dkim tag exist,  I could offer an option to relax SPF in both 
WCSAP.WCX and SMTPFILTER-DKIM-VERIFY.WCX.

Without some signal at wcSMTP about DMARC,  SPF will most likely remain a hard 
rejection at WCSAP/SMTP (at RCPT state) before DMARC at DATA.

—
HLS

> On Jun 27, 2023, at 7:58 AM, Douglas Foster 
>  wrote:
> 
> Ale, here is an attempt at a formal model.   Application to the current 
> question is at the very end.
> 
> Any test (DKIM, SPF, ARC) has these result possibilities:
> Pass
> No data or uncertain result
> Fail
> 
> The test results are imperfect, so we have to consider these probabilities
> 
> Probability that PASS is a correct result
>Probability that a false PASS will be whitelisted or not blocked in 
> content filtering
>  Net result that a false PASS is delivered to the user
> 
> Probability that a NoData / Uncertain result is correct (presumed 100%).
>   Probability that an Uncertain message is wanted or unwanted.
>   Probability that an unwanted message is or is not blocked by 
> content filtering
>Net probability that an unauthenticated and unwanted message 
> is delivered to the user
> 
> Probability that FAIL is a correct result
>   Probability that a FAIL result is blocked by local policy (presumed 
> 100%)
>Probability that a false FAIL is actually wanted
>   Net probability that false FAIL blocks a wanted message
> 
> My strategy is documented in my "Best Practices" draft submission.   To 
> summarize my experience:
> - The frequency of a true PASS is high, so the probability of a false PASS is 
> low
> - The probability of a false PASS being detected by content filtering is 
> pretty good.
> - The frequency of a true FAIL is low, so the probability of a false FAIL is 
> high.
> - Uncertain messages have a high percentage of unwanted messages, but also a 
> non-trivial volume of wanted messages.
> 

Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

[Hector Santos]

> If the DMARC spec makes that clear, I think we win.  And recipients
> can still do what they want: if DMARCbis goes out with "use DKIM only"
> and a recipient wants to use SPF anyway, they can do that... just as a
> recipient that decides to use best-guess-SPF in the absence of actual
> SPF records is free to make that choice.

When said that way, I believe that requires a version bump v2 which would 
inherently means “use DKIM only,"

So supporters all do a version check:


   bUseDKIMOnly =  (DMARC[“v=“] == “DMARC2”)?1:0


And the new supporter will use the flag bUseDKIMOnly throughout its current 
DMARC1 evaluation accordingly.  

Or via “Add-on” tag extension:

   bUseDKIMOnly =  (DMARC[“auth="] == “dkim”)?1:0

Six in one, Half Dozen of the other?

The problem is that there are implementations that do check for v=DMARC1 and 
will not required DMARC2 as a valid record when in fact a DMARC2 record exist 
whose only purpose in life was to signify a relaxed DMARC1 evaluation regarding 
SPF.

I like the tag extension instead.  Make coding life easier, I think.   But if  
v=DMARC2 is the way Levine wishes to go, I’m ok.  I see issues with just 
changing the inherent behavior without any protocol negotiating signals.

—
HLS


 



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

Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

[Hector Santos]

Alessandro,  I believe we are on the same wave.  I support the DMARC1 tag 
extension `auth=‘ idea.   Do you have any suggestions for the text?  

Technically we don’t need DMARC1-Bis.   That document can move forward as is 
and a new draft proposal I-D called “DMARC1-EXTENSION-AUTH” can be written for 
relaxing the original DMARC1 (RFC 7489) and also the current DMARC1-bis.

—
HLS

> On Jun 24, 2023, at 12:17 PM, Alessandro Vesely  wrote:
> 
> On Fri 23/Jun/2023 20:13:27 +0200 Hector Santos wrote:
>>> On Jun 23, 2023, at 12:52 PM, John R Levine  wrote:
>>> On Thu, 22 Jun 2023, Emanuel Schorsch wrote:
>>>> I agree with John's point that dkim+spf doesn't make sense in the context
>>>> of strict DMARC enforcement (I think it provides value for p=none domains
>>> Since the aggregate reports tell you what authentication worked, I don't 
>>> even see that as a benefit.  There's also the question how many people 
>>> would even look at a DMARC v2 tag which would be a prerequisite for the 
>>> auth tag.
>> DMARC v1 supports extended tags.  See section 3.1.3 in RFC 7489:
>> 3.1.3 <https://datatracker.ietf.org/doc/html/rfc7489#section-3.1.3>.  
>> Alignment and Extension Technologies
>>If in the future DMARC is extended to include the use of other
>>authentication mechanisms, the extensions will need to allow for
>>domain identifier extraction so that alignment with the RFC5322 
>> <https://datatracker.ietf.org/doc/html/rfc5322>.From
>>domain can be verified.
> 
> 
> Eh?  Dkim+spf wouldn't be a new mechanism, as the domain identifier would 
> have to be the same.  I'd have cited 6.3:
> 
> 6.3.  General Record Format
> https://datatracker.ietf.org/doc/html/rfc7489#section-6.3
> 
>   Section 11 creates a registry for known DMARC tags and registers the
>   initial set defined in this document.  Only tags defined in this
>   document or in later extensions, and thus added to that registry, are
>   to be processed; unknown tags MUST be ignored.
> 
> Of course, there will be lots of verifiers who ignore auth=, t=, and ed25519. 
> Unfortunately, while we have so many blog posts, we're still missing DMARC 
> verifier checks.
> 
> 
>>> The idea is that auth=dkim means you'd publish SPF records but hope people 
>>> will ignore them, or vice versa for auth=dkim?  I still don't get it.
>> The immediate benefit would be forwarders. I believe Wei labeled this form 
>> of forwarding REM in the PDF analysis posted recently.
>> With REM forwarders, in SMTP transport terms, it is a passthru message 
>> forwarded to a recorded address given by the local domain or locally hosted 
>> domain Recipient , untouched data.  MTA inbound to MTA outbound. The MDA, 
>> like gmail.com <http://gmail.com/>, would see an SPF failure so the DMARC 
>> auth=dkim relaxed option tells GMAIL that the hard fail with SPF is 
>> acceptable, ignore it, but expect the DKIM to be valid from the author 
>> signer domain.
> 
> 
> SPF hard fail is acceptable even with the default auth=.  (SPF hard fail is a 
> problem for those who reject before DATA.  Receiving MXes have no DKIM clue 
> at that stage.  The only way forwarding might work without replacing the 
> bounce address is if either the receiver or the SPF record provide for 
> whitelisting. As a side note, let me add that I'm rejecting way more spam 
> thanks to spf-all than DMARC and DNSBL together.)
> 
> The auth=dkim (excluding SPF) setting is needed by domains who /have/ to 
> include a bloated SPF record in order to deliver at sites which only verify 
> that.  However, since the bloated record allows impersonation, they don't 
> want that DMARC verifiers consider it.  They probably wish that everybody 
> used DMARC so that they could avoid publishing an SPF record, but there's not 
> much they can do about it.
> 
> 
> Best
> Ale
> -- 


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

Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

[Hector Santos]

On Jun 23, 2023, at 1:54 PM, John R Levine  wrote:
> 
>> My understanding is that if `auth=dkim` then SPF would be ignored from the
>> perspective of DMARC. So  if a receiver sees DKIM is not DMARC aligned and
>> only SPF is DMARC aligned then it would still be treated as a DMARC fail.
> 
> That's my understanding.
> 
>> It would be a way for senders to say "yes I checked that all my DKIM
>> signatures are working and aligned, I don't need you to look at SPF and
>> don't want to have the risk of SPF Upgrades.
> 
> So why do you publish an SPF record?  Presumably so someone will accept your 
> mail who wouldn't otherwise, except you just said they shouldn't. Still not 
> making sense to me.

I believe because the domain may still want the restrictive SPF -ALL  and DMARC 
p=reject or p=quarantine for normal direct messages but they recognize users 
will be contacting people where a SPF will fail due to a forward.

If you remove the SPF record or weaken it with ~ALL or ?ALL, then it weakens 
the majority of non-forwarded direct transactions. The proposed tag `auth=dkim` 
will indicate to gmail that SPF failing is ok as long as the first party DKIM 
signature is still intact.   It’s weaker but would be less problematic than it 
is today.

Today, we can modify the return path for the forward or don’t allow for forward 
and make the (gmail) user pick up the mail via POP3/IMAP.  No forwarding.

—
HLS

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

Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

[Hector Santos]

> On Jun 23, 2023, at 12:52 PM, John R Levine  wrote:
> 
> On Thu, 22 Jun 2023, Emanuel Schorsch wrote:
>> I agree with John's point that dkim+spf doesn't make sense in the context
>> of strict DMARC enforcement (I think it provides value for p=none domains
> 
> Since the aggregate reports tell you what authentication worked, I don't even 
> see that as a benefit.  There's also the question how many people would even 
> look at a DMARC v2 tag which would be a prerequisite for the auth tag.

DMARC v1 supports extended tags.  See section 3.1.3 in RFC 7489:

https://datatracker.ietf.org/doc/html/rfc7489#section-3.1.3



3.1.3 .  Alignment 
and Extension Technologies

   If in the future DMARC is extended to include the use of other
   authentication mechanisms, the extensions will need to allow for
   domain identifier extraction so that alignment with the RFC5322 
.From
   domain can be verified.





> 
> The idea is that auth=dkim means you'd publish SPF records but hope people 
> will ignore them, or vice versa for auth=dkim?  I still don't get it.
> 

The immediate benefit would be forwarders. I believe Wei labeled this form of 
forwarding REM in the PDF analysis posted recently.

With REM forwarders, in SMTP transport terms, it is a passthru message 
forwarded to a recorded address given by the local domain or locally hosted 
domain Recipient , untouched data.  MTA inbound to MTA outbound. The MDA, like 
gmail.com , would see an SPF failure so the DMARC auth=dkim 
relaxed option tells GMAIL that the hard fail with SPF is acceptable, ignore 
it, but expect the DKIM to be valid from the author signer domain.

Who sets this tag?  The initial sender that unbeknownst to this sender, the MX 
Is not the final MDA.  We will never know that information of where a contact 
can be reached.  The Hosted Domain market is very big and important.

So it will be a matter of training system admins that domains with any chance 
of being indirect, it will probably be a good idea to use a relaxed SPF 
evaluation for DMARC1.

We will not need a version bump. 

—
HLS



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

Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

[Hector Santos]

Levine makes a good point. A less complex option would be:

auth=dkim  # apply dkim only, ignore spf, dkim failure is 
dmarc=fail
auth=spf# apply spf only, ignore dkim, spf failure is 
dmarc=fail


the default auth=dkim,spf SHOULD NOT be explicitly be required. It 
adds no additional security value.  I would like to note that some DNS 
Zone Managers with DMARC record support will add the complete tags 
available for the protocol with the default conditions making the 
record look more complex than it really it.


Other system integration options would (forgive me for I have sinned):

atps=1 # we support ATPS protocol for 3rd party signer.
rewrite=1  # we are perfectly fine with Author Rewrite

--
HLS





On 6/22/2023 10:18 PM, John Levine wrote:

It appears that Emil Gustafsson   said:

I don't know if there is a better way to encode that, but I'm supportive of
making a change that that would allow domains to tell us (gmail) that they
prefer us to require both dkim and spf for DMARC evaluation (or whatever
combination of DKIM and SPF they desire).

I really don't understand what problem this solves. More likely people
will see blog posts telling them auth=dkim+spf is "more secure",
they'll add that without understanding what it means, and all that
will happen is that more of their legit mail will disappear.

If you're worried about DKIM replay attacks, let's fix that rather
than trying to use SPF, which as we know has all sorts of problems of
its own, as a band-aid.

R's,
John

___
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] easier DKIM, DMARC2 & SPF Dependency Removal

[Hector Santos]

> On Jun 22, 2023, at 9:54 AM, Scott Kitterman  wrote:
> 
> My conclusion (it won't surprise you to learn) from this thread is precisely 
> the opposite.  
> 
> In theory, DKIM is enough for DMARC (this was always true), but in practice 
> it 
> is not.
> 
> I don't think there's evidence of a systemic weakness in the protocol.  We've 
> seen evidence of poor deployment of the protocol for SPF, but I think the 
> solution is to fix that (see the separate thread on data hygiene).
> 
> Scott K
> 

Scott, this all started as a way to add weight to a SPF=SOFTFAIL using ADSP.  
Microsoft started it and DMARC came out with a surprising even tighter rule for 
DKIM+SPF alignment.

SPF rejects immediately issued an 55z the transaction, confused DMARCers.  
Let’s keep in mind SPF pre-dated DMARC.

SPF softfail results were interesting to see how a DKIM signature may help.  
Microsoft’s idea before DMARC.

Overall, DMARC created a Link with SPF that wasn’t thoroughly reviewed with the 
IETF.  It skipped the process as an Informational proposal.  Now as a standard 
track DMARCbis, we see all the problems. 

How is this problem fixed with client/server protocol negotiating software?

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

Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

[Hector Santos]

> On Jun 22, 2023, at 1:08 PM, Barry Leiba  wrote:
> 
>> I concur that this isn't really a problem for either working group to solve 
>> as part of a standard,
> 
> Well, the part that the working group needs to solve is whether the
> challenges of getting DKIM right are such that we need to retain SPF
> to fill that gap, or whether the issues with relying on SPF are more
> significant.  I think that's an important part of the decision we're
> discussing, and will be a significant part of judging consensus on
> that discussion.
> 
> Barry, as chair
> 

Barry, this is obviously a new relaxation option.  From a mail system 
integration standpoint, the options are:

1) A version bump to DMARC2 with new semantics with backward DMARC1 
compatibility, or

2) Use a DMARC1 Extended tag option allowed by DMARC1.   Alessandro cited an 
excellent backward compatible extended tag option:

auth=dkim|spf (default value), auth=dkim+spf, auth=dkim, auth=spf

Of course, this would need to be discussed and I know Levine see this is too 
late for DMARCbis, but in my opinion,  Why the rush?  IETF San Fran next month?

DMARCBis is highly contentious and remains problematic. You know whats 
happening. I put my IETF faith in you.

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

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

[Hector Santos]

> On Jun 17, 2023, at 9:50 PM, John Levine  wrote:
> 
> It appears that Hector Santos   said:
>>> Can these senders not accomplish the same thing by removing the SPF record 
>>> altogether?
>>> 
>>> -MSK, participating
>> 
>> 
>> Isn’t SPF, DKIM and alignment are all required for DMARC1 passage? Failure 
>> if any are missing?
> 
> No, that has never been the case.  Please reread RFC 7489.
> 



Everything in that doc, all angles of reading this Informational Status RFC 
suggest SPF is a natural part of the DMARC consideration.  

A domain with a DMARC1 record is expected to have SPF and DKIM.  The 
authenticated identifiers need to be aligned as well. The DMARC1 policy define 
how failures are handled.  If the policy p=none allows for failures by not 
having a SPF record, I would agree that would be technically true but not all 
receivers behave the same.With restrictive DMARC policies. SPF is pretty 
much required.  Senders risked failures by receivers who may applied it 
inconsistently. 

Section 4.3 has items 1,6, 7 and 8 describing SPF as a factor  in the 
established procedure and flow and consideration in policy result evaluation. 

Let’s consider the huge industry DMARC marketing as well where SPF, DKIM are 
described as necessary email security preparation for  DMARC.

The section 10.1, 2nd para confirms my main point that SPF may be processed 
separately for reject (-all)  results preempting payload processing:


   Some receiver architectures might implement SPF in advance of any
   DMARC operations.  This means that a "-" prefix on a sender's SPF
   mechanism, such as "-all", could cause that rejection to go into
   effect early in handling, causing message rejection before any DMARC
   processing takes place.  Operators choosing to use "-all" should be
   aware of this.


Anyway, I support removing SPF from the DMARCbis or DMARC2 evaluation.  Section 
10.1 2nd para semantics need to remain.

Thanks

—
HLS




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

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

[Hector Santos]

> On Jun 17, 2023, at 8:41 PM, Murray S. Kucherawy  wrote:
> 
> On Sat, Jun 17, 2023 at 2:40 PM Ken Simpson  > wrote:
>> FWIW, I'd like to chuck my hat in the ring on the side of removing SPF from 
>> the next iteration of DMARC. As the operator of an email delivery service 
>> with tens of millions of primarily uncontrolled senders on web hosting 
>> servers, it would be great if domain owners could assert via their DMARC 
>> record that receivers should only trust DKIM-signed email.
> 
> Can these senders not accomplish the same thing by removing the SPF record 
> altogether?
> 
> -MSK, participating


Isn’t SPF, DKIM and alignment are all required for DMARC1 passage? Failure if 
any are missing?

Even then, with no SPF, what would remain for a reduced DMARC2 requirement is a 
1st party DKIM signature only.  No 3rd party. When we resolve this part, “I can 
die and finally go to heaven."

Note, from my pov, SPF was always separate from any payload DKIM-based policy 
protocol process because there are receivers who will reject at SMTP before 
DATA or DMARC consideration. For these optimized systems, DMARC would only ever 
see a SPF = pass, softfail, neutral or none/unknown but never a spf=reject 
unless the implementation delayed SPF rejects until DMARC can be processed.

—
HLS

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

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

[Hector Santos]

> On Jun 12, 2023, at 6:02 PM, Jim Fenton  wrote:
> 
> On 9 Jun 2023, at 22:35, Murray S. Kucherawy wrote:
> 
>> 
>> You were previously talking about inserting ">" before a line starting
>> "From ", which is typically done on delivery when writing to an
>> mbox-formatted mailbox file, because in that format, "From " at the front
>> of a line has a specific meaning (i.e., "this is a new message").  If that
>> insertion is happening in transport, then a local mailbox convention is
>> leaking out into the transport environment, which means something is
>> misconfigured, and all bets are off.
>> 
>> In any case, it is not a transport conversion anticipated by the section
>> you're quoting, so I've no idea why a DKIM signer might opt to handle it
>> specially.
> 
> I’m not as definite that this is a misconfiguration, but might be a 
> historical artifact.

Very historic - UUCP days and it didn’t come with the “>” prefix. Thats 
something new to perhaps mask and avoid stripping at the MDA.




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

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

[Hector Santos]

Barry,

Whoa! Take it easy.  

We are on the DMARC2 thread per topic - a proposal. Not anything for the 
current DMARCbis. 

Is the chair suggesting the current charter for DMARCbis should change to 
remove SPF? Was the charter changed for this?

To be clear, DMARC2 is not DMARCbis right now, are you wishing this now?

Hector


> On Jun 9, 2023, at 8:27 PM, Barry Leiba  wrote:
> 
> Hector, did you not understand this?:
> 
>>> We will *not* consider what should happen to
>>> SPF outside of DMARC, and any discussion of that is *out of scope* for
>>> this working group under its current charter.
> 
> Please stop discussing it.
> 
> Barry
> 
> On Fri, Jun 9, 2023 at 8:23 PM Hector Santos  wrote:
>> 
>>> On Jun 9, 2023, at 4:41 AM, Barry Leiba  wrote:
>>> 
>>> Repeating this one point as chair, to make it absolutely clear:
>>> 
>>> The proposal we're discussing is removing SPF authentication from
>>> DMARC evaluation *only*.  We will *not* consider what should happen to
>>> SPF outside of DMARC, and any discussion of that is *out of scope* for
>>> this working group under its current charter.
>>> 
>>> Barry, as chair
>> 
>> For the record,  from a long time SMTP implementer standpoint, DMARC would 
>> be ignored, dropped, turned off, etc first before any consideration to stop 
>> SPF support.   As a Transporter, SPF works. As an Administrator - ADSP, I 
>> mean “Supper ADSP” aka DMARC has been horrible.  I, and most people, could 
>> easily deprecate Wildcat! DMARC with no harm and fact, less harm because the 
>> false positives will disappear.  My product add-on for wcSMTP, wcDMARC, 
>> never did honor the p=reject|quarantine. It was left for filters and no one 
>> hard any confidence to make it work.
>> 
>> SPF on the other hand, I don’t see dropped in the name of DMARC.  So if it’s 
>> about sparate, but not abandon, that I can support - because it is already 
>> separate.  SPF preempts DMARC or any Payload protocol..
>> 
>> Thanks
>> 
> 
> ___
> 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] DMARC2 & SPF Dependency Removal

[Hector Santos]

> On Jun 9, 2023, at 4:41 AM, Barry Leiba  > wrote:
> 
> Repeating this one point as chair, to make it absolutely clear:
> 
> The proposal we're discussing is removing SPF authentication from
> DMARC evaluation *only*.  We will *not* consider what should happen to
> SPF outside of DMARC, and any discussion of that is *out of scope* for
> this working group under its current charter.
> 
> Barry, as chair

For the record,  from a long time SMTP implementer standpoint, DMARC would be 
ignored, dropped, turned off, etc first before any consideration to stop SPF 
support.   As a Transporter, SPF works. As an Administrator - ADSP, I mean 
“Supper ADSP” aka DMARC has been horrible.  I, and most people, could easily 
deprecate Wildcat! DMARC with no harm and fact, less harm because the false 
positives will disappear.  My product add-on for wcSMTP, wcDMARC, never did 
honor the p=reject|quarantine. It was left for filters and no one hard any 
confidence to make it work.

SPF on the other hand, I don’t see dropped in the name of DMARC.  So if it’s 
about sparate, but not abandon, that I can support - because it is already 
separate.  SPF preempts DMARC or any Payload protocol..

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

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

[Hector Santos]

> On Jun 8, 2023, at 10:20 AM, Murray S. Kucherawy  wrote:
> 
> On Thu, Jun 8, 2023 at 6:00 AM Tobias Herkula 
> mailto:401und1...@dmarc.ietf.org>> 
> wrote:
>> My team recently concluded an extensive study on the current use and 
>> performance of DMARC. We analyzed a staggering 3.2 billion emails, and the 
>> insights drawn are quite enlightening. Of these, 2.2 billion emails 
>> (approximately 69%) passed the DMARC check successfully. It's quite an 
>> achievement, reflective of our collective hard work in fostering a safer, 
>> more secure email environment.
>>  
>> 
>> However, upon further analysis, it's evident that a mere 1.6% (or thirty-six 
>> million) of these DMARC-passed emails relied exclusively on the Sender 
>> Policy Framework (SPF) for validation. This is a remarkably low volume 
>> compared to the overall DMARC-passed traffic, raising questions about SPF's 
>> relevancy and the load it imposes on the DNS systems.
>> 
>>  
>> 
>> Given the current use case scenarios and the desire to optimize our 
>> resources, I propose that we explore the possibility of removing the SPF 
>> dependency from DMARC. This step could result in a significant reduction in 
>> DNS load, increased efficiency, and an accurate alignment with our 
>> predominant use cases.
>> 
>> [...]
>> 
> 
> Does anyone have consonant (or dissonant) data? 
> 



Thank you for inviting feedback on Mr. Herkula's interesting DMARC2 proposal, 
focusing on detaching SPF from DMARC's evaluation process. I would like to 
share my thoughts on this matter.

While the principle behind the proposed DMARC2 is valuable, I remain sceptical 
about the effectiveness of separating SPF from DMARC to alleviate DNS load. For 
various reasons, notably the layer issue – SPF being an SMTP protocol rather 
than a payload protocol – SPF is unlikely to be fully discarded.

It's worth recalling that SPF's contribution has served the email community 
well, despite certain node transition issues such as relays and forwards. The 
optional integration of SPF within DMARC1 from the onset might have simplified 
the process, mitigating the challenges associated with the merged results and 
reducing the occurrence of false positives, which in many cases has begun to 
give domains a second thought on using p=reject|quarantine policies. 

A potential DMARC2 proposal should, in my opinion, maintain backward 
compatibility, making SPF an optional requirement.  The real gap with DMARC1 
has been the lack of diversity in policies, and effectively, the DMARC2 
proposal could add a new "policy" that doesn't require SPF evaluation.

For context, we've amassed nearly two decades worth of data on SPF, DKIM, ADSP, 
and DMARC, providing considerable insight into the longevity and effectiveness 
of these measures.

It's crucial to establish that SPF was deliberately designed to, and in many 
cases will, use a HARDFAIL result to preempt payload transfer or its acceptance 
(at DATA). This is precisely why the SUBMITTER add-on ESMTP protocol was 
introduced as part of SenderID – the payload version of SPF – to relay the 
Purported Responsible Address (PRA) at the SMTP MAIL FROM command.

By reviving the SUBMITTER protocol for DMARC purposes, servers/receivers can 
check the DMARC policy at SMTP, offering valuable foresight into the email 
domain's expectations prior to payload delivery. This approach allows for a 
more optimized process, ensuring that SPF is evaluated at MAIL FROM or RCPT TO, 
once the recipient address's acceptability is established per RFC 5321, Section 
3.3 Mail Transactions' recommendations.

It's important to note that SPF-compliant servers – as evidenced recently by 
gmail.com – can reject SPF failures at SMTP independent of DMARC. For domains 
using SPF hard failures (-ALL), DMARC is not mandatory and in many cases, a 
hard SPF policy vs hard  DMARC policies are mutual exclusive.  Odds are good, 
if SPF was disabled, DMARC2 could yield the same way. I suggest that the 
proposed DMARC2 revisit the coupling of SOFTFAIL SPF results with DMARC2 policy 
analysis.  

While DMARC has introduced complexities and some uncertainty, my recent 
analysis reveals that domains without DMARC, but implementing hard SPF 
policies, experienced minimal issues, except for gmail.com domain members. The 
problem appears to be more prominent with ESPs, particularly those with a 
lenient DMARC p=nonen since ESPs with strong policies are restricted from 
subscriptions and submissions.

In conclusion, the evolution to a DMARC2 should focus on addressing these 
concerns, potentially including a "rewrite=1" option to mailing lists with 
appropriate permissions. This could potentially make it more palatable to 
modify the author's address, while respecting the hard-won email security 
principles.

Thanks

---
Hector Santos
Santronics Software,Inc.












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

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

[Hector Santos]

My #1 concern is how the bigger ESP is contributing to the delivery problems, 
causing chaos for business users and customer relationship problems with mail 
hosting provider  I am seeing uncertainty and inconsistency among different 
receivers with ESP gmail.com seems to be the most aggressive and I am seeing 
the bigger ESPs using different methods, including proprietary methods.

As a sideline note, I will venture email overhead has skyrocketed to a new 
level of hard to follow headers for tech support. I don’t think we can continue 
down this path in the name of trying to get DMARC as apart of everyone’s domain 
when in fact, it is unfortunately becoming more apparent, a domain may be is 
better off with no DMARC record, not even p=none may help. Using SPF is good 
enough it seems.

—
HLS

> On Jun 8, 2023, at 11:02 AM, Barry Leiba  wrote:
> 
> I disagree with the premise (the last sentence of your first paragraph).  
> Broken or ineffective authentication is worse than none, because it causes 
> deliverability problems.  I’d rather have no authentication and rely on other 
> means of filtering.
> 
> Barry
> 
> On Thu, Jun 8, 2023 at 3:54 PM Seth Blank  > wrote:
>> Participating, while running around so apologies for terseness:
>> 
>> Sophisticated senders do DKIM. The long tail, we're lucky if they do SPF. 
>> Some authentication is better than none.
>> 
>> The problem isn't people evaluating SPF vs DKIM and choosing the easier 
>> option. It's people who have a business, who bolt on email, and then 
>> struggle to authenticate through any means. Again, we're lucky when we get 
>> SPF from them, and I'll still take that over no auth all day every day.
>> 
>> Don't disagree at all with the myriad problems with SPF, and that the goal 
>> should be to eliminate it. I just don't believe we're anywhere close to that 
>> being a reality yet.
>> 
>> The data that led to DMARC showed that SPF and DKIM were both necessary to 
>> determine legitimacy broadly. What would we need to understand now to see if 
>> only DKIM is necessary?
>> 
>> On Thu, Jun 8, 2023 at 3:44 PM Barry Leiba > > wrote:
>>> See, I don't look at it as "harmed".  Rather, I think they're using "we use 
>>> SPF" as a *reason* not to use DKIM, and I think that *causes* harm.
>>> 
>>> SPF is, as I see it, worse than useless, as it adds no value to domain that 
>>> use DKIM -- any time DKIM fails SPF will also fail -- and actually impedes 
>>> the adoption of DKIM.  Reliance on SPF causes DMARC failures that result in 
>>> deliverability problems for legitimate mail.  I wholeheartedly support 
>>> removal of SPF as an authentication mechanism that DMARC accepts.
>>> 
>>> Barry, as participant
>>> 
>>> On Thu, Jun 8, 2023 at 3:30 PM Seth Blank 
>>> mailto:40valimail@dmarc.ietf.org>> 
>>> wrote:
 Participating, I have data that I believe points to a long tail of 
 businesses who predominantly only authenticate on behalf of others using 
 SPF, and would be harmed by such a change. It will take me a little while 
 to confirm and share.
 
 I also know a predominant ccTLD with millions of registrations, that has 
 SPF on roughly 80% of them, but DMARC on barely 5%. I don't have data on 
 DKIM for those, but I assume it's closer to the DMARC penetration than the 
 SPF one. I'll see if I can get this data to share more publically, and 
 also get the DKIM answer.
 
 Of course the goal is aligned dkim with a stated policy, but I don't think 
 the data supports us being anywhere close to that realistically. 
 
 As Chair, this is a valuable conversation to have with real data on 
 problems and opportunities at scale, and am excited to see Tobias share 
 and see what others have to say.
 
 Seth
 
 On Thu, Jun 8, 2023 at 3:21 PM Murray S. Kucherawy >>> > wrote:
> On Thu, Jun 8, 2023 at 6:00 AM Tobias Herkula 
>  > wrote:
>> My team recently concluded an extensive study on the current use and 
>> performance of DMARC. We analyzed a staggering 3.2 billion emails, and 
>> the insights drawn are quite enlightening. Of these, 2.2 billion emails 
>> (approximately 69%) passed the DMARC check successfully. It's quite an 
>> achievement, reflective of our collective hard work in fostering a 
>> safer, more secure email environment.
>>  
>> 
>> However, upon further analysis, it's evident that a mere 1.6% (or 
>> thirty-six million) of these DMARC-passed emails relied exclusively on 
>> the Sender Policy Framework (SPF) for validation. This is a remarkably 
>> low volume compared to the overall DMARC-passed traffic, raising 
>> questions about SPF's relevancy and the load it imposes on the DNS 
>> systems.
>> 
>>  
>> 
>> Given the current use case scenarios and the desire to 

Re: [dmarc-ietf] Third party signatures

[Hector Santos]

Wei,

Have you studied the past R and functional specifications, 
architectural surrounding SPF and DKIM leading up to DMARC?


   RFC5598  Internet Mail Architecture
   RFC5322  Internet Message Format
   RFC5321  Simple Mail Transfer Protocol
   RFC4405  SUBMITTER SMTP Service Extension
   RFC4406  Sender ID: Authenticating E-Mail
   RFC4407  Purported Responsible Address (PRA)
   RFC4408  Sender Policy Framework (SPF)
   RFC4686  Analysis of Threats Motivating DKIM
   RFC4870  DomainKeys
   RFC4871  DKIM (RFC5672.TXT,  RFC6376.TXT)
   RFC5016  Requirements for a DKIM Signing Practices Protocol
   RFC5451  Message Header Field for Indicating Message 
Authentication Status

   RFC5518  Vouch By Reference
   RFC5585  DKIM Service Overview
   RFC5617  DKIM Author Domain Signing Practices (ADSP)
   RFC5863  DKIM Development, Deployment, and Operations
   RFC5965  An Extensible Format for Email Feedback Reports
   RFC6376  DomainKeys Identified Mail (DKIM) Signatures
   RFC6377  DomainKeys Identified Mail (DKIM) and Mailing Lists
   RFC6541  DomainKeys Identified Mail (DKIM) Authorized Third-Party 
Signatures


I find it technically unfeasible and non-logical to support a high 
overhead, complex ARC concept that has no promise of any solution for 
a DKIM Policy model we have been seeking since 2005.


What are we solving in the first place with ARC?  The ability to 
revert to original integrity due to unknown middle wares changes? What 
ever happen to passthru mail transports?


In my technical view, it has been the PORT 25 unsolicited 3rd party 
signature unauthorized by the author domain due to the dearth of 
scaled AUTHOR::SIGNER Authorization methods.   ARC is not resolving 
this problem. The overhead is horrendous.


We have been seeking deterministic protocols to filter out failures 
with zero to low false positive.  Diffusion by Osmosis!
We don't have it today.   It has been made more complex than it really 
is.   I recommend to study the past work.


Thank you.

--
Hector Santos, CEO/CTO
Santronics Software, Inc.




On 5/15/2023 5:02 AM, Wei Chuang wrote:
That's a good point around ARC as that's what it was meant to do. 
And that got me thinking that it might be helpful to systematically 
compare the different proposed approaches and their pros and cons.  
The next approach would be to consider the general approach of the 
reversible transform idea that several folks have proposed, and how 
that would look.  And that got me rethinking the "DARA" work that 
we're already prototyping for DKIM replay mitigation, if it can 
relate to mailing-list and forwarder modifications and I now think 
DARA can help here too. The three different approaches have distinct 
pros and cons.


The following is a summary of the comparison.  Attached is a more 
detailed comparison as PDF that tries to work through what the 
algorithms would likely do.



ARC

Use ARC to override the SPF and DKIM results at Receiver by those 
found at the Forwarder.


Pros:

 *

Uses existing SPF, DKIM and ARC standards.

 *

Tolerates header and body modifications

Cons:

 *

Receiver must trust the ARC headers generated by the forwarder.

 *

Receiver must trust the modifications the forwarder made.

 *

Receiver must trust that no ARC replay occurred


Transform

Proposed in draft-kucherawy-dkim-transform 
<https://datatracker.ietf.org/doc/draft-kucherawy-dkim-transform/02/>where 
the forwarder can specify a "tf=" tag that specifies addition of 
Subject header prefix, text footer to a mime-part, mimify plaintext, 
and adding a mime-part representing a footer to an existing 
mime-tree to the DKIM-Signature.  These all may be reversed to 
recover the original signature.


DKIM-Signature: d=...; tf=subject,mime-wrap,

The ideas in draft-vesely-dmarc-mlm-transform-07 
<https://datatracker.ietf.org/doc/html/draft-vesely-dmarc-mlm-transform-07>are 
conceptually similar though add support for ARC.


Pros:

 *

Tolerates header and body modifications

 *

Identifies the modifications

 *

Does not require particular trust of the forwarder to be
non-malicious

Cons:

 *

Receiver must trust that no DKIM replay occurred

 *

Might not compose across multiple modifying forwarders

 *

Might not support all possible modifications by forwarder

 *

Reversing all possible draft transformations is potentially
complicated


DARA

This clarifies the DARA ideas in draft-chuang-replay-resistant-arc 
<https://datatracker.ietf.org/doc/draft-chuang-replay-resistant-arc/>which 
calls for authenticating a path from the Originator through the 
Forwarder to the Receiver that's tolerant of modifications.  Some 
ideas of a validated path are explored in 
draft-levine-dkim-conditional 
<https://datatracker.ietf.org/doc/html/draft-levine-dkim-conditional-04>. 



Pros:

 *

Tolerates header and body modifications

 *

Does not require particular tr

Re: [dmarc-ietf] Add MLS/MLM subscription/submissions controls to DMARCbis

[Hector Santos]

Alex,

I agree with a suggestion to have a separate document, a great 
starting point is to update the ATPS RFC document.  However, DMARCbis 
MUST open up the door for it and address the potential new security 
issues with From Rewrite.


1) Address the MUST NOT p=reject with a new small section, a few 
paragraphs citing the basic non-compliance issues with legacy MLS/MLM 
verifiers of not following DMARC policy and instead creating a new 
potential security threat which may required a security threat section 
or add it to the current "Display Attack" security section.  I don't 
believe we can get by this by saying it will "never happen."


2) Update section 4.4.3 Extended Tag Extensions to update the door up 
to 3rd party authorization, ATPS and possibly others.


Thanks

--
HLS



On 5/1/2023 9:49 AM, Brotman, Alex wrote:

This sounds like a separate document to me. (yes, I see Ale's draft below) And 
IMO, I don't think we should hold up DMARCbis for that work.

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


-Original Message-
From: dmarc  On Behalf Of Hector Santos
Sent: Monday, May 1, 2023 9:26 AM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Add MLS/MLM subscription/submissions controls to
DMARCbis

On 5/1/2023 6:51 AM, Alessandro Vesely wrote:

Been there, done that.  For the message I'm replying to, I have:

Authentication-Results: wmail.tana.it;
   spf=pass smtp.mailfrom=ietf.org;
   dkim=pass reason="Original-From: transformed" header.d=google.com;
   dkim=pass (whitelisted) header.d=ietf.org
 header.b=jAsjjtsp (ietf1);
   dkim=fail (signature verification failed, whitelisted)
header.d=ietf.org
 header.b=QuwLQGvz (ietf1)

However, not all signatures can be verified.  Mailman tries and
preserve most header fields, but not all.  For example, they rewrite
MIME-Version: from scratch and don't save the old one.  So if a poster
signs that field and writes it differently (e.g. with a
comment) MLM transformation cannot be undone.
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draf
t-vesely-dmarc-mlm-transform__;!!CQl3mcHX2A!DfPhD9QIFk5QZaU-

JPkz748sZC
QtLXqL1FIxGonW_xDwc9pXdioEnY546GZUnzjzSNW1BdDF27VjLabqZaB5XtMgrS
WZ9HPP

m2s$


And this was my result for your message, separating lines for easier
reading:

Authentication-Results: dkim.winserver.com;
   dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;
   adsp=none author.d=tana.it signer.d=ietf.org;
   dmarc=fail policy=none author.d=tana.it signer.d=ietf.org (unauthorized
signer);

   dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;
   adsp=none author.d=tana.it signer.d=ietf.org;
   dmarc=fail policy=none author.d=tana.it signer.d=ietf.org (unauthorized
signer);

   dkim=fail (DKIM_BAD_SYNTAX) header.d=none header.s=none header.i=none;
   adsp=dkim-fail author.d=tana.it signer.d=;
   dmarc=dkim-fail policy=none author.d=tana.it signer.d= (unauthorized signer);

   dkim=fail (DKIM_BODY_HASH_MISMATCH) header.d=tana.it header.s=delta
header.i=tana.it;
 adsp=dkim-fail author.d=tana.it signer.d=tana.it;
 dmarc=dkim-fail policy=none author.d=tana.it signer.d=tana.it
(originating signer);

Four signatures were added to your submission and the only one that counts is
the top one, the last one added.

It failed DMARC because tana.it did not authorized ietf.org.   You can
easily resolve this by adding atps=y to your DMARC record:

  v=DMARC1; p=none; atps=y; rua=mailto:dmarca...@tana.it;
ruf=mailto:dmarcf...@tana.it;

and add an ATPS sub-domain record authorizing ietf.org in your dana.it
zone:

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

Do that and all ATPS compliant verifiers should show a DMARC=pass:

Authentication-Results: dkim.winserver.com;
   dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;
   adsp=none author.d=tana.it signer.d=ietf.org;
   dmarc=pass policy=none author.d=tana.it signer.d=ietf.org (ATPS signer);


For a short list of signers, I updated my DMARC evaluator to also support ASL
"Authorized Signer List" to avoid the extra ATPS record.
So doing this will work across my evaluator for smaller scale mail senders

  v=DMARC1; p=none; atps=y; asl=ietf.org; rua=mailto:dmarca...@tana.it;
ruf=mailto:dmarcf...@tana.it;


This will skip atps=y because asl=ietf.org was satisfied. It was show
how it was authorized:

   dmarc=pass policy=none author.d=tana.it signer.d=ietf.org (ASL signer);


Any ATPS or ASL idea will give us the author-defined trust of ietf.org
as a 3rd party signer.

That said,  keeping with the suggestion DMARCBis should add MLS/MLM
semantics, I believe when the Receiver is receiving mail for a
MLS/MLM,  it should have the following updated modern consideration
for a MLS/MLM:

1) It should honor policy first, by check for restrictive domains

2) It should honor the domain restrictive policy to avoid creating new
security problems

Re: [dmarc-ietf] Add MLS/MLM subscription/submissions controls to DMARCbis

[Hector Santos]

On 5/1/2023 6:51 AM, Alessandro Vesely wrote:


Been there, done that.  For the message I'm replying to, I have:

Authentication-Results: wmail.tana.it;
  spf=pass smtp.mailfrom=ietf.org;
  dkim=pass reason="Original-From: transformed" header.d=google.com;
  dkim=pass (whitelisted) header.d=ietf.org
header.b=jAsjjtsp (ietf1);
  dkim=fail (signature verification failed, whitelisted) 
header.d=ietf.org

header.b=QuwLQGvz (ietf1)

However, not all signatures can be verified.  Mailman tries and 
preserve most header fields, but not all.  For example, they rewrite 
MIME-Version: from scratch and don't save the old one.  So if a 
poster signs that field and writes it differently (e.g. with a 
comment) MLM transformation cannot be undone.

https://datatracker.ietf.org/doc/html/draft-vesely-dmarc-mlm-transform



And this was my result for your message, separating lines for easier 
reading:


Authentication-Results: dkim.winserver.com;
 dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;
 adsp=none author.d=tana.it signer.d=ietf.org;
 dmarc=fail policy=none author.d=tana.it signer.d=ietf.org (unauthorized 
signer);

 dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;
 adsp=none author.d=tana.it signer.d=ietf.org;
 dmarc=fail policy=none author.d=tana.it signer.d=ietf.org (unauthorized 
signer);

 dkim=fail (DKIM_BAD_SYNTAX) header.d=none header.s=none header.i=none;
 adsp=dkim-fail author.d=tana.it signer.d=;
 dmarc=dkim-fail policy=none author.d=tana.it signer.d= (unauthorized signer);

 dkim=fail (DKIM_BODY_HASH_MISMATCH) header.d=tana.it header.s=delta 
header.i=tana.it;
 adsp=dkim-fail author.d=tana.it signer.d=tana.it;
 dmarc=dkim-fail policy=none author.d=tana.it signer.d=tana.it 
(originating signer);

Four signatures were added to your submission and the only one that 
counts is the top one, the last one added.


It failed DMARC because tana.it did not authorized ietf.org.   You can 
easily resolve this by adding atps=y to your DMARC record:


v=DMARC1; p=none; atps=y; rua=mailto:dmarca...@tana.it; 
ruf=mailto:dmarcf...@tana.it;


and add an ATPS sub-domain record authorizing ietf.org in your dana.it 
zone:


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

Do that and all ATPS compliant verifiers should show a DMARC=pass:

Authentication-Results: dkim.winserver.com;
 dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;
 adsp=none author.d=tana.it signer.d=ietf.org;
 dmarc=pass policy=none author.d=tana.it signer.d=ietf.org (ATPS signer);


For a short list of signers, I updated my DMARC evaluator to also 
support ASL "Authorized Signer List" to avoid the extra ATPS record. 
So doing this will work across my evaluator for smaller scale mail senders


v=DMARC1; p=none; atps=y; asl=ietf.org; 
rua=mailto:dmarca...@tana.it; ruf=mailto:dmarcf...@tana.it;



This will skip atps=y because asl=ietf.org was satisfied. It was show 
how it was authorized:


 dmarc=pass policy=none author.d=tana.it signer.d=ietf.org (ASL signer);


Any ATPS or ASL idea will give us the author-defined trust of ietf.org 
as a 3rd party signer.


That said,  keeping with the suggestion DMARCBis should add MLS/MLM 
semantics, I believe when the Receiver is receiving mail for a 
MLS/MLM,  it should have the following updated modern consideration 
for a MLS/MLM:


1) It should honor policy first, by check for restrictive domains

2) It should honor the domain restrictive policy to avoid creating new 
security problems and avoid delivery problems.  This means to 
implement subscription and submission controls.  DMARCbis should pass 
the buck back to the restrictive domain who must deal with user's 
needs or not.


3) It should check if the submission's author domain authorizes the 
MLM signing domain by finding a ATPS record, if so


3.1) it can continue as the 3rd party signer and also keep the From as 
is, unchanged, or


3.2) it can also consider to rewrite.  If rewrite is performed, the 
signing domain should have a security that does not allow any Display 
Attack Replays with the now altered 5322.From identity.



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



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

[dmarc-ietf] Add MLS/MLM subscription/submissions controls to DMARCbis

[Hector Santos]

> On Apr 29, 2023, at 4:42 PM, Douglas Foster 
>  wrote:
> 
> ...
> 
> But I need to clarify whether I understand your point.   What I am hearing is:
> For the short term, mailing lists should refuse postings from DMARC-enforcing 
> domains.   That position can be relaxed only if all participating domains 
> have agreed to ignore DMARC Fail for messages from the list  (Ale floated 
> some ideas about that approach.)
> For the longer term, we need a non-DKIM method for delegating rights to a 
> third party.

Ideally, the goal is to eliminate “From Rewrite” to return to the “good ol’ 
days.”  So the first time is to recognize having subscription and submissions 
controls is a natural consideration for the DKIM Policy "Protocol Complete” 
model. If the MLS supports the protocol, it would consider this method more so 
than a destruction method that tear down security.  This will also pass the 
buck back to the domain owner to deal with its user’s needs or not.

> You talk about "incomplete protocol" as if this is a commonly understood and 
> accepted term.  I interpret it to mean a third-party authentication method 
> other than DKIM.  DKIM does serve for third-party authentication where it has 
> been embraced and deployed.   So the issue is that it has not been practical 
> for many situations and we do need another option.

Protocol complete is a client/server protocol negotiation concept.  It 
basically means the “State Machine”, the conversation between the client and 
server is well-defined. No Loop Holes Very key concept in protocol design.

In terms of DKIM Signing Practices, you can read "Requirements for a DomainKeys 
Identified Mail (DKIM) Signing Practices Protocol 
https://www.rfc-editor.org/rfc/rfc5016.txt 
 for its definition.

DKIM Signing Complete: a practice where the dtomain holder assert
that all legitimate mail will be sent with a valid first party 
signature.

But I believe it is not Protocol Complete and to achieve this with DKIM Policy 
Modeling, you have to cover the other signing scenarios which includes 3rd 
party signing scenarios. 

ATPS is the best we got and it works.  You don’t have to worry,  You are using 
gmail.com . Relaxed policy. Minimal security.  ietf.org 
 Rewrite destroys my isdg.net  domain 
security even though I have ietf.org  authorized as an ATPS 
signer.  

It should honor policy and reject my submissions.   Idea.  Add the option to 
the subscription. If you don’t care, let it rewrite to join or use another 
unsecured address.

Not hard.

—
HLS


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

Re: [dmarc-ietf] Messages from the dmarc list for the week ending Sun Apr 30 06:00:04 2023

[Hector Santos]

What is the count based on?  Is the count the amount of mail created 
since the last date of this report which was 1 week ago?


Did Scott create 25 messages and myself 14 messages in one week? I 
don't think so.



On 4/30/2023 5:59 AM, John Levine wrote:

Count|  Bytes |  Who
++---
  94 ( 100%) | 946980 ( 100%) | Total
  25 (26.6%) | 200417 (21.2%) | Scott Kitterman 
  14 (14.9%) | 190300 (20.1%) | Hector Santos 
  12 (12.8%) |  81505 ( 8.6%) | Alessandro Vesely 
   9 ( 9.6%) | 102937 (10.9%) | Jesse Thompson 
   7 ( 7.4%) | 123062 (13.0%) | Brotman, Alex 
   6 ( 6.4%) |  95933 (10.1%) | Douglas Foster 

   6 ( 6.4%) |  31018 ( 3.3%) | John Levine 
   3 ( 3.2%) |  30536 ( 3.2%) | Dotzero 
   3 ( 3.2%) |  17389 ( 1.8%) | Matthäus Wander 
   2 ( 2.1%) |  25665 ( 2.7%) | Barry Leiba 
   2 ( 2.1%) |  12106 ( 1.3%) | John R. Levine 
   2 ( 2.1%) |   5589 ( 0.6%) |  
   1 ( 1.1%) |  20637 ( 2.2%) | Seth Blank 
   1 ( 1.1%) |   5569 ( 0.6%) | Benny Pedersen 
   1 ( 1.1%) |   4317 ( 0.5%) | Jim Fenton 

___
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] Summary: Search for some consensus, was: Proposed text for p=reject and indirect mail flows

[Hector Santos]

> Given that lists are expected to (A) continue making content changes, and (B) 
> continue accepting all comers, I think we need to embrace From Rewrite as a 
> necessary consequence of A and B.Unlike Hector, I don't have a problem 
> with From Rewrite because the act of altering the content makes it a new 
> message, and the modifying entity becomes responsible for the whole thing.   
> So we need a caveat to list owners which lays out the real risks and the 
> better alternatives.


Douglas,

Just a few points.

It is more accurate to state, "Unlike others," because I am not the only one 
who has a problem with altered mail authorship, and worse, when done for the 
purpose of a security teardown it potentially introduces a new security threat 
with Display Name attacks.  I believe I am “IETF” correct to raise this 
security concern where IETF security folks would agree.
 
It is often stated that it is unfair to MLS/MLM folks who have worked unchanged 
for over 30+ years to be required to change.  Please understand I have a 
commercial MLS product since 1996 and I don’t like changes just like the next 
MLS developer. I’ve extremely conservative but I do adapt when necessary. My 
MLS is a legacy product but it is still actively supported. 

Well, for the MLS or MLM refusal to adopt the protocol, the refusal to adopt 
measures known to resolve the DKIM secured with Policy mail stream, caused an 
immediate need by one MLM to create a hack to alter list submissions from 
restrictive domains. It resolved the immediate problem. The MLM could have 
adopted subscription/submission controls as outlined in 2006 and discussed many 
times in the WGs. It  was not  unknown. These correct methods would have pushed 
the burden back to the domain seeking exclusive mail security once they began 
to publish and honor p=reject. The MLM could have supported any of the many 
ADID::SDID association authorization proposals too, but it did not. So here we 
are with the DMARC rewrite problem where in my view, needs to be explained and 
corrected. 

The "new message" angle is one view, but not the definitive one to suggest it 
is okay to alter list submission copyrighted authorships. It is not a normal 
thing to do, but what you can do as an MLS/MLM developer depends widely on the 
type of list distribution. If you are just broadcasting to a list of people as 
a read-only list, then the preparation of required headers is a legitimate 
instance where it completes a new secured message with the proper secured 
business addresses.


—
HLS

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

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

[Hector Santos]

Douglas, 

In general, you can’t impose or mandate TLS under PORT 25 unsolicited, 
unauthenticated sessions. You can do this with ESMTP AUTH a.k.a SUBMISSION 
Protocol (RFC6409) which is Port 587. Under this port, you can mandate more 
Authentication/Authorization and mail format correctness than with Port 25 and 
not using ESMTP AUTH.

So for example, for PCI, you must use A/A mechanisms probably under Port 587 
because it can be mandated. But not under Port 25.

—
HLS

> On Apr 27, 2023, at 7:04 AM, Douglas Foster 
>  wrote:
> 
> There are options on TLS failure.  
> 
> Mandatory TLS is actually pretty common, since PCI DSS, HIPAA and GDBR have 
> all been interpreted as requiring TLS on email.For outbound mail, our MTA 
> is configured to drop the connection if encryption cannot be established.  I 
> think this configuration option has become pretty common in commercial 
> products.Domains that cannot accept encrypted traffic are handled with 
> secure web relay (Zixmail or one of its many imitators.)  In the case of a 
> report recipient that cannot accept TLS traffic, we would simply drop the 
> destination.
> 
> For inbound mail, my organization has concluded that data security is the 
> responsibility of the sender, so we do accept unencrypted messages.  
> 
> By and large, mandatory TLS will be implemented consistently, rather than on 
> a specific message like a DMARC report, so I don't know how much needs to be 
> said in this document.
> 
> Doug 
> 



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

[dmarc-ietf] Proposed Updates for DMARCbis - Section 4.4.3 and New Appendix A.8

[Hector Santos]

I would like to propose updates to the DMARCbis documentation, specifically for 
Section 4.4.3 and a new Appendix A.8. Please find the suggested revisions 
below.  Your input would be greatly appreciated.  It is just a starting point.

Proposed update for Section 4.4.3:

4.4.3. Alignment and Extension Technologies

DMARC can be extended to incorporate authentication and authorization 
mechanisms that aid in the evaluation of DMARC policy. Any new authentication 
extensions must facilitate domain identifier extraction to enable verification 
of alignment with the RFC5322.From domain.

Authorization extensions address situations where the author domain differs 
from the signer domain, known as 3rd party signatures. The following 
Author::Signer domain authorization methods have been explored:

DomainKeys Identified Mail (DKIM) Authorized Third-Party Signatures (ATPS) 
[RFC6541]
Third-Party Authorization Label (TPA) [draft-otis-tpa-label-08]
Mandatory Tags for DKIM Signatures [draft-levine-dkim-conditional-04]
Delegating DKIM Signing Authority [draft-kucherawy-dkim-delegate-02]
The first two methods are DNS-based, while the latter two are non-DNS-based. 
All share the common objective of authorizing the 3rd party signature. The ATPS 
proposal is the simplest method and has demonstrated success in practice by 
reducing 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.

Proposed new Appendix A.8:

A.8 Mailing List Servers

Mailing List Servers (MLS) applications that are compliant with DMARC 
operations SHOULD adhere to the following guidelines for DMARC integration:

Subscription and Submission Controls:

MLS subscription processes should perform a DMARC check to determine if the 
subscribing or submitting email domain's DMARC policy is restrictive regarding 
mail integrity changes or 3rd party signatures. The MLS SHOULD only allow 
subscriptions and submissions from original domain policies that permit 3rd 
party signatures with a p=none policy.

Message Content Integrity Change:

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

Security Tear Down:

The MLS SHOULD NOT compromise the author's security by changing the authorship 
address (From) domain. Instead, it should apply subscription/submission 
controls. However, if circumstances necessitate a From rewrite, the rewrite 
with a new address SHOULD maintain the same level of security as the original 
submission to avoid potential Replay and Display Name Attacks.
Please let me know your thoughts on these proposed updates and whether they can 
be integrated into the DMARCbis documentation.

Best regards,

Hector Santos




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

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

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 

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

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