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

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

horizing the always signed. DMARC needs this Always Signed by someone idea too with ATPS to finish the authorization missing piece. -- Hector Santos, https://santronics.com https://winserver.com ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Signaling MLMs

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

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

> On Apr 13, 2023, at 3:13 PM, Hector Santos > wrote: > > On 4/13/2023 11:21 AM, Barry Leiba wrote: >>> Anyone who does forwarding is damaged by DMARC because there are a lot of >>> people who do DMARC on the cheap with SPF only. >> This brings up another is

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

I didn’t we need to mention the type of people, organization, etc. “This is particularly important because SPF will always fail in situations where mail is forwarded.” The issue applies to all. > On Apr 13, 2023, at 12:04 PM, Todd Herr > wrote: > > On Thu, Apr 13, 2023 at 11:21 AM Barry

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

, and using SPF only, without DKIM, is strongly NOT RECOMMENDED. Keep in mind, there are implementers of SPF that act at SMTP before DATA and reject hard failures with 55z errors. In other words, no payload is transferred. -- Hector Santos, https://santronics.com https://winserver.com

Re: [dmarc-ietf] Signaling MLMs

y to override at its own risk especially when DMARCBis offers nothing to resolve this problem. But it can easily fit in too and see where it goes. -- Hector Santos, https://santronics.com https://winserver.com ___ dmarc mailing list dmarc@ietf.org

Re: [dmarc-ietf] Signaling MLMs

t;.policy-adsp") CopyFile(msgfn,msgfn+".dmarc") sfSetGlobalResult(SF_DISCARD,SF_ENDRULES,554) // create response fv = open msgfn+".response" for output if fv > 0 then print #fv,"554

Re: [dmarc-ietf] Signaling MLMs

> On Apr 12, 2023, at 2:15 PM, Murray S. Kucherawy wrote: > > I've been thinking about the point a few people have made now that DMARC has > two actors that cause the problem: Those who "blindly" apply "p=reject", and > those who advertise "p=reject". You do, indeed, need two to tango; >

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

and collaborate on the development of DSAP/ATPS as a more robust and adaptable email authentication protocol that serves the interests of all parties involved. I look forward to your thoughts and feedback on this proposal. Best regards, Hector Santos, CEO/CTO Santronics.com > On Apr 12, 2023, a

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

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

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

> On Apr 10, 2023, at 12:55 PM, Murray S. Kucherawy wrote: > > I think the one thing we haven't discussed is: Could the 80-20 rule apply > here? That is, if we start off with something like what > draft-kucherawy-dkim-transform proposed (or even a trivial subset of it), > might it make

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

> On Apr 10, 2023, at 12:55 PM, Murray S. Kucherawy wrote: >> > I think the one thing we haven't discussed is: Could the 80-20 rule apply > here? That is, if we start off with something like what > draft-kucherawy-dkim-transform proposed (or even a trivial subset of it), > might it make

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

> On Apr 9, 2023, at 2:33 PM, Barry Leiba wrote: > > > As Todd previously stated, my preference is for language that > > acknowledges the primacy of the domain owner over interoperability > > The problem is that IETF standards are about interoperability, not about > anyone’s primacy. > >

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

> On Apr 9, 2023, at 2:15 PM, Murray S. Kucherawy wrote: > > On Sun, Apr 9, 2023 at 6:33 AM Jesse Thompson > wrote: >> As Todd previously stated, my preference is for language that acknowledges >> the primacy of the domain owner over interoperability. CISOs have

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

. The -target will allow a forwarder to resign as a 3rd party without -asl or -atps requirements. — Hector Santos, CEO/CTO Santronics Software, Inc,___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

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

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

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

> On Apr 1, 2023, at 11:33 AM, Dotzero wrote: > > > > On Sat, Apr 1, 2023 at 3:02 AM Barry Leiba > wrote: >> > If we use SHOULD NOT, as you suggest, there's an implication that there >> > might be a valid reason for >> > non-transactional mail to use

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

> On Apr 1, 2023, at 11:25 AM, Dotzero wrote: > Nobody forces a Sender to publish a DMARC record. Nobody forces a receiver to > validate DMARC. Nobody forces mailing lists to accept mail from domains which > publish a DMARC record let alone one which publishes p=reject policy. But it >

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

> On Apr 1, 2023, at 7:17 AM, Jim Fenton wrote: > > Not picking on Murray here, but his message was the most recent that talked > about p=reject with respect to non-transactional email: > > On 1 Apr 2023, at 15:53, Murray S. Kucherawy wrote: > >> If we use SHOULD NOT, as you suggest,

[dmarc-ietf] 5322.From Header Rewrite specification

Is there a specification for rewriting the 5322.From to help resolve DMARC p=reject redistribution problems? What is the logic the IETF.ORG list using? Thanks in advance — HLS___ dmarc mailing list dmarc@ietf.org

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

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

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

> On Mar 30, 2023, at 10:16 AM, Todd Herr > wrote: > > My fear is that adding further text to DMARCbis that says "MUST NOT use > p=reject" along with the new language in Policy Enforcement Considerations > results in a spec that says: > As a domain owner, you can request treatment for

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

does not have -atps, then the receiver MUST honor the domain reject policy for failures. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

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

a proposed experiment. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

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

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

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

> On Mar 26, 2023, at 1:11 PM, Michael Thomas wrote: > My contention is that documenting what has failed in the problem statement > saves time eventually in the solution space as you can reference it when > somebody brings it up as to why it doesn't work. It would be just a cut and > paste

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

> On Mar 26, 2023, at 6:13 AM, Murray S. Kucherawy wrote: > > On Sat, Mar 25, 2023 at 10:29 AM Michael Thomas > wrote: >> On 3/24/23 6:19 PM, Barry Leiba wrote: >> > I don't agree with the premise. I think what was tried and didn't >> > work should be documented in the

Re: [dmarc-ietf] ARC Dependency?

Wouldn’t it be far easier to add the trusted 3rd party domains in some DNS table or lookup, ala an ATPS-like protocol? The RFC5322 ARC overhead is horrendous. Never mind the complexity evolved to implement. > On Mar 24, 2023, at 7:17 PM, Seth Blank wrote: > > Microsoft is using ARC quite

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

+1. ARC is not a solution, but it is a good part of the problem. It’s not hard to see how our fall back to defocusing, the de-emphasis of the DKIM Policy Model in lieu of Reputation Modeling creating this issue. Every issue we have today is nearly 100% because of the lob-sided efforts to

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

model do not have this problem. But, via POLICY if the domain using reputation wishes a verifier to put more restrictions on a received signed domain, i.e. enforce `x=` expiration tag, I am all for it. Thanks Hector Santos CEO/CTO Santronics Software, Inc. > On Mar 7, 2023, at 7:09

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

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

Re: [Ietf-dkim] Remove the signature! (was: Re: DKIM reply mitigations: re-opening the DKIM working group)

> On Nov 20, 2022, at 6:01 PM, Murray S. Kucherawy wrote: > > > > On Sun, Nov 20, 2022, 11:08 Dave Crocker > wrote: >> Seriously. DKIM is intended as a transit-time mechanism. When delivery >> occurs, transit is done. So DKIM has done its job and can (safely?)

Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group

> On Nov 11, 2022, at 11:46 AM, Barry Leiba wrote: > > Indeed... > The issue here is this: > > 1. I get a (free) account on free-email.com. Ok > 2. I send myself email from my account to my account. Of course, > free-email signs it, because it's sent from me to me: why would it > not?

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

e MAIL FROM: line MAIL FROM: submitter=5322.from Now SMTP has the ability to check for the DMARC policy to see how strong SPF SHOULD be and if its fails or not. This will allow for the short circuiting and optimization of MAIL data I/O which today is increasingly getting larger with multi-medi

Re: [dmarc-ietf] Sender vs From Addresses

As to why the IETF.ORG mailing list does not support it or explore it and has chosen instead to rewrite, I don't know, but its so simple --- a DNS Lookup without any 5322.From tampering. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos __

Re: [dmarc-ietf] Sender vs From Addresses

if it makes sense. If sender is used, there SHOULD be some author policy tag indicating so. -sender=1 means to follow your specs? -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos ___ dmarc mailing list dmarc@ietf.or

Re: [dmarc-ietf] Sender vs From Addresses

quot;replacement recipient", and replacing the original sender's |Reply-To:| would impair the functionality for //those// users. *Charles A. Gregory*// _______ dmarc mailing list dmarc@ietf.org h

Re: [dmarc-ietf] Ticket #1 - SPF alignment

ROM: [SUBMITTER=pra] At the point, the SMTP client has some awareness of the payload and DMARC expectations. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #1 - SPF alignment

f all this, but for me, there are some basic filter concepts that can be applied and I do for my wcSMTP package before all the extra DNS overhead can be applied. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos [1] Lightweight MTA Authentication Protocol (LMAP) Discuss

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

address at 6 position 2 - not check, assume plus 6 has the a valid address. In each case, it will fail (no https delivery supported), #2 may be an a wasted delivery attempt to an invalid email address. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos _

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

s a new DMARC version 2 resource record. I don't think we (I know I can't) can continue with DMARCbis without Extended Tag support and be hesitant to invent them because there is a compatibility problem. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos ___

Re: [dmarc-ietf] auth-res vs. dmarc

at we need and then use this for the update up the A-R specs to create a more common and useful name space to all. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos ___ dmarc mailing list dmarc@ietf.org https://www.ietf.o

Re: [dmarc-ietf] reporting documents, Ticket #55 - Clarify legal and privacy implications of failure reports

ADSP 5322.From check Maybe DMARC 5322.From check Maybe ATPS 5322.From check Maybe VBR 5322.From check Overall, there are a lot of calls today per SMTP session. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos ___ dmar

Re: [dmarc-ietf] auth-res vs. dmarc

f._atps TXT ( "v=atps01; d=gmail.com;" ) pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps TXT ( "v=atps01; d=ietf.org;" ) jchjykxmwknbyfge2bg4td6add264olh._atps TXT ( "v=atps01; d=winserver.com;" ) -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] p=quarantine

On 12/11/2020 11:19 AM, Dotzero wrote:> On Fri, Dec 11, 2020 at 11:11 AM Hector Santos We are not doing reporting at this time. Not the main focus. That can come later as an augmented feature, in fact, we might consider it as a paid service to be sending thousands report out to doma

Re: [dmarc-ietf] p=quarantine

On 12/11/2020 11:10 AM, Hector Santos wrote: * SPF -ALL, REJECT - Receiver rejects at MAIL FROM state with a 550 response. Correction: * SPF -ALL, REJECT - Receiver rejects at RCPT TO state with a 550 response. SPF is only tested once a valid (existing) RCPT TO is provided

Re: [dmarc-ietf] p=quarantine

sending thousands report out to domains. Keep it simple folks. Be safe and have a great weekend. Thanks -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #39 - remove p=quarantine

ue the WG decision to add ARC to DMARC in some matter. But don't ram it down our throats. Allow domains to explore with an "ARC=1" tag in their DMARC record, then at some point in the future, as we learn more, it can be explored. But imo, we should not speak of a DKIM Policy

Re: [dmarc-ietf] ARC vs reject

n atps=1 DMARC MAY consider using RFC6541 rewrite=0 Mailing List SHOULD NOT rewrite 5322.From Keep it simple folks. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos ___ dmarc mailing list dmarc@ietf.org https://www.ietf.

Re: [dmarc-ietf] Announcing DMARCbis Editors

e 3rd party resigned and authorization issue. While I personally, and I believe ideally, prefer ATPS be included in the DMARC-BASE protocol, due to the lack of WG support, I rather get the DKIM-BASE 1st party semantics completed first. Thanks -- Hector Santos, https://secure.santronics.com https://twit

Re: [dmarc-ietf] Ticket #7: ABNF for dmarc-record is slightly wrong

or had DMARC documented fields with their options. You had to go into GUI's raw edit mode option to add extended tags and this was supported. Since the editor did not recognize the tag, it disabled the form Editor and only allowed the raw field editor. Nice job. -- Hector Santos, https://secure.sant

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

you say anything to him? Should that be tolerated? I'm trying my best to participate without the snide remarks and reputation hurting remarks. I take it very personal because I have seen how it can hurt people. He should stop doing that. -- Hector Santos, CTO/CEO Santronics Software, Inc. https

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On 9/29/2020 6:54 PM, Dave Crocker wrote: On 9/29/2020 3:41 PM, Hector Santos wrote: Do you have an algorithm that replaces the current one? I've no idea what any of your note has to do with the DKIM protocol specification. wow. By way of a small example, DKIM does not have o=. Right

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On 9/29/2020 1:26 PM, Dave Crocker wrote: On 9/29/2020 6:40 AM, Hector Santos wrote: On 9/27/2020 11:44 PM, Dave Crocker wrote: DKIM has a single signature binding requirement, the 5322.From DMARC establishes the relationship. I don't read it that way. DKIM binds the signer d= domain

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

at are those steps? can it be outlined in itemized steps? -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

third party proposals on the table? -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

DMARC tag extension. The existence of the extra tag triggers the logic. For ATPS RFC6541, it was designed to piggyback off ADSP. So ATPS will need to be updated to use DMARCbis. The Domain sets the atps=y extension tag to trigger the logic. -- Hector Santos, https://secure.santronics.

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

with DMARC, except that the policy in question now is "reject" rather than "discardable"? Yes, it's just a keyword, but it reflects the semantics of the expected action as well. -Jim No one was expected to follow a reject, so it was said, until it did happen. SPF pushed --

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

st. Remove the Author Domain dependency so that the world can nip the Mail tampering bug opened with Levine's Rewrite crud. I wouldn't worry about backward compatibility. Two different streams, only the newer one will matter. -- Hector Santos, https://secure.santro

[dmarc-ietf] LSAP - Lightweight Signer Authorization Protocol methodology

TP client that is emitting the mail, either IPv4 or IPv6. - the domain that provides the sought-after authorization information; initially, the domain portion of the "MAIL FROM" or "HELO" identity. - the "MAIL FROM" or

Re: [dmarc-ietf] non-mailing list use case for differing header domains

in this thread - executive assistants sending on behalf of multiple DMARC protected brand domains - is not that uncommon and I think a policy solution to that would be warmly welcomed. +1 -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos

Re: [dmarc-ietf] non-mailing list use case for differing header domains

On 7/30/2020 6:39 AM, Jeremy Harris wrote: On 29/07/2020 18:34, Hector Santos wrote: Look at my DMARC record for my isdg.net domain: v=DMARC1; p=reject; atps=y; rua=mailto:dmarc-...@isdg.net; ruf=mailto:dmarc-...@isdg.net; The atps=y [...] So anyone out there can see that I authorized

Re: [dmarc-ietf] non-mailing list use case for differing header domains

com to sign for isdg.net It is really sample. Whether we can "coerce" receivers to honor any of this is a different situation. In general, all you can do create a PROTOCOL that makes good engineering sense and usable by the IETF community. If not, then generally

Re: [dmarc-ietf] Meetecho at IETF 108

to hear them. You can email the list, the chairs, or me with your thoughts. -MSK, for the first time sporting an Area Director hat in here ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc -- Hector Santos, https

Re: [dmarc-ietf] non-mailing list use case for differing header domains

addresses and does not have this problem (administration aside). The DKIM Policy Model since ADSP lacked the ability to authorize 3rd party domains. DMARC did not address the problem and reason ADSP was abandoned. Hence the on-going dilemma. -- Hector Santos, https://secure.santronics

Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations

On 7/26/2020 2:34 PM, Dave Crocker wrote: On 7/26/2020 11:29 AM, Hector Santos wrote: Dave, for a number of years of practice, depending in the system or service, users have been provided with trust-related decisions . Do you need real examples? There is a difference between providing

Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations

because now you are forcing the user to scrutinize the Spam Box opening the door to reading and accidental clicks. if REPORT NOT SPAM does not clear it up, there is even more confusion for the purpose of that button or any similar AI learning logic that may be employed. -- Hect

Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations

deterministic mechanisms, we do have mail systems who do allow the user to make these type of trust decisions. If a trust-related question is answered wrong by the user, the true victim is the honest sender. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos

Re: [dmarc-ietf] Agenda requests for Madrid IETF

variables and outputs can be defined, registered for the DKIM-REPORTS specs.) -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations

s problems until they change or the user is made aware he can't use his exclusive domain on a public forum. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC threat analysis needed

ia local policy exceptions can ignorantly and blinding destroy the integrity and resign the mail instead of just honoring it. This language would have be updated or removed and just leave the implicit idea that local policy always prevails in all SMTP situations. Have a good weekend, be

Re: [dmarc-ietf] DMARC Use of the RFC5322.Sender Header Field

was added. This was the "DKIM Policy Killer" and we have not recovered. The irony now is the third party signer impugning on the 1st party policies. 1st Party Policies Matters! -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos _

Re: [dmarc-ietf] DMARC Use of the RFC5322.Sender Header Field

y the sending domain, i.e., the "From:" or "Sender:" header; thus, this tag can never contain an empty value. and also section 3.1 "Determining the Sending Address of an Email" https://tools.ietf.org/html/rfc4870#section-3.1 where there is a protocol language re

Re: [dmarc-ietf] draft-crocker-dmarc-author-00

see how we can trust a DKIM-signature that has no immutable identity requirement to it. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC Use of the RFC5322.Sender Header Field

this is with the ADID adding a SDRID or SDID DNS record which is how ATPS "Authorized Third Party Signer" works. Another way is use a non-DNS based conditional signature idea. There is also TPA. Supposedly, it scales better than ATPS as a DNS record lookup proposal. -- Hector San

Re: [dmarc-ietf] draft-crocker-dmarc-author-00

that won't be. Then imo, it must be an immutable header object and a requirement to be hash bound. This changes DKIM-BASE and the DKIM Policy protocol. Lacking this requirement, leaves open a variety of loop-holes. -- Hector Santos, https://secure.santronics.com https://twitter.com

Re: [dmarc-ietf] DMARC Use of the RFC5322.Sender Header Field

rily because we didn't have a 3rd party resigner authorization protocol. This is where we left it, never to go away, and its back again. How do resolve this without re-inventing email and introducing new headers? -- Hector Santos, https://secure.santron

Re: [dmarc-ietf] DMARC Use of the RFC5322.Sender Header Field

domain for DMARC policy? Does this mean the Sender header is now required to be hash bound to the signature? -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt

On 7/7/2020 8:47 AM, Hector Santos wrote: The problem has been Signer Reputation wanting to push out DKIM Policy: Layer 1: DKIM Policy Deterministic protocol Layer 2: DKIM Signer Trust/Reputation The argument has always been by Mr. Levine and others, why need Layer 1 [if] all we need is layer

Re: [dmarc-ietf] Mailing List Digest Considerations

On 7/7/2020 8:20 AM, Benny Pedersen wrote: Hector Santos skrev den 2020-07-07 13:52: What would be, if any, DKIM, DMARC and ARC consideration when digests are created? user posts to maillist should only be ARC sealed digist post could be dkim signed aswell, since content is dkim breaked

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt

remove any recognition of its importance. The cogs had a hard time doing this because DKIM policy was too strong of a concept. It would simply not go away. 5322.From could not be removed from DKIM-STD. It could not avoid the fundamental idea that 5322.From is the minimum required header to

[dmarc-ietf] Mailing List Digest Considerations

others. I don't recall a standard method for created a digest. - Based on my current view for the available list digests, they are on the lower side of having subscribers. Is a List Digest a non-consideration as an MLM output? -- Hector Santos, https://secure.santronics.com https://twitter.com

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt

it. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos On 7/6/2020 12:43 AM, Murray S. Kucherawy wrote: On Sun, Jul 5, 2020 at 8:35 PM Hector Santos mailto:hsan...@isdg.net>> wrote: 1) Curious, are these Mail List Server (MLS) developers active participants of

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt

a general question and not specifically address to you as WG AD and the proposal editor. I'm sure you can be fair, but nonetheless, I have an active implementer "fairness" concern with each of these itemize questions. Thanks -- Hector Santos, https://secure.santronics.com https://twitter.co

Re: [dmarc-ietf] DMARC as an instance of a class

On 7/3/2020 10:34 AM, ned+dm...@mrochek.com wrote: On 7/3/2020 9:58 AM, Hector Santos wrote: SA is a tool that reads the entire RS232 payload. HA! RS232 on my mind, helping an enterprise customer with his 32 modem server setup. Of course, I meant RFC5322. Good to know I'm not the only

Re: [dmarc-ietf] DMARC as an instance of a class

On 7/3/2020 9:58 AM, Hector Santos wrote: On 7/1/2020 7:51 PM, John Levine wrote: ##, ###. Spam filters like spamassassin have looked at the headers along with everything else in the message forever. SA is a tool that reads the entire RS232 payload. HA! RS232 on my mind, helping

Re: [dmarc-ietf] DMARC as an instance of a class

hope and expect the WG chairs and AD would be addressing this. Have a safe holiday weekend. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo

Re: [dmarc-ietf] An alternative proposal to the known intermediary problem

controls with subscription and submission checking. It doesn't need to worry about getting support for the abandoned MLS. He just needs to control the entry points like subscription and submission. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos

Re: [dmarc-ietf] An alternative proposal to the known intermediary problem

On 6/26/2020 9:27 AM, Hector Santos wrote: The latter would certainly be true during the early migration period in the same way it was true with SPF, ADSP and now ADSP The same was will be true with ATPS with NXDOMAIN results. Meant to say: The latter would certainly be true during the early

Re: [dmarc-ietf] An alternative proposal to the known intermediary problem

complete and support. The security section #1 will need to be review to address its described replay potential. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos ___ dmarc mailing list dmarc@ietf.org https://www.ietf.

Re: [dmarc-ietf] What if... Sender:

. SPF has it because it allows you to authorize other IPs outside your own network. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] What if... Sender:

norm offering a negative classification, i.e. rejection or quarantine. So if Sender: wouldn't be as useful as From:, why not? Because we still do not have protocol that can test the assertion that the 3rd party Sender is authorized by the 1st party. It is the same problem. -- Hector Santos, http

Re: [dmarc-ietf] What if... Sender:

-- Sure, maybe the user doesn't want to be bothered with this, so he turned it off in the MUA's DKIM/DMARC options under the View | Preference section. [X] Display Unauthorized DKIM signer warnings With 40 years with no MUA guidance, of course, it will continue to be a statu

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

using _dmarc.ietf.org for the return address to kept with the expected DMARC alignment. That will maintain the DMARC aligned protection for the original submission and resigner distribution. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos _

Re: [dmarc-ietf] Mediation

policy. Here are your options: 1) Use another non-restrictive domain, 2) Prevent your domain from subscription and submission, or 3) Authorize the Rewriting of your secured domain to a secured resigner domain. Thanks -- Hector Santos, https://secure.santronics.com ht

Re: [dmarc-ietf] Mediation and controlled forwarding

s !fs tags, and by using the x= tag to limit the time during which forwarded signatures are valid. If the author still believes this loophole exist, why are we bothering? -- Hector Santos, https://secure.santronics.com https://twitter.com/he

Re: [dmarc-ietf] Mediation

. (*Sigh*) pr -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

=3 Only Display address when signer domain differs Of course, with change comes new opportunity. If the MUA was updated to support this tag, then we may not need the tag and just advise the MUA to prominently display the address and/or when we have a 3rd party resigner involved.

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

f-interest groups behind the scenes, benefit. No offense to anyone, 15 yrs on this, is not a good thing. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailma

<    1   2   3   4   5   6   7   8   9   10   >