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

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

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

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

Re: [Ietf-dkim] Testing a DKIM implementation

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

Re: [dmarc-ietf] DMARC exceptions

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

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

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

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

> 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

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

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 do

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

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

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 reco

Re: [dmarc-ietf] The sad state of SPF: research just presented at NDSS

roneous 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 mailin

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

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

Re: [dmarc-ietf] dmarc-dmarcbis: add "req=dkim"

+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,

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

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

Re: [Ietf-dkim] Security indicators, not Headers that should not be automatically oversigned

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

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

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

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

> 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

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

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

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

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

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

ed 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

F 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

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

ever, 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 Ja

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

ecify 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

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

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

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

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

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

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:

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

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

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

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

> 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: >>> >>> DM

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

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

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

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://ww

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

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

[dmarc-ietf] Current Status of DMARCBis

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

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

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

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

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,

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

/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 d

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

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 autho

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

, 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

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

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

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

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

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 t

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

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

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

> 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

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

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

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

+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,

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

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

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

> 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

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

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: >>> O

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

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

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

> 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

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

ems 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

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

> 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

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

> 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

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

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

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

> 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

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

> 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

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

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

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

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

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

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

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

Re: [dmarc-ietf] Third party signatures

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

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

t 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

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

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

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

> 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

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

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

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

> 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

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

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

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

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

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

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

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

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]

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

ail system with 3rd party signer support as it was originally envisioned. 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

> 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

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

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

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

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

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

ctice 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 h

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

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

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

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

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

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

h 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

f 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: >> >>>

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

> 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

Re: [dmarc-ietf] Delegated authentication for Gmail

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

Re: [dmarc-ietf] Delegated authentication for Gmail

> 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

Re: [dmarc-ietf] Delegated authentication for Gmail

> 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

Re: [dmarc-ietf] Delegated authentication for Gmail

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

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

> 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

[dmarc-ietf] About UAID User Agent Identity.

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 p

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

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

Re: [dmarc-ietf] Signaling MLMs

> 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

Re: [dmarc-ietf] Signaling MLMs

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

Re: [dmarc-ietf] Signaling MLMs

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

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

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

Re: [dmarc-ietf] Signaling MLMs

or 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

) 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

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

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

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

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

Re: [dmarc-ietf] Signaling MLMs

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

[dmarc-ietf] Author vs Signer Domains

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 over

Re: [dmarc-ietf] Signaling MLMs

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 Hec

Re: [dmarc-ietf] Signaling MLMs

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

Re: [dmarc-ietf] Signaling MLMs

The solution to move forward is: - Recommend MUST NOT publish if domain wants to allow users to use domain in public list systems, - Warn MLS/MLS to avoid From Rewrite and recommend to honor p=reject by rejecting subscription, submissions. This is already in practice since 2011. - Update

  1   2   3   4   5   6   7   8   9   10   >