FYI
-- Forwarded message -
From: IESG Secretary
Date: Thu, May 9, 2024 at 1:01 PM
Subject: WG Action: Formed Mail Maintenance (mailmaint)
To: IETF Announcement List
Cc: , ,
A new IETF WG has been formed in the Applications and Real-Time Area. For
additional information,
I have a slightly different viewpoint:
On Mon, Apr 22, 2024 at 4:31 PM John R. Levine wrote:
> Since nobody else responded, here's my tl;dr -- interesting proposal, but
> no.
>
> The first problem is that there is no appetite to change ARC at this point.
>
Agreed. That was a long list of
FYI only. Please don't discuss this here; send feedback to me directly or
to i...@ietf.org.
-MSK, ART AD
-- Forwarded message -
From: The IESG
Date: Fri, Apr 19, 2024 at 10:25 AM
Subject: WG Review: Mail Maintenance (mailmaint)
To: IETF-Announce
A new IETF WG has been
On Mon, Apr 15, 2024 at 7:02 AM Todd Herr wrote:
>
> I would propose the following first draft of expository text regarding
> setting N at 8:
>
> The point of the Tree Walk is to allow for the publishing and discovery of
> DMARC policy records at any level in the DNS hierarchy that strikes a
>
On Sun, Apr 7, 2024 at 10:33 AM Scott Kitterman
wrote:
> >Seth says there are people who need N=8 but for business reasons he can't
> tell us who they are. I'm not thrilled about that but I see little
> downside to bumping the number up to 8.
>
> I expect that's where we end up, but I think we
On Thu, Apr 4, 2024 at 12:02 PM Dotzero wrote:
>
>
>>
>> My overall point is that this thread makes it seem like we're not putting
>> forward a complete solution. It feels a lot more like a proposed standard
>> that for its clear success depends on a bunch of other things that range
>> from
On Thu, Apr 4, 2024 at 10:21 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> Murray, I was hoping your proposal to advance ARC was serious.
>
If people think (and have evidence that) ARC is ready, then why would I not
be serious?
The WG needs to resolve that "if" though.
>
On Thu, Apr 4, 2024 at 8:50 AM Alessandro Vesely wrote:
> > I know what "contract" means abstractly, but what does this actually
> look
> > like to someone that's looking for specific guidance? The text you have
> > here, by itself, is vague and I don't think many operators will know
> what
> >
On Wed, Apr 3, 2024 at 4:16 AM Alessandro Vesely wrote:
> > So what are you suggesting should go in this document that's in WGLC?
>
> Section 8.6 states the ML problem very well, but it says nothing about the
> way forward.
Here, we agree. And I'm saying: If we have anything concrete we can
On Tue, Apr 2, 2024 at 9:03 AM Seth Blank wrote:
>
> I think details about the technique to which you're alluding, especially
>> with real world examples, anecdotes, or other data, would be really
>> valuable to publish somewhere, be that in this document or elsewhere. Even
>> just a paragraph
On Tue, Apr 2, 2024 at 9:01 AM Alessandro Vesely wrote:
> By now, most mailing lists arranged to either rewrite From: or not
> break
> DKIM signatures. We all hope those hacks are temporary.
> >>>
> >>> What do you mean by "temporary", given the time scales that have
> already
> >>>
On Tue, Apr 2, 2024 at 8:49 AM John Levine wrote:
> It appears that Murray S. Kucherawy said:
> >Can you give an example, even if only a hypothetical one?
>
> I'm not Emmanuel but people at large mail systems have told me that
> the biggest value of ARC is to deal with mai
Hi Emanuel,
On Tue, Apr 2, 2024 at 1:02 AM Emanuel Schorsch
wrote:
> Just to chime in, Gmail is using ARC and it has already provided a large
> amount of value for the indirect flow problem. Especially, since other
> major providers and a number of forwarders are adding ARC headers that
>
On Tue, Apr 2, 2024 at 3:01 AM Alessandro Vesely wrote:
> >> By now, most mailing lists arranged to either rewrite From: or not
> break
> >> DKIM signatures. We all hope those hacks are temporary. >
> >
> > What do you mean by "temporary", given the time scales that have already
> > passed
On Mon, Apr 1, 2024 at 4:05 PM John Levine wrote:
> >"One possible mitigation to problem X is [ARC], which provides for a
> >mechanism to demonstrate 'chain-of-custody' of a message. However, use of
> >ARC is nascent, as is industry experience with it in connection with
> DMARC."
>
> Generally
On Mon, Apr 1, 2024 at 11:33 AM Todd Herr wrote:
> The second document also recommends that receivers "Make use of ARC
> headers", but I do not believe that ARC header consumption is yet
> widespread enough to consider that recommendation to be commonly
> implemented. I myself am not a receiver,
On Sun, Mar 31, 2024 at 6:37 PM Seth Blank wrote:
> "It is therefore critical that domains that host users who might post
> messages to mailing lists SHOULD NOT publish p=reject."
>
> [...]
>
> More accurate language that alleviates the concern would be "It is
> therefore critical that domains
On Mon, Apr 1, 2024 at 4:44 AM Alessandro Vesely wrote:
> > * Mailing lists — Mailing list operators, including ietf.org, have had
> to
> > implement rewriting of From addresses such as u...@example.com becomes
> > user=40example@dmarc.ietf.org when a p=strict or p=quarantine
> policy is in
On Sun, Mar 31, 2024 at 3:28 PM Richard Clayton
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> In message 7...@mail.gmail.com>, Seth Blank
> writes
>
> >Some Mail Receiver architectures implement SPF in advance of any
> >DMARC operations. This means that an SPF hard fail
On Sun, Mar 31, 2024 at 9:32 AM Alessandro Vesely wrote:
> On Sun 31/Mar/2024 14:22:04 +0200 Douglas Foster wrote:
> > On SPF, our document should say simply,
> > " a DMARC-compliant evaluator MUST NOT reject a message, based on SPF
> result,
> > prior to receiving the Data section and checking
On Sun, Mar 31, 2024 at 5:22 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> On SPF, our document should say simply,
> " a DMARC-compliant evaluator MUST NOT reject a message, based on SPF
> result, prior to receiving the Data section and checking for aligned and
> verifiable
On only the charter point:
On Sat, Mar 30, 2024 at 2:27 PM Jim Fenton wrote:
>
> >> ??? Not Found
> >> -
> >>
> >> I expected to find some text at least recommending a rewriting strategy
> for From addresses to be used by mailing lists and the like.
> >
> > That would be extremely
This seems like it's probably legitimate. Does it need to be fixed in the
-bis document?
-MSK
-- Forwarded message -
From: RFC Errata System
Date: Sat, Mar 23, 2024 at 8:04 AM
Subject: [Technical Errata Reported] RFC7489 (7865)
To: , ,
Cc: ,
The following errata report has
On Fri, Mar 22, 2024 at 12:59 AM Scott Kitterman
wrote:
> >> For t=y, DKIM says:
> >>
> >>y This domain is testing DKIM. Verifiers MUST NOT treat
> messages
> >> from Signers in testing mode differently from unsigned email,
> >> even should the signature fail to
On Mon, Mar 18, 2024 at 1:08 PM Dotzero wrote:
>
> Add this to 11.1 Authentication Methods
>>
>>
>> Both of the email authentication methods that underlie DMARC provide
>> some assurance that an email was transmitted by an MTA which is
>> authorized to do so. SPF policies map domain names to
On Fri, Mar 15, 2024 at 9:11 AM John Levine wrote:
> It appears that Todd Herr said:
> >I agree that clarifying it can't hurt, obviously, ...
>
> I disagree, it does hurt.
>
> If we say you're allowed to use CNAMEs to point to DMARC records,
> people are to say uh oh, is there something
On Fri, Mar 15, 2024 at 12:55 AM Alessandro Vesely wrote:
> On Thu 14/Mar/2024 15:47:14 +0100 Todd Herr wrote:
> > On Tue, Mar 12, 2024 at 5:19 AM Alessandro Vesely
> wrote:
> >> On 12/03/2024 03:18, Neil Anuskiewicz wrote:
> >> > Please remove the pct tag from the spec.
> >>
> >> It has been
On Fri, Mar 15, 2024 at 3:20 AM John Levine wrote:
> As an author of the ADSP RFC, I enthusiastically support dropping it
> into the memory hole. It was a bad idea then and time has not improved
> it.
I tend to agree. That appendix was meant to answer the question "Why DMARC
and not ADSP?"
On Thu, Mar 14, 2024 at 9:17 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> All of this is based on my slightly confrontational comment that "Tree
> Walk is inefficient and unreliable", which maybe needs elaboration. My
> approach to the problem changed dramatically when I
On Tue, Mar 12, 2024 at 6:23 AM Tobias Herkula wrote:
> The DMARC Record on the DKIM signing domain is not relevant for DMARC
> evaluation, so if the 5322.From header domain is “example.com” the
> “adkim:r” is relevant for evaluation regarding your example setup and would
> consider a DKIM
On Sat, Mar 9, 2024 at 4:00 PM Tim Wicinski wrote:
> Just picking over the ABNF with my checks, some Qs
>
> dmarc-version = "v" equals %s"DMARC1
>
>
> I believe the "%s" should be dropped
>
I think this was intentional; we want "v=DMARC1" to be valid and "v=dmarc1"
to be not valid. Unless I'm
On Fri, Mar 8, 2024 at 6:49 AM Alessandro Vesely wrote:
> since we removed the rf= tag (format of failure reports), do we still
> need to tackle the IANA registry? Since we only use one format, it
> makes little sense. However, the registry actually exists. Is it
> possible to delete or
Heads up that I'm going to be looking carefully at use of "SHOULD"
throughout the document when it comes to AD Evaluation. An example that
gave me pause:
On Tue, Mar 5, 2024 at 6:30 AM Alessandro Vesely wrote:
> in section 5.5.1, Publish an SPF Policy for an Aligned Domain, the last
> sentence
On Wed, Mar 6, 2024 at 11:42 AM Todd Herr wrote:
> The text reported in the erratum doesn't really exist in DMARCbis; it's
> been replaced by the DNS Tree Walk (
> https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-30.html#name-dns-tree-walk
> )
>
> Are we to issue an actual update to RFC
Since we're in WGLC here, this erratum is worth consideration. I've
recommended "Held For Document Update" as the disposition.
My reply to the erratum was:
===
The algorithm as presented is correct, but I understand this report.
The steps are, paraphrased:
(1) Go get a set of things.
(2)
On Fri, Mar 1, 2024 at 5:20 PM Seth Blank wrote:
> mailto: is the only function that's ever been used. We even discussed
> exploring other mechanisms, and consensus was to drop that exploration. I
> can't find the ticket quickly, but I know it was covered early on during
> the bis work.
>
> Do
On Thu, Feb 29, 2024 at 2:14 PM Seth Blank wrote:
> As Chair: Consensus was already called. Todd just wants the wording
> consistent in the document. There's no need for another decision here.
>
This is my understanding as well. Mike Hammer summarized it neatly.
-MSK
On Sat, Feb 10, 2024 at 12:34 PM Jim Fenton wrote:
> > No, it's perfectly fine to declare that DMARC only applies to certain
> > classes of messages.
>
> This actually concerns me a bit. If having multiple From: addresses causes
> a message to be out of scope for DMARC and therefore bypass a
en a DKIM
> Signature is missing it should be treated as an error.
>
> There is currently no way to indicate that.
>
Why is DMARC the right place to fix that problem? It seems like you want a
way to assert this even if the receiver isn't. using DMARC.
> > On 6 Feb 2024,
On Tue, Feb 6, 2024 at 2:33 AM Jeroen Massar wrote:
> `req=dkim`: requires DKIM, messages not properly signed are then to be
> rejected/quarantined based on 'p' policy.
>
This sounds like what RFC 5617 tried to do, minus the constraint that the
signing domain be equal to the author domain,
On Mon, Feb 5, 2024 at 10:56 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> The evidence from Google is that multi-valued From DOES have usage and is
> usually malicious. That should be sufficient evidence to conclude l that
> the security hole must be plugged, not ignored.
>
On Mon, Feb 5, 2024 at 10:22 AM Alessandro Vesely wrote:
> On 05/02/2024 00:29, Murray S. Kucherawy wrote:
> > On Sun, Feb 4, 2024 at 5:25 AM Alessandro Vesely wrote:
> >
> >>> What do we think has changed since then that warrants reconsidering
> that
> >
On Sun, Feb 4, 2024 at 5:25 AM Alessandro Vesely wrote:
> > What do we think has changed since then that warrants reconsidering that
> > position? Have we started to see multi-value From attacks?
>
> A DMARC filter has to do something when it sees a multi-value From:.
Why? It hasn't so far
On Sun, Jan 28, 2024 at 5:40 AM Alessandro Vesely wrote:
> > I think this point about alignment of Sender is definitely correct,
>
> Let's also recall there was a proposal to consider Sender: anyway.
>
And also let's recall that the community has previously rejected the idea
of involving Sender
On Wed, Jan 17, 2024 at 2:56 AM Alessandro Vesely wrote:
> Since email format allows multi-valued From:, its meaning is
> straightforward.
>
Syntax, yes, but meaning? That seems debatable. Does the order of values
matter, for example?
As John says, it can also be the result of some kind of
On Tue, Jan 16, 2024 at 10:24 AM Murray S. Kucherawy
wrote:
> As I recall, with milter in particular, the MTA will add a missing Date
> field, which the filter never actually sees and thus cannot sign. The
> filter only sees the message exactly as it was presented to the MTA. As a
On Tue, Jan 16, 2024 at 2:03 AM Alessandro Vesely wrote:
> On Mon 15/Jan/2024 20:49:35 +0100 John Levine wrote:
> > It appears that Scott Kitterman said:
> >>I don't think that's sensible at all. It's not the place of a signing
> filter to modify the message.
>
> A signing filter, as part of
In addition to what Todd offered:
On Thu, Jan 11, 2024 at 11:51 AM Damien Alexandre wrote:
> The RFC first states:
>
> "Messages bearing a single RFC5322.From field containing multiple
> addresses (and, thus, multiple domain names to be evaluated) are
> typically rejected because the sorts of
On Tue, Jan 9, 2024 at 8:07 AM Benny Pedersen wrote:
> dkim spec should not allow reject of failed dkim, this is a job for
> dmarc, but this have to be solved first
>
It doesn't (or at least it's a "SHOULD NOT")[1].
-MSK
[1] RFC 6376, Section 6.3, paragraph 2
On Thu, Nov 23, 2023 at 9:19 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> The gap between what is being attempted and what is needed is a huge
> personal disappointment.
>
You have made your disappointment plain more times than I can remember.
It's on the record each of
On Tue, Nov 14, 2023 at 5:33 AM Seth Blank wrote:
> As Chair, Douglas, again, what operational issue per charter are you
> trying to address, and where is your suggested text to address?
>
I agree, this far exceeds DMARC's charter. None of this to say the topic
is not one worth exploring, but
On Wed, Nov 8, 2023 at 7:04 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> Charter Goal: The protocol will cause Evaluators to accept mailing list
> posts without From munging (as long as the list is a legitimate operator)
>
Can you please point to the place in the charter
At the chairs' request, the DMARC meeting at IETF 118 has been canceled.
-MSK, ART AD
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
On Sun, Oct 29, 2023 at 12:35 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> By contrast, the new tag cannot be effective until DMARCbis is published
> and filtering software updated. This involves years. Even then, domain
> owners will never have confidence that the new
On Sat, Oct 28, 2023 at 8:28 AM Richard Clayton
wrote:
> Paying attention to the (sometimes inferred) age of a signature is also
> important for reducing the opportunity for replay, viz: it would be a
> Good Thing for senders to set appropriately short expire times.
>
Why does it have to be
On Wed, Oct 25, 2023 at 9:33 AM Richard Clayton
wrote:
> >The operator is making the decision to publish or enforce, not the
> >user.
>
> Looking at $DAYJOB$ logs for this week I see a shade under 300 people
> who are participating in IETF working groups using p=reject addresses.
>
> I
On Wed, Oct 25, 2023 at 8:17 AM Richard Clayton
wrote:
> So might I suggest a wording that captures what will actually happen in
> the real world
>
> Domains that choose to publish p=reject SHOULD inform the people
> using those domains of the issues that may arise if theu post to
>
On Tue, Oct 24, 2023 at 11:11 PM Steven M Jones wrote:
> On 10/20/23 12:35 PM, Murray S. Kucherawy wrote:
>
> (1) As written, the text says (to me) that the handling of a message might
> change depending on this mapping of a broken value to "none", but only if
> &quo
On Tue, Oct 24, 2023 at 11:15 AM 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
On Tue, Oct 24, 2023 at 5:34 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> In short, I am not part of the presumed consensus on this document. I will
> vigorously oppose any document which does not discuss malicious
> impersonation defenses for every domain.
>
Doug,
A
[trimming redundant Ccs]
On Tue, Oct 24, 2023 at 9:41 AM Dotzero wrote:
> I'd like to first thank Francesca for taking the time to review where the
> working group is as far as consensus.
>
+1, that was a lot to sift through.
The short version of the non-normative language should be in the
On Tue, Oct 24, 2023 at 8:57 AM Scott Kitterman
wrote:
> My understanding of IETF consensus is that technical objections have been
> addressed. I think this is critical to the difference between IETF
> consensus and voting. It's not just 'most people think X'. I don't think
> that the
On Mon, Oct 23, 2023 at 9:07 PM Scott Kitterman
wrote:
> I don't think this is consistent with the IETF's mandate to provide
> documents
> which promote interoperability. I do not, however, plan to file an appeal
> about it.
>
Two things to say about that:
(1) This is Francesca's
On Mon, Oct 23, 2023 at 12:04 PM Brotman, Alex wrote:
> I should note that generally, while there's an "error" field available,
> there's no guidance about what should go in there. (not in 7489 either that
> I could find in a brief search)
>
Has there ever been any push for structured content
On Mon, Oct 16, 2023 at 8:35 PM Neil Anuskiewicz wrote:
> The reference to DBOUND was sparked by looking around at what w3aawg was
> saying as I generally think they have some good papers and a great video
> series on email authentication. But what I found on DBOUND isn’t
> endorsement. They
On Fri, Oct 20, 2023 at 12:05 AM OLIVIER HUREAU <
olivier.hur...@univ-grenoble-alpes.fr> wrote:
> I don't understand the choice made when writing the point 6. of the policy
> discovery mechanism (Dmarcbis :
> https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-28.html#section-4.7
> )
>
>
On Tue, Oct 17, 2023 at 6:51 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> Why do we need to support relaxed alignment at all?
>
Because the charter says:
The working group will seek to preserve interoperability with the
installed base of DMARC systems, and provide
On Tue, Sep 19, 2023 at 8:24 AM Alessandro Vesely wrote:
> My wording can certainly be improved. Before denying the idea, please
> consider
> a couple of facts:
>
> 1) We want ARC to override DMARC, yet we don't say so. Not in such a way
> that,
> when a receivers does so, he can say he's
On Tue, Sep 19, 2023 at 6:13 AM Dotzero wrote:
>
>
>> No. I think this section is currently, correctly, focused on what to do
>> with only references to why. I don't think we should change that. If the
>> current references are inadequate, then we should improve them, not attempt
>> to restate
On Sun, Sep 17, 2023 at 2:47 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> We have established that the normative implementation of DMARC is
> (unfortunately) a fully-automated solution which implements RFC 7489
> exactly and nothing more.
>
Sure, but why would you do that,
On Sun, Sep 17, 2023 at 11:04 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> You misunderstsnd my position. I don't expect a world where perfect
> information is dropped in my lap without any effort on my part. Not now,
> not ever.
>
> I have determined, by measurement, that
On Wed, Sep 13, 2023 at 6:01 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> Let's analyze the problem Jim raises, using it to answer Hector's question
> about where responsibility lies.
>
> Our assumed reference model is a fully automated, by-the-spec
> implementation of RFC
One thing I forgot to mention:
On Thu, Sep 7, 2023 at 9:29 AM Wei Chuang wrote:
> Our suggestion is that there is not a lot of value in including this
> language in the bis document if the likely outcome is that it will be
> ignored, and rather more effort should be placed with a technical
On Sat, Sep 9, 2023 at 11:16 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> I understand the phased roll-out goal, but phased rollout and percentages
> are not applicable to the evaluator's task.
>
> I start with an assumption that message sources reflect the character of
>
I'm not looking to change the WG's mind on this matter, but:
On Sat, Sep 9, 2023 at 3:54 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> There are many percentages mixed up together in this issue:
>
>- The percentage of domain message sources which provide proper
>
On Thu, Sep 7, 2023 at 9:29 AM Wei Chuang wrote:
> Regarding the languages in section 8.6 "It is therefore critical that
> domains that host users who might post messages to mailing lists SHOULD NOT
> publish p=reject. Domains that choose to publish p=reject SHOULD implement
> policies that
Kitterman
> wrote:
> >
> >
> >
> > On August 7, 2023 7:47:03 PM UTC, "Murray S. Kucherawy" <
> superu...@gmail.com> wrote:
> > >On Sat, Aug 5, 2023 at 1:09 PM Tim Wicinski wrote:
> > >
> > >> Based on the ABNF in -28, how abo
On Sat, Aug 5, 2023 at 1:09 PM Tim Wicinski wrote:
> Based on the ABNF in -28, how about something like this:
>
>
> dmarc-method = "dkim" / "spf"
>
> dmarc-auth = "auth" equals dmarc-method *(*WSP "," *WSP dmarc-method)
>
>
> I think this "should"(*) allow for all permutations but also
On Fri, Aug 4, 2023 at 2:28 AM Alessandro Vesely wrote:
> > Collecting some data and doing some experimentation would be really
> helpful
> > toward determining the right path here, if any.
>
> Evaluating Sender: doesn't help whitelisting rejection before DATA.
>
Huh? I didn't say anything
On Thu, Aug 3, 2023 at 10:39 AM Hector Santos wrote:
> [...]
>
> However, at present, the most plausible use-case appears to be the
> addition of delayed SPF rejection scenarios through DMARC evaluation.
> Essentially, SUBMITTER/PRA serves as an optimizer and a mechanism to
> soften the impact
On Mon, Jul 31, 2023 at 9:47 AM Hector Santos wrote:
>- I mentioned using the deprecated SUBMITTER/PRA (RFC4405/RFC4407)
> protocols as an implementation detail to access the author's DMARC
> policy at the SMTP "MAIL FROM" stage. Wei expressed interest in this
> idea. This could also enhance
On Mon, Jul 31, 2023 at 11:59 AM Murray S. Kucherawy
wrote:
> [...] the idea of demanding all lists the world over start munging From
> fields (or whatever mutation we claim is now mandatory) will not happen in
> short order no matter how much we wish it would.
>
Just to be clear, m
On Mon, Jul 31, 2023 at 4:27 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> Murray has said that we cannot impose obligations on mailing lists,
> because he does not perceive them as DMARC participants.
>
I don't recall saying that. My perspective is that the "lists are
On Mon, Jul 24, 2023 at 9:13 AM OLIVIER HUREAU <
olivier.hur...@univ-grenoble-alpes.fr> wrote:
> > Correct, the ABNF doesn't allow this construction, so it's a syntax
> error.
>
> DMARCbis ABNF is not as restrictive as RFC 7489 :
>
>
> dmarc-record = dmarc-version *(dmarc-sep dmarc-tag)
On Mon, Jul 24, 2023 at 8:37 AM Mark Alley wrote:
> From my understanding, that would most likely result in a permerror code
> for evaluation, given that's not syntactically valid per the ABNF for the
> dmarc-record, see below where it only shows each tag once from section 6.4
>
On Sun, Jul 23, 2023 at 1:06 PM Matthäus Wander wrote:
> b) Messages are generated by an automated system without a Date header
> and signed by a central MTA. An outgoing mail gateway then adds the
> missing Date header (Postfix option 'always_add_missing_headers'), thus
> invalidating the DKIM
On Wed, Jul 19, 2023 at 6:31 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> I don't take DMARC as a certain result to be used in isolation, but
> clearly a quorum evaluators do, and hence the mailing list problem that has
> caused such consternation.
>
> If we want to diminish
On Fri, Jul 21, 2023 at 1:22 AM Matthäus Wander wrote:
> > "SHOULD" leaves the implementer with a choice. You really ought to do
> > what it says in the general case, but there might be circumstances where
> > you could deviate from that advice, with some possible effect on
> >
On Wed, Jul 19, 2023 at 12:27 AM Alessandro Vesely wrote:
> > How do you determine that an evaluator is enforcing DMARC "against
> lists"?
>
> That assumes there are lists that don't munge From:. Is that real today?
>
I wasn't aware that this munging had become a standard, or even common.
It's
On Tue, Jul 18, 2023 at 4:27 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> 1) For evaluators that enforce DMARC against lists, are they willing to
> consider any concessions to list traffic? If so, do they favor an
> exemption process where the list avoids munging, or an
On Thu, Jul 13, 2023 at 6:11 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> I did not say "life isn't fair" to be rude, but as a call to acknowledge
> the reality that exists rather than the reality you wish you had.
>
So what I'm hearing, again, is "Lists should get with the
On Thu, Jul 13, 2023 at 3:40 AM Scott Kitterman
wrote:
> >Google uses 5.7.26 for the purpose (and for SPF and DKIM rejects):
> >
> >https://support.google.com/a/answer/3726730?sjid=16541570162287939258-NA
> >
> >Their use of 5.7.26 seems in keeping with IANA - Multiple authentication
> >checks
On Wed, Jul 12, 2023 at 6:20 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> Does anyone believe that things will change if we publish an RFC which
> says "Verizon Media MUST change to p=none"? I don't.
>
It would be absurd to make such a directed statement. I trust you're
On Fri, Jul 7, 2023 at 6:14 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> Malicious impersonation creates a need for authentication. If the list
> makes changes that disable the originator's authentication, then it is the
> list's problem to find a way to convince the
On Fri, Jul 7, 2023 at 6:35 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> Consequently, the problem remains: How does an evaluator distinguish
> between a legitimate list and a malicious attack?
>
If we had a reliable answer to that, this would've been over ages ago.
Still no hat on.
I can see the compromise in language that's been proposed here, and I
appreciate the effort by the chairs.
Two things I'd like to raise. First:
On Thu, Jul 6, 2023 at 7:55 AM Barry Leiba wrote:
> It is therefore critical that domains that host users who might
>
On Thu, Jul 6, 2023 at 9:00 AM Marcello
wrote:
> Just to clarify, is it possible having this “bad” ARC header is skewing
> the final spam score of the email when it hits the final email service
> provider ?
>
Yes, it's possible. Or rather, it's impossible to know how the end
receiver is or is
On Thu, Jul 6, 2023 at 8:21 AM Barry Leiba wrote:
> > For clarity: When you say, "AD will call consensus on this issue", you
> mean after the results of the discussion
> > are brought to the list and reviewed by the working group, not at the
> meeting, right?
>
> Yes, correct. I wanted to make
On Fri, Jun 30, 2023 at 12:21 AM Jan Dušátko wrote:
> Scott, Barry,
> as far as I understand, SPF are historic technology,
>
Not in any official capacity. RFC 7208 is a Proposed Standard. In fact,
in IETF terms, it enjoys higher status than DMARC does right now.
The status of these protocols
On Fri, Jun 30, 2023 at 11:22 AM Todd Herr wrote:
> Why is the mechanism called "Domain-based Message Authentication,
> Reporting, and Conformance" and not "Domain-based Message Authentication,
> Reporting, and Disposition"? Perhaps a better question, why is
> "conformance" in the name of the
1 - 100 of 837 matches
Mail list logo
