Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal
Jan Dušátko <jan@dusatko.org> Sun, 18 June 2023 20:56 UTC
Return-Path: <jan@dusatko.org>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3DBC14CE2F for <dmarc@ietfa.amsl.com>; Sun, 18 Jun 2023 13:56:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dusatko.org header.b="EC/cgkdb"; dkim=pass (2048-bit key) header.d=dusatko.org header.b="byVods03"; dkim=pass (2048-bit key) header.d=dusatko.org header.b="oMd+pKjS"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Flw4LEDrcrYD for <dmarc@ietfa.amsl.com>; Sun, 18 Jun 2023 13:56:39 -0700 (PDT)
Received: from vhost.cz (hermes.vhost.cz [82.208.29.84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77991C14F747 for <dmarc@ietf.org>; Sun, 18 Jun 2023 13:56:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dusatko.org; s=key2048; t=1687121792; bh=vvWrWz9MTR4Sp3GgGj9xDob4kvLiyaeI8Kpdp5sTHFg=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=EC/cgkdbgOyaEqVdZg75PcQHwViERdG81O1uVwMH4I/PM3yN4GHH7zUW3gNGXSqSF +c06CGOoWmmfj83wXa4Swm6to8keh7ckHek4UPxw3UehjsBliBmK8Nl68ZkGPgFtwC knw+rKJu26c22t5CjGXQ2cJANHnZD+3jyxMm68Jr6vJ5Aj0OzRUvhJXVpAB0w6djih qJ0EOhd7syChyReeu4ok88Hd/2MQMhARmpBJk3FBF3XBBYo2nYHHaXD19ObQ/b5kSM rUxOh6x8NVMW3NZjvugtIcFUEaqqL/v1JEsNLYR4akd1bHoZGmKs0+z6rpxinoux82 SY8cjaCHV3B3w==
Received: from localhost (localhost [127.0.0.1]) by hermes.vhost.cz (Postfix) with ESMTP id D04798001B for <dmarc@ietf.org>; Sun, 18 Jun 2023 22:56:32 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at hermes.vhost.cz
Received: from vhost.cz ([127.0.0.1]) by localhost (hermes.vhost.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOACmDNoYt2o for <dmarc@ietf.org>; Sun, 18 Jun 2023 22:56:31 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dusatko.org; s=key2048; t=1687121791; bh=vvWrWz9MTR4Sp3GgGj9xDob4kvLiyaeI8Kpdp5sTHFg=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=byVods03zTu1Oi8U6fj3CVDKMsfCLJRyp5WHOY4BzICoB3riM/ZjxV0f0GoRjHeGV l2h9RwMKQ/Xvi0c8m05VfEjd01HUKpnY/UPU7XHJ2ytkAN4hMJzccPUv8A6i4j83Sb k8G4MvfjxD0Cf4KpYgiKXbqrRPvoTztLaIMkPsMZBP6DSP5avE2eW16tAetRux+sPL TjHPMAIGcRQyaTFFxO0eeUo66LfFTVRpPbaruzCIpVaka3qgoOnVwGrATAEq7GmGZi +E8ovQlhjSZWKXhCEuwQavdVQMeWJQEK6mTd4EpXt9JPF39NitkBa0MdTEjRLHAHOO /20NuCwnh7eVw==
Received: by hermes.vhost.cz (Postfix, from userid 115) id 850E080051; Sun, 18 Jun 2023 22:56:31 +0200 (CEST)
X-Spam-Virus: _CLAMAVRESULT_
X-Spam-Pyzor: Reported 0 times.
X-Spam-DCC: :
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dusatko.org; s=key2048; t=1687121786; bh=vvWrWz9MTR4Sp3GgGj9xDob4kvLiyaeI8Kpdp5sTHFg=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=oMd+pKjSPghjZa6T0X+zmRFe5N2l2CimskIIkpqRTb7lIAxkidNSYAP1D8RmZy4fs WJ2GplB6qoGhQEWrU+BWvDflQEongObnQP3MzJeCp4FLDQkndyypGCpj2IAnO8vOp7 HcPj0I9ntn8L1x236DG+wS4cCj3yQTR8Lq7xFHqtGFAiPPAPKjnrzTlGnSugXRilPG rOha3a0UYonT8ZNFfI7MIyMIy1R5eVW0/ZAhk+FhSG/FOHuFXaerLUYxrPZwOE+1tS ARtcgZqBLEU26IsklfN2UK/X95O5su9Ay2iCClbn7qV7pB0vdPQklP2PoZ7zeeQIFH B/SctUuhGygBg==
Received: from [192.168.1.160] (static-84-242-66-51.bb.vodafone.cz [84.242.66.51]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) by hermes.vhost.cz (Postfix) with ESMTPSA id 1E4688001B; Sun, 18 Jun 2023 22:56:26 +0200 (CEST)
Message-ID: <31c265c4-2cec-9204-1e33-0771d5237cc5@dusatko.org>
Date: Sun, 18 Jun 2023 22:56:17 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.11.2
Content-Language: en-GB
To: Douglas Foster <dougfoster.emailstandards@gmail.com>, Ken Simpson <ksimpson@mailchannels.com>
Cc: dmarc@ietf.org
References: <30BB83B2-B454-41B8-992B-8E2569802D9C@1und1.de> <D225D7FC-C570-4B63-A694-9F16DB1F33E1@kitterman.com> <CALaySJKwuOK-81dW2H9dtURxa5mLQDUNo+MWcs+Hho8N+yP9qg@mail.gmail.com> <2817813.dRqVH37e0G@localhost> <CALaySJJbPFBAV_7mZaARYWuMzuX+74r2Cm0jD+z92_iuFRn_MQ@mail.gmail.com> <25736.57534.195344.782189@fireball.acr.fi> <1ec42959-977a-9ce0-907a-83a5eb2b6ef2@tana.it> <25739.5435.550786.601699@fireball.acr.fi> <25739.33240.127804.524371@fireball.acr.fi> <5d9a0b0f-8777-2494-d779-376c6ab8b37d@tana.it> <7d39aa8e-dacc-05fa-eff1-2cc350d521db@inboxsys.com> <CAH48ZfwyBwfKzG_3R5uyV6tmY0yUtWy=5yAoAOEhUGn_Rz6HNw@mail.gmail.com> <47b8a0c7-6a52-a4ad-e98e-8cb2f881713e@inboxsys.com> <285f2d2e-13fd-7cdc-c816-fba759f0745b@dusatko.org> <CAH48ZfzhyZK3RQHXH-PPk=sqY9gOtpA85vV-Myyo_RrEvOGu-Q@mail.gmail.com> <CAEYhs4F9=GDsCuQ9pAi8z-MBNHUJ9jZCwipT3Qe_YjaD65s9mA@mail.gmail.com> <CAH48Zfz-GRvXhOAWYn_mAypyoWm4L3=BKBxJad6X5NSFDD83yQ@mail.gmail.com>
From: Jan Dušátko <jan@dusatko.org>
In-Reply-To: <CAH48Zfz-GRvXhOAWYn_mAypyoWm4L3=BKBxJad6X5NSFDD83yQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/1Bkzz5VH-0eRVe-G1RNKMe41QNc>
Subject: Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 18 Jun 2023 20:56:45 -0000
Douglas, In my opinion, quite a number of administrators are aware of this possibility. But if someone were to send an e-mail for an organization (I mean a counterfeit e-mail), the recipient doesn't have a chance to verify whether the sender is actually using DKIM or not. The attacker can take advantage of this and just won't add a digital signature (I miss ADSP, I liked this standard). SPF at least to some extent limits where this e-mail can leave from. DMARC requires using SPF or DKIM or SPF and DKIM. If neither method is used, DMARC can report the situation, but it won't prevent receipt (m'I correct?). And the basic problem is just how to give the recipient of e-mails from the organization the tools to verify. Because it's nothing but authenticity verification. No one else can define this policy. Because there are cases where each of these methods has a legitimate use. But at the moment, trying to provide exhaustive information that the recipient could verify is extremely challenging. Such a policy must be unambiguous, it must not allow undefined behavior ... that is, I'm getting to the status machine. The policy conditions are not met, that is, the e-mail is rejected or falls into quarantine. In my opinion, DMARC2 is a good way to solve some problems, but I would personally like to see the possibility of specifying control mechanisms based on the owner's decision. I would also like to see a specification of what quarantine means. It's marking, moving into user or system quarantine, deteriorating scores ... Likewise, I would leave it up to the recipient to carry out the controls. It's in his interest, but it's his decision. Thank you Jan Dne 18. 6. 2023 v 19:56 Douglas Foster napsal(a): > I suspect that many domain owners have not considered the possibility of > using DKIM with SPF NONE. > > Then there is the concern about evaluators that understand SPF but do not > understand DMARC. Do they treat SPF NONE as acceptable or suspicious? > > For your situation Ken, do your clients have the ability to connect their > web-generated email to a DKIM signing server? If not, do you envision > providing that service (with SPF AUTH login to ensure clients are kept > separate from each other))? > > DF > > On Sat, Jun 17, 2023 at 5:39 PM Ken Simpson <ksimpson@mailchannels.com> > 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. >> While one option would be to allow the specification within the DMARC >> record of acceptable authentication methods, removing SPF altogether would >> be more straightforward. >> >> Domain owners constantly struggle to keep their SPF records up to date. >> Errors are easy to make, and the consequences of a mistake can be grave, >> particularly for domains that are a frequent target of phishing gangs. >> >> At least with DKIM, domain owners can take charge of their authentication >> rather than delegating any part of it to third parties (for instance, via >> spf include records). >> >> Regards, >> Ken >> >> On Sat, Jun 17, 2023 at 11:25 AM Douglas Foster < >> dougfoster.emailstandards@gmail.com> wrote: >> >>> In general, message recipients lack the expertise needed to distinguish >>> between legitimate and fraudulent identities. Most users do not know how >>> to read message headers or how to make sense of them if shown. Whenour >>> automated evaluation systems and administrative quarantine cannot resolve >>> an ambiguity, users cannot be expected to do better with less information. >>> Domain-specific tolerance for risk needs to be implemented with >>> domain-specific policies, but not with end-user discretion. >>> >>> DMARC has limited scope. In its purest form, it only blocks >>> impersonations when the domain has a DMARC policy, the policy specifies >>> enforcement (quarantine or reject), and the policy is detected correctly >>> (absence of PSL errors and absence of in-transit changes). Only a subset >>> of domains have a DMARC policy, and only a subset of those domains have >>> enforcement. So only a small percentage of impersonation attacks can be >>> protected by DMARC. For that very limited defense to work, domain owners >>> and evaluators need a high level of confidence in a PASS result. >>> Eliminating the PSL increases the confidence in PASS even if it creates >>> some increase in false failures. Eliminating SPF will have the same >>> effect, and is desirable for the same reason. Our assumption is that >>> DMARC-enforcing domain owners are highly motivated and will reconfigure as >>> necessary to ensure DMARC PASS results. >>> >>> This same logic raises questions about whether relaxed authentication >>> remains necessary or appropriate. With SPF, relaxed authentication seems >>> necessary because changing the MailFrom domain to match a desired From >>> domain is complex. For DKIM, I see no important obstacles which prevent >>> the signature domain from exactly matching the From domain. >>> >>> ARC addresses the one problem that domain owners cannot prevent, which is >>> forwarding with in-transit changes. >>> >>> Evaluators and recipients have a much larger problem. They need to >>> protect themselves from all impersonation attacks, which DMARC does not >>> attempt. Their defenses must be implemented within the limits of >>> information available at evaluation time. If the message has a relevant >>> DKIM signature but no DMARC policy, the DKIM PASS is still a valid >>> indication that the message is not impersonated. Similarly, if the >>> message has no signature but produces SPF PASS with exact alignment, the >>> SPF PASS result indicates that the message is probably not impersonated. >>> Conversely, SPF FAIL and SPF NONE service to increase the suspicion of an >>> impersonation. >>> >>> Evaluators use sender authentication to perform a three-way split on >>> messages: >>> - Messages from verified and highly trusted senders are allowed to bypass >>> some or all content filtering. >>> - Messages from unwanted senders are unconditionally blocked prior to >>> content filtering. >>> - Messages from all other senders are accepted if they pass content >>> filtering. >>> >>> The more effective your sender authentication, the less you need perfect >>> content filtering. Similarly, the more perfect your content filtering, >>> the less you need optimal sender authentication. >>> >>> In summary, your instincts are correct, SPF has a long term role in your >>> defenses, even if it is not part of the DMARC specification. >>> >>> Doug Foster >>> >>> On Sat, Jun 17, 2023 at 8:28 AM Jan Dušátko <jan= >>> 40dusatko.org@dmarc.ietf.org> wrote: >>> >>>> Hi >>>> >>>> I would like to know your opinion on the options currently available to >>>> the system administrator. If it is trying to define a policy that allows >>>> recipients to authenticate emails, its options are, in my opinion, >>>> limited. >>>> - The issue of SPF and cloud systems mentioned, or including over >>>> networks with mask /8 or /16 is extremely inappropriate >>>> - It is not possible to set up the enforcement of DKIM signatures >>>> because DomainKey and its policies are not related to DKIM and there is >>>> no similar technology for DKIM (ADSP is not used) >>>> - If I am the administrator of hundreds or thousands of domains, it is >>>> in my interest to provide the recipient with information about the >>>> sender's authentication options. For example, all emails use DKIM, all >>>> emails use ARC, all emails use SPF ... and if not, you can discard them. >>>> But I do not have this option with DMARC. >>>> I understand that this is in the middle of what DMARC2 is supposed to >>>> address. But could there be a possibility for the DMARC2 record >>>> administrator to define a policy for domains and provide relevant >>>> information for recipients? It is the recipient's decision whether to do >>>> this verification, but it is also the sender's decision to offer this >>>> information. Unfortunately, at this point, either the signature is >>>> valid, or wrong, or it is not. If it is not possible to accept the >>>> e-mail, but the recipient does not have the option of verifying whether >>>> the sender's domain enforces this signature. It is similar with SPF. And >>>> DMARC2 seems to me to be a good place for these definitions. But I would >>>> like to avoid of forced removal of SPF, please let it for administrator >>>> decision. >>>> >>>> Regards >>>> >>>> Jan >>>> >>>> Dne 16. 6. 2023 v 13:28 Sebastiaan de Vos napsal(a): >>>>> The need for separate DKIM failure codes to be able to separate >>>>> between in-transit changes and public key errors is more than just >>>>> valid and I don't consider SPF worthless in general, but I just find >>>>> it disturbing how the obviously misplaced confidence in SPF currently >>>>> weakens the whole DMARC standard. >>>>> >>>>> Is it not in our best interest to encourage and motivate in particular >>>>> the less sophisticated senders to use the higher confidence mechanisms? >>>>> >>>>> >>>>> On 16.06.23 13:02, Douglas Foster wrote: >>>>>> RFC 7489 takes 8 different authentication mechanisms and lumps them >>>>>> into a single PASS result: >>>>>> DKIM or SPF, each with up to four types of alignment: same domain, >>>>>> parent->child, child->parent, and sibling->sibling >>>>>> >>>>>> These eight mechanisms all provide some level of confidence that the >>>>>> message is not impersonated, but they do not provide an equal level >>>>>> of confidence. >>>>>> >>>>>> Unsophisticated senders have little incentive to use the higher >>>>>> confidence mechanisms because any PASS result is still PASS. The >>>>>> solution is not to pretend that SPF is worthless, because that is an >>>>>> overstatement. The solution is to talk about the differences in >>>>>> confidence provided by the different authentication methods, and note >>>>>> that evaluators have reason to distrust some of them. That distrust >>>>>> could cause a weakly authenticated message to be distrusted by some >>>>>> evaluators. >>>>>> >>>>>> Similarly, needs multiple types of FAIL. Since the data indicates >>>>>> that missing (or invalid) public keys are a significant portion of >>>>>> all failures, it needs a separate failure code from "normal" failures >>>>>> which suggest in-transit changes. The DKIM group needs to define the >>>>>> result code but this group would need to integrate it into our >>>>>> aggregate reports. >>>>> >>>> -- >>>> -- --- ----- - >>>> Jan Dušátko >>>> >>>> Tracker number: +420 602 427 840 >>>> e-mail: jan@dusatko.org >>>> GPG Signature: https://keys.dusatko.org/E535B585.asc >>>> GPG Encrypt: https://keys.dusatko.org/B76A1587.asc >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> -- >> >> Ken Simpson >> >> CEO, MailChannels >> <https://www.mailchannels.com/?utm_source=Email%20Signature&utm_medium=Ken%20Simpson&utm_campaign=Website> >> >> >> Facebook <http://bit.ly/2dnoP3K> | Twitter <http://bit.ly/2ehoWni> | >> LinkedIn <http://bit.ly/2dw87lU> | Help Center >> <https://mailchannels.zendesk.com/hc/en-us?utm_source=Email%20Signature&utm_medium=Ken%20Simpson&utm_campaign=Help%20Center> >> >> Our latest case study video: watch here! >> <https://www.youtube.com/watch?v=psb41xDIL9k> >> -- -- --- ----- - Jan Dušátko Tracker number: +420 602 427 840 e-mail: jan@dusatko.org GPG Signature: https://keys.dusatko.org/E535B585.asc GPG Encrypt: https://keys.dusatko.org/B76A1587.asc
- [dmarc-ietf] DMARC2 & SPF Dependency Removal Tobias Herkula
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Murray S. Kucherawy
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Seth Blank
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Barry Leiba
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Seth Blank
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Barry Leiba
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Barry Leiba
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Seth Blank
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Tobias Herkula
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Scott Kitterman
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Scott Kitterman
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Seth Blank
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Barry Leiba
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Tobias Herkula
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Benny Pedersen
- Re: [dmarc-ietf] version bump to DMARC2 John Levine
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Hector Santos
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Hector Santos
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Dotzero
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Barry Leiba
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Dotzero
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Scott Kitterman
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Barry Leiba
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Scott Kitterman
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Douglas Foster
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Barry Leiba
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Barry Leiba
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Barry Leiba
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Alessandro Vesely
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Barry Leiba
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Brotman, Alex
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Murray S. Kucherawy
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Scott Kitterman
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Alessandro Vesely
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Alessandro Vesely
- Re: [dmarc-ietf] version bump to DMARC2 Emil Gustafsson
- Re: [dmarc-ietf] version bump to DMARC2 Barry Leiba
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Barry Leiba
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Hector Santos
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Barry Leiba
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Hector Santos
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Barry Leiba
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Murray S. Kucherawy
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Alessandro Vesely
- Re: [dmarc-ietf] Errors in the tree walk, was ver… Alessandro Vesely
- [dmarc-ietf] Version bump: was DMARC2 & SPF Depen… Scott Kitterman
- Re: [dmarc-ietf] Version bump: was DMARC2 & SPF D… Tim Wicinski
- Re: [dmarc-ietf] Version bump: was DMARC2 & SPF D… Scott Kitterman
- Re: [dmarc-ietf] Version bump: was DMARC2 & SPF D… Tim Wicinski
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Jesse Thompson
- Re: [dmarc-ietf] PSD flag vs Version bump John Levine
- Re: [dmarc-ietf] PSD flag vs Version bump Barry Leiba
- Re: [dmarc-ietf] PSD flag vs Version bump John R Levine
- Re: [dmarc-ietf] PSD flag vs Version bump Scott Kitterman
- Re: [dmarc-ietf] PSD flag vs Version bump Richard Clayton
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Richard Clayton
- Re: [dmarc-ietf] Version bump: was DMARC2 & SPF D… Alessandro Vesely
- Re: [dmarc-ietf] PSD flag vs Version bump Alessandro Vesely
- Re: [dmarc-ietf] PSD flag vs Version bump Barry Leiba
- Re: [dmarc-ietf] version bump to DMARC2 Emil Gustafsson
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Jim Fenton
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Hector Santos
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Barry Leiba
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Tero Kivinen
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Barry Leiba
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Douglas Foster
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Murray S. Kucherawy
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Seth Blank
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Alessandro Vesely
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Richard Clayton
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Tero Kivinen
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Tero Kivinen
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Tero Kivinen
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Scott Kitterman
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Murray S. Kucherawy
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Alessandro Vesely
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Sebastiaan de Vos
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Douglas Foster
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Alessandro Vesely
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Sebastiaan de Vos
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Michael Kliewe
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Jan Dušátko
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Douglas Foster
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Ken Simpson
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Murray S. Kucherawy
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Hector Santos
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal John Levine
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Hector Santos
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Douglas Foster
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Jan Dušátko
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Ken Simpson
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Barry Leiba
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Alessandro Vesely
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Patrick Ben Koetter
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… John R Levine
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Benny Pedersen
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Wei Chuang
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal David Verdin
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Alessandro Vesely
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Tobias Herkula
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Douglas Foster
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Scott Kitterman
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Todd Herr
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal John Levine
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Alessandro Vesely
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Todd Herr
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Alessandro Vesely
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Sebastiaan de Vos
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Douglas Foster
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Sebastiaan de Vos
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Todd Herr
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Sebastiaan de Vos
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Scott Kitterman
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Douglas Foster
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Murray S. Kucherawy
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Barry Leiba
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Dotzero
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Hector Santos
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Hector Santos
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Ken Simpson
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Emil Gustafsson
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… John Levine
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Emanuel Schorsch
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Douglas Foster
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… John R Levine
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Hector Santos
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Emanuel Schorsch
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… John R Levine
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Emanuel Schorsch
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Hector Santos
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Barry Leiba
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… John R Levine
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Hector Santos
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Barry Leiba
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Douglas Foster
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Alessandro Vesely
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Alessandro Vesely
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Hector Santos
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Hector Santos
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Jan Dušátko
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Barry Leiba
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Florian.Kunkel
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Scott Kitterman
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Jan Dušátko
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Murray S. Kucherawy
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Alessandro Vesely
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Douglas Foster
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Barry Leiba
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… John Levine
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Alessandro Vesely
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Alessandro Vesely
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Douglas Foster
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Barry Leiba
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Tobias Herkula
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Hector Santos
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Hector Santos
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Hector Santos
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Alessandro Vesely
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Barry Leiba
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Scott Kitterman
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Douglas Foster
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Emanuel Schorsch
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Murray S. Kucherawy
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Douglas Foster
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Murray S. Kucherawy
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… John Levine
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Barry Leiba
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Tero Kivinen
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Jan Dušátko
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Alessandro Vesely
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Murray S. Kucherawy
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Hector Santos
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Hector Santos
- Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Depend… Tero Kivinen
- [dmarc-ietf] Why does DKIM fail when SPF succeeds… Matthäus Wander
- Re: [dmarc-ietf] Why does DKIM fail when SPF succ… Murray S. Kucherawy
- Re: [dmarc-ietf] Why does DKIM fail when SPF succ… Matthäus Wander
- Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal Neil Anuskiewicz
- Re: [dmarc-ietf] Why does DKIM fail when SPF succ… OLIVIER HUREAU
- Re: [dmarc-ietf] Why does DKIM fail when SPF succ… Matthäus Wander