Re: [dmarc-ietf] Using ARC to override DMARC FAIL

[Ken O'Driscoll]

Do you trust the ARC signer is the only appropriate policy test. Everything
else, including your "wanted and valued sender" test is a value judgement
for a message filter, not an ARC evaluation. If you trust the ARC signer of
a message, then you trust their assertion as to the authentication status
of the message at the point they signed it.

Ken.

On Mon 19 Sep 2022, 18:31 Douglas Foster, <
dougfoster.emailstanda...@gmail.com> wrote:

> I am trying to specify the generic form of a local policy rule to trust
> ARC to override DMARC FAIL.
> This is my current draft:
>
> - The message's RFC532.From address indicates a wanted and valued sender.
>
> - The message produces DMARC FAIL.
>
> - The ARC chain is intact
>
> - An ARC-A/R entry exists and indicates DMARC PASS, aligned SPF PASS, or
> aligned DKIM PASS.   If more than one such ARC set is found, the highest
> sequence number is used.
>
> - The IP address used for SPF is extractable from the comment field of
> that same ARC A/R record.
>
> - A Received header can be found with the same Source IP address, and
>
> - The rest of the Received chain is scanned forward, and all included
> servers are trusted to create only accurate message headers and to make
> only non-malicious changes to the message.  Given the unpredictability
>
> Can anyone simplify this formula?
>
> Doug Foster
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Collecting message metadata, was Time to work on failure reporting

[Ken O'Driscoll]

> 
> Any hint about why it's not used?
> 

PII. Report generators are reluctant to send reports that may contain PII for 
compliance, security, and privacy reasons.

Plus, if you are a report receiver those reasons may be valid too. What's the 
point in requesting failure reports if your email ops people are prohibited 
from actually reading them etc.

I don't think their use is ever going to grow and will probably further decline 
over the years.

Keeping it as-is for backwards compatibility is probably the best option. 

Ken.


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

Re: [dmarc-ietf] no zone cuts, no Shortcuts

[Ken O'Driscoll]

> 
> I still don't see any value in adding text like this.  The description
> of the tree walk is clear enough.

+1 (again), I don't understand why this is needed.

What problem statement is the proposed text attempting to address?

Ken.

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

Re: [dmarc-ietf] no zone cuts, no Shortcuts

[Ken O'Driscoll]

> 
> I'm with Barry.  I see no reason to mention zone cuts or anything like
> zone cuts at all.
> 
> They are not relevant to DMARC.  It would just confuse people.

+1

I also believe it to be unnecessarily confusing and distracting.

Ken.

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

Re: [dmarc-ietf] rfc8617

[Ken O'Driscoll]

The IETF have no control over how third parties choose to implement RFCs. If a 
vendor chooses not to implement a particular RFC because of its status, and 
that choice results in an interoperability issue, then that discussion is 
between the vendor and their customers - the IETF have no part to play in that 
conversation.

My personal opinion would be that Barracuda will choose to implement ARC long 
before it gets on the standards track simple because of the market force of 
their customers demanding it. I suspect that they are not the only filter 
vendor who needs to revaluate implementing ARC in light of Microsoft's decision.

The ARC WG may be a better place to ask about the development status of the 
protocol - https://www.ietf.org/mailman/listinfo/arc

Ken.

From: dmarc  On Behalf Of Andreas Niedermann
Sent: Friday 29 July 2022 10:40
To: dmarc@ietf.org
Subject: [dmarc-ietf] rfc8617


Hi there



My question is at which time rfc8617 will move from the experimental 
cathegory...

Microsoft uses ARC and many customers moved to Office365. They interact with 
outbound.protection.outlook.com. Many messages from this source are modified 
and break even relaxed/relaxed DKIM cannonication. Thus email from this domain 
is blocked and cannot reach our customers. We use barracuda filters and wanted 
to request DMARC and ARC features. Barracuda tells us that they're not 
implementing because of the experimental status. Weird... it's in state 
experimental and all giants like Microsoft and Google are using it...



Do you have some explaination?


Freundliche Grüsse
Andreas Niedermann

Armacom AG
Muttenzerstrasse 107
4133 Pratteln
Mail: andreas.niederm...@armacom.ch
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] What's the bis in DMARCbis?

[Ken O'Driscoll]

Bis means "again", in this case it refers to the next iteration of the DMARC 
specification. It's an IETF naming convention, nothing to do with DMARC or the 
working group specifically.

Ken.

> -Original Message-
> From: dmarc  On Behalf Of Damian Lukowski
> Sent: Monday 20 June 2022 12:00
> To: dmarc@ietf.org
> Subject: [dmarc-ietf] What's the bis in DMARCbis?
> 
> I have not found an explanation anywhere.
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc

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

Re: [dmarc-ietf] Tree walk in -06

[Ken O'Driscoll]

> 
> I don't think there is any other place where the default is not one of
> the explicit options.  The benefit of psd=u, such as it might be, is to
> make it more consistent, and to be clear that we really mean it when we
> say that psd=y, psd=n. and psd=u mean three different things.
> 
> This is not a big deal but I do think I've seen confusion, e.g., people
> wrongly concluding that all existing DMARC records will have to have
> psd=n added. (I suppose those people will now demand psd=u, so you can't
> win.)

+1 

Having different behaviour for the absence of the tag and the default value 
will be unnecessarily confusing and not intuitive.

Ken.

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

Re: [dmarc-ietf] (7.1?) DKIM-only authentication

[Ken O'Driscoll]

No. “?all” in an SPF record is a negative signal to many filters and a quick 
way to the spam folder. It also exposes the domain to abuse unconnected with 
DMARC.

If a sender intentionally relies on DKIM-only alignment, then that’s their 
decision. Making any recommendations as to what their SPF record should 
contain, other than being valid, is out of scope. Such recommendations are also 
prone to make operational assumptions. For example, assuming that the author 
domain is never going to be used in any other context, such as a 5321.From 
domain in a different message with a non-DMARC protected 5322.From domain. A 
specification tries to avoid such assumptions.

We also have ARC for cases where an intermediate MTA rewrites the 5321.From.

If we really need to spell out the potential risks of DKIM-only (or indeed 
SPF-only) alignment, then maybe a BCP document is a better place. It’s not like 
this is a widespread problem currently.

Ken.

From: dmarc  On Behalf Of Douglas Foster
Sent: Friday 11 February 2022 08:14
To: IETF DMARC WG 
Subject: [dmarc-ietf] (7.1?) DKIM-only authentication

I know that we took out the reference to default policy at my request, and I 
think it was in section 7.1.   But subsequent discussion helped me to 
understand objectives that were not clear to me in the previous text.   I think 
we need to re-insert something specific about domain owners that want DKIM-only 
authentication.   Proposed language:
“Some domain owners want DMARC authentication to use DKIM signatures only.   
This requires ensuring an SPF result other than PASS.  An SPF result of FAIL or 
SOFTFAIL is likely to produce unwanted rejects by non-DMARC evaluators.   An 
SPF result of NONE may be ineffective if an evaluator responds to NONE by 
applying a locally-defined default SPF policy that produces an unintended SPF 
PASS.   Domain owners who desired DKIM-only authentication are RECOMMENDED to 
publish a policy of “?ALL”, which ensures an SPF result of NEUTRAL, neither 
PASS nor FAIL.Similarly, DMARC evaluators SHOULD treat SPF NONE as 
equivalent to NEUTRAL when the RFC5322.From domain has an applicable DMARC 
policy record.”

Doug Foster

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

Re: [dmarc-ietf] Section 5 - DKIM-only authentication

[Ken O'Driscoll]

Organisations using DKIM-only (also SFP-only) with an enforcing DMARC policy 
are more common than you may think. While some configurations are perhaps in 
error, many I have encountered are deliberate decisions based on specific use 
cases.

For example, I have a finance house that uses DKIM-only auth with p=reject on 
their main domain. When deploying DMARC they risked it and decided that giving 
a third-party control of their SPF (via an include) was not an option. It’s a 
valid reason whether one personally agrees with it or not. There are tons of 
other reasons why organisations make similar decisions.

Single auth is actively used in the wild.

Ken.

From: dmarc  On Behalf Of Douglas Foster
Sent: Monday 27 December 2021 13:51
To: IETF DMARC WG 
Subject: [dmarc-ietf] Section 5 - DKIM-only authentication

These two sections assume that some domain owners will want DMARC 
authentication to be based on DKIM only.

5 Policy
A Domain Owner can also choose to not have some underlying authentication 
technologies apply to DMARC evaluation of its domain(s). In this case, the 
Domain Owner simply declines to advertise participation in those schemes. For 
example, if the results of path authorization checks ought not be considered as 
part of the overall DMARC result for a given Author Domain, then the Domain 
Owner does not publish an SPF policy record that can produce an SPF pass result.

5.7.2. Determine Handling Policy
Heuristics applied in the absence of use by a Domain Owner of either SPF or 
DKIM (e.g., [Best-Guess-SPF]) SHOULD NOT be used, as it may be the case that 
the Domain Owner wishes a Message Receiver not to consider the results of that 
underlying authentication protocol at all.

We agreed to drop the reference to Best-Guess-SPF, but we have not addressed 
the underlying requirement.  Do we actually have domain owners who do not want 
SPF included in the DMARC evaluation process?  If so, why?

I am guessing that this request could only originate from a domain owner with a 
valid but overly inclusive SPF record, probably because of include clauses.   
The suggested strategy of no SPF record, or the equivalent "?ALL", or not 
acceptable.   These approaches only make a weak SPF policy even weaker.To 
allow an overly-broad SPF policy to be ignored for DMARC purposes, we should 
provide an explicit policy flag for this purpose.

But each new option adds complexity.   Is this option actually valuable to 
somebody?
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Experiments

[Ken O'Driscoll]

Well, I have had a deliverability related encounter with ARC in the wild, and 
can report that ARC is actively being used by Zoho.

A client was using Zoho for their service desk and messages started going 
missing. The way these service desks work is that you forward say 
supp...@example.com to a unique Zoho supplied email address which goes to your 
service desk queue.

On investigation, it was determined that the only messages going missing were 
those originating from domains with an enforcing DMARC policy and 
non-aligned/non-existent/broken DKIM.

Correspondence with Zoho’s customer service revealed that they a) have 
implemented ARC, b) expect every mailbox provider to also have implemented ARC, 
and c) are making filtering decisions on that belief. They appear to be 
maintaining their own internal trust db. And yes, I know that this is ideally 
how we want ARC to work; Zoho are just eager and early to the party. They were 
not receptive to my opinion on the flaw with their strategy.

In my client’s case, their ISP has no plans to implement ARC, so Zoho 
grudgingly disabled the filtering for their account.

This incident made me wonder how much stealth ARC is out there, i.e. it’s not 
evident that it’s being used at all, or indeed for filtering decisions, until 
you poke the organisation.

Ken.

From: dmarc  On Behalf Of Murray S. Kucherawy
Sent: Wednesday 22 September 2021 21:30
To: IETF DMARC WG 
Subject: [dmarc-ietf] Experiments

Is anyone in a position to comment on the ARC and PSD experiments and how 
they're progressing?  Deployment status?  Data acquired thus far?

-MSK

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

Re: [dmarc-ietf] Ticket #11 (and #112) - Proposed language

[Ken O'Driscoll]

+1

Ken.


From: dmarc  on behalf of John Levine 
Sent: Wednesday, 16 June 2021, 19:02
To: dmarc@ietf.org
Cc: ves...@tana.it
Subject: Re: [dmarc-ietf] Ticket #11 (and #112) - Proposed language

It appears that Alessandro Vesely   said:
>It might make sense to reject that ~30% which doesn't even have an
>organizational domain (dubbed totally astray in my previous post).  But I still
>receive From:  on a mailing list.  Rejecting that
>risks getting unsubscribed.  Perhaps mailing lists deserve a special 
>permission...

Or perhaps mailing lists should refrain from forwarding messages from cowards 
who
use fake addresses and don't sign their mail.

Either way, I still don't see what this has to do with DMARC.  Let's close 
ticket #112 and stop.

R's,
John

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

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

Re: [dmarc-ietf] Sender-supplied decision matrix for passing DMARC

[Ken O'Driscoll]

I think this is a bad idea as it adds unnecessary additional complexity. 
Currently, a domain owner can choose to only implement DKIM or SPF on a mail 
stream if they only wish one mechanism to be evaluated.

Further, if there is a (renewed?) desire to apply a policy layer to DKIM signed 
messages, then isn't that what ADSP (RFC 5617) was intended for?

Ken.


From: dmarc  on behalf of Brotman, Alex 

Sent: Monday 14 June 2021, 18:10
To: dmarc@ietf.org
Subject: [dmarc-ietf] Sender-supplied decision matrix for passing DMARC

Hello,

I was talking to some folks about DMARC, and a question came as to suggest as 
the domain holder that your messages should always pass DKIM.  Effectively, the 
asker wants to say "I intend to deploy SPF and DKIM, but I will *always* sign 
my messages with DKIM."  So the obvious answer may be "Just only use DKIM", but 
I'm not sure that completely answers the question.  While discussing with 
someone else, "Tell me when DKIM fails, but SPF is fully aligned".  There was 
recently an incident at a provider where they were allowing any sender to send 
as any domain (and I'm aware that's not specifically a DMARC issue).  We all 
know brands that have just dumped in a pile of "include" statements without 
fully understanding the implications.  In this case, other users could send as 
other domains, but perhaps they would not have been DKIM signed.  Should there 
be a method by which a domain holder can say "We want all message to have both, 
or be treated as a failure", or "We'll provide both, but DKI
 M is a must"?

>From a receiver side, it makes evaluation more complex.  From a sender side, 
>it gives them more control over what is considered pass/fail.

How does this look in practice?  Maybe 
"v=DMARC1;p=quarantine;rua=...;pm=dkim:must,spf:should;"
(pm=Policy Matrix)

Does this make everyone cringe, or perhaps worth a larger discussion?

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

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

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

Re: [dmarc-ietf] Sender vs From Addresses

[Ken O'Driscoll]

Hi Charles,

DMARC is intended to prevent unauthorised use a domain name in the 5322.From 
header. This header was chosen because it is displayed in MUAs and is the 
target of spoofing attempts in phishing campaigns. I agree that there is some 
ambiguity in the original RFC but the intention is clear - DMARC exclusively 
works on 5322.From by design not oversight.

The interoperability issues between DMARC and mailing lists etc. are well 
understood and documented (for example, see 
https://www.rfc-editor.org/rfc/rfc7960.html) and the underlying protocols where 
the policy get applied, namely SPF and DKIM, already had interoperability 
issues with intermediaries even before DMARC came along.

There is actually an existing working group draft discussing extending DMARC to 
incorporate the 5322.Sender header, see 
https://datatracker.ietf.org/doc/draft-ietf-dmarc-sender/. That document goes 
into considerable detail on how 5322.Sender could be incorporated in the future.

Ken.

From: dmarc  On Behalf Of Charles Gregory
Sent: Wednesday 24 March 2021 09:49
To: dmarc@ietf.org
Subject: [dmarc-ietf] Sender vs From Addresses

I'm having trouble with DMARC prioritizing the From address over the Sender 
address.  Couldn't a future version at least allow this behavior to be modified 
with the DNS entry or something?

I found my issue well articulated in the thread copied below and completely 
agree with this gentleman.

Thoughts???

Taken from:  email - Why does DMARC operate on the From-address, and not the 
envelope sender (Return-Path)? - Server 
Fault


1.  Why was DMARC designed that way?
* because the people who designed it apparently didn't read section 
3.6.2 of RFC 5322, or 
misinterpreted it, or ignored it.

That section clearly establishes that a Sender: header, when present, takes 
priority over a From: header, for the purposes of identifying the party 
responsible for sending a message:

The "Sender:" field specifies the mailbox of the agent responsible for the 
actual transmission of the message. For example, if a secretary were to send a 
message for another person, the mailbox of the secretary would appear in the 
"Sender:" field and the mailbox of the actual author would appear in the 
"From:" field. If the originator of the message can be indicated by a single 
mailbox and the author and transmitter are identical, the "Sender:" field 
SHOULD NOT be used. Otherwise, both fields SHOULD appear.

Contrast this with the rationale given in RFC 
7489:

DMARC authenticates use of the RFC5322.From domain by requiring that it match 
(be aligned with) an Authenticated Identifier. The RFC5322.From domain was 
selected as the central identity of the DMARC mechanism because it is a 
required message header field and therefore guaranteed to be present in 
compliant messages, and most Mail User Agents (MUAs) represent the RFC5322.From 
field as the originator of the message and render some or all of this header 
field's content to end users.

I contend that this logic is flawed, as RFC 
5322 goes on to call out 
this error explicitly:

Note: The transmitter information is always present. The absence of the 
"Sender:" field is sometimes mistakenly taken to mean that the agent 
responsible for transmission of the message has not been specified. This 
absence merely means that the transmitter is identical to the author and is 
therefore not redundantly placed into the "Sender:" field.

I believe that DMARC is broken by design, because
* it conflates authority to send and proof of authorship;
* it misinterprets prior RFCs, and
* in doing so it breaks any previously compliant list-serv that 
identified itself by adding its own Sender: header.

If a Sender: field is present, DMARC should say to authenticate that field and 
ignore the From: field. But that's not what it says, and therefore I consider 
it to be broken.

RFC 7489 continues:

Thus, this field is the one used by end users to identify the source of the 
message and therefore is a prime target for abuse.

This is simply wrong (in the context of justifying ignoring the Sender: 
header). At the time that DMARC was designed, common email clients would 
routinely display a combination of the information from Sender: and From: 
fields, something like From name-for-mailing-list@server on behalf of 
user@original.domain. So it was always clear to 
the user who was responsible for sending the message they were looking at.



Suggestions that Reply-To: is an adequate replacement are also flawed because 
that header is wid

Re: [dmarc-ietf] Info - DMARC at WEB.DE, GMX, mail.com coming soon

[Ken O'Driscoll]

Arne,

You should post this over on mailop too - a lot of postmasters and senders who 
would find this useful don’t lurk here.

Also, are your GDPR compliant aggregate reports the same as the RFC 
specification, or are you going to modify them in some way?

Ken.

From: dmarc  On Behalf Of Arne Allisat
Sent: Tuesday 9 March 2021 16:38
To: dmarc@ietf.org
Subject: [dmarc-ietf] Info - DMARC at WEB.DE, GMX, mail.com coming soon

Just a short info to whom it might interest:

Very soon, we will go live with DMARC check on incoming mails for all mailboxes 
operated by WEB.DE, GMX & mail.com.
That covers several hundreds of recipient domains [1] and roughly 50% of the 
German email users.

For now we will handle reject and quarantine policies equally as quarantine.
GDPR compliant, aggregated DMARC reports will follow as well (without giving an 
ETA).

Best regards
Arne Allisat
Head of Mail Application Security
Produktmanagement Portal
1&1 Mail & Media GmbH | Brauerstraße 48 | 76135 Karlsruhe | Germany
E-Mail: arne.alli...@1und1.de | Web: 
www.1und1.de

[1] - A non official reference of domains can be found at 
https://www.spamresource.com/2020/03/reference-webde-gmx-and-mailcom-domains.html
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

[Ken O'Driscoll]

On Monday 22 February 2021 16:14, Dave Crocker wrote:
> Strictly speaking co.uk is not ICAN-authorized.  It's authorized by
> mechanisms internal to the UK.
> 

None of the ccTLDs registry operators would call or consider themselves 
"ICANN-authorized". The original authorisation to use the namespace is very 
separate to ICANN having any general authority over them. Further, it’s likely 
to be confused with the more common term "ICANN-accredited", which refers to a 
sub-set of domain registrars, not registries.

I think a better and more inclusive term would be "Internet Domain Registry".

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

Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

[Ken O'Driscoll]

I would go even further and not even talk about the trees and nodes. Also, 
echoing elsewhere in this thread, making it really clear that this is not a 
case of DMARC is coming for your TLD. So, I’d propose something super basic 
like this for the second paragraph:

Domain name suffixes (for example .com, .eu, and .co.uk) are controlled by 
registries, who either directly or through accredited registrars, facilitate 
the registration and management of domain names below these suffixes. DMARC 
currently permits expression of policy only for domain names and not for domain 
suffixes. Since its deployment in 2015, specialist use cases have been 
identified where it may be desirable for a suffix to express a DMARC policy. 
This document describes an experimental extension to DMARC to add that 
capability.

Ken.

From: dmarc  On Behalf Of Murray S. Kucherawy
Sent: Monday 22 February 2021 07:09
To: Barry Leiba 
Cc: Dave Crocker ; IETF DMARC WG 
Subject: Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

On Fri, Feb 19, 2021 at 3:02 PM Barry Leiba 
mailto:barryle...@computer.org>> wrote:
I agree that the abstract is unclear.  This makes no sense to me:

   domain names represent either nodes in the tree below
   which registrations occur, or nodes where registrations have
   occurred; it does not permit a domain name to have both of these
   properties simultaneously.

I don't understand the distinction that it's trying to make between
the two possibilities.
I also don't see the antecedent to "these domains" in the final
sentence of that paragraph.

Beyond that:
> I'm at a loss to understand what's confusing.  I'm not convinced that 
> "registrations" in the
> context of domain names is unclear to a reader familiar with this space.

I am absolutely convinced that it is.  Think of people in M3AAWG, for
whom this is very relevant.  Many of them don't know much about
registries, registrars, and such, and in general, the average reader
won't understand the difference, from a "registration" standpoint,
between facebook.com (which is registered) and 
"www.facebook.com"
(which is not).  To the average reader, "facebook.com" is 
registered
under com, and "www.facebook.com" is registered under 
facebook.  And
the ones who don't think that will likely not understand why we can't
just talk about second-level domains and be done with it.

Actually that's a community that I would expect to know exactly what all those 
terms mean and how they are all related.

I think the use of "registered" seems to be the source of some of this 
confusion.  To work with the example you gave here, I agree that 
"facebook.com" is registered (under "com"), but disagree 
that "www.facebook.com" is registered at all; 
"facebook.com" was delegated to some company that now 
"owns" that piece of the namespace tree and can create whatever it wants under 
there without any external arrangement.  To my mind, "register" involves a 
specific transaction, sometimes involving money, with whoever gates access to 
make those delegations.

All that needs to be explained in the Introduction, not the Abstract.
But the Abstract has to explain enough for a reader to understand why
she might or might not be interested in getting the document and
reading it.  So it's going to be tough to word it carefully and to
keep it concise.  But we have to.

Stressing a point:
We very clearly do NOT want to explain this stuff in the Abstract.  In
fact, we don't have to explain much at all in the Abstract.  What we
have to do is make sure that the Abstract doesn't say stuff that's
*wrong* or confusing.  So let's try to find some fifth-grade language
that can suffice, and then make sure the Introduction has the right
words to make it clear to people who know how to do email, but who
don't already understand the issues involved here.

How's this?:


   DMARC (Domain-based Message Authentication, Reporting, and

   Conformance) is a scalable mechanism by which a mail-originating

   organization can express domain-level policies and preferences for

   message validation, disposition, and reporting, that a mail-receiving

   organization can use to improve mail handling.

   Within the Domain Name System (DNS) on the public Internet, which is

   organized as a tree, some nodes of that tree are reserved for use by

   registrars, who delegate sub-trees to other operators on request.  DMARC 
currently
   permits expression of policy only for such sub-trees.  There is a marked 
desire to

   be able to express policy for the reserved nodes as well.  This document

   describes an experimental extension to DMARC to add that capability.


If we like that as a replacement Abstract, I'll carry on and propose a revision 
to the Introduction.

-MSK
___
dmarc mailing list
dmarc

Re: [dmarc-ietf] Ticket #64 - Contained Data PII Concerns

[Ken O'Driscoll]

The concern is that PII is contained in the aggregate reports.

The machinations of the individual Information Governance functions that draw 
such conclusions or the decision making processes of individual organisations 
around those conclusions, is not relevant, and won’t help close this ticket.

Ken.

From: dmarc  On Behalf Of Douglas Foster
Sent: Thursday 18 February 2021 02:21
To: IETF DMARC WG 
Subject: Re: [dmarc-ietf] Ticket #64 - Contained Data PII Concerns

It would help me if you could elaborate on the concerns that you have 
encountered.

Which data is sensitive and therefore needing classification?

Which roles creates the objection?   Server owner sending reports, recipient 
domain allowing the server owner to send reports from recipient data, or only 
report recipient?

When the report recipient domain delegates reception to an authorized agent, 
how does the organization making the delegation escape liability for how the 
information is handled and used?


On Wed, Feb 17, 2021 at 4:27 PM Ken O'Driscoll 
mailto:40wemonitoremail@dmarc.ietf.org>>
 wrote:

I PM deployments for organisations and the concept of aggregate reports have 
caused problem more than once. Similar to the PII concerns of providers which 
originated this ticket, these organisations operate in heavily a regulated 
industry and have extensive DPO functions. To give a flavour of what those 
concerns translate to - I have been asked is it possible to implement DMARC 
without using reports! I have also had con-calls about training a new hire to 
read and classify the reports! That's just two examples. It's mostly driven by 
overzealous DPOs but I understand their concerns on some level. When they 
realise that we can distil the report data and it doesn't need to be on-site, 
they hand wave away any custodian concerns and the project moves forward.

So, assuming that my DMARC clients aren't unique, I'm wondering if this section 
could be split into two parts, one for Mail Receivers and one for Domain Owners?

If so, for Domain Owners, I'd propose something like this:

Aggregate feedback reports are essential for the proper implementation and 
operation of DMARC. Domain Owners can choose to exclusively direct reports to a 
processor external to their organization. In such cases, the content of the 
reports are never sent directly to the Domain Owner.

Thoughts?

Ken.

> -Original Message-
> From: dmarc mailto:dmarc-boun...@ietf.org>> On Behalf 
> Of Brotman, Alex
> Sent: Wednesday 17 February 2021 18:40
> To: Alessandro Vesely mailto:ves...@tana.it>>; 
> dmarc@ietf.org<mailto:dmarc@ietf.org>
> Subject: Re: [dmarc-ietf] Ticket #64 - Contained Data PII Concerns
>
> Incorporating some feedback:
>
> ---
> ## Data Contained Within Reports (Tkt64)
>
> Within the reports is contained an aggregated body of anonymized data
> pertaining to the sending domain.  The data is meant to aid the report
> processors and domain holders in verifying sources of messages
> pertaining to the DMARC Identifier.  The data should not contain any
> identifying characteristics about individual senders or receivers.  An
> entity sending reports should not be concerned with the data contained
> as it does not contain personal information, such as email addresses or
> usernames. There are typically three situations where data is reported
> to the aggregate receivers: messages properly authenticated, messages
> that fail to authenticate as the domain, or messages utilizing the DMARC
> Identifier that have no authentication at all.  In each of these cases,
> there exists no identifying information for individuals, and all content
> within the reports should be related to SMTP servers sending messages
> posing as that domain.
> ---
>
>
> --
> Alex Brotman
> Sr. Engineer, Anti-Abuse & Messaging Policy Comcast
>
> > -Original Message-
> > From: dmarc mailto:dmarc-boun...@ietf.org>> On 
> > Behalf Of Alessandro Vesely
> > Sent: Monday, February 15, 2021 8:31 AM
> > To: dmarc@ietf.org<mailto:dmarc@ietf.org>
> > Subject: Re: [dmarc-ietf] Ticket #64 - Contained Data PII Concerns
> >
> > On Fri 12/Feb/2021 21:30:38 +0100 Brotman, Alex wrote:
> > > Hello folks,
> > >
> > > In ticket #64
> >
> (https://urldefense.com/v3/__https://trac.ietf.org/trac/dmarc/ticket/64_<https://urldefense.com/v3/__https:/trac.ietf.org/trac/dmarc/ticket/64_>
> _;!
> > !CQl3mcHX2A!W97hZ0-
> > iwRDi8wBssmRFF6OycVE12vM3xhGd9BmLhEzi6Vycp3bgzwji21xLQQgnnMRa
> > BuxGQg$ ), it was suggested that a Privacy Considerations section may
> > alleviate some concerns about the ownership of the data.  I created an
> > initial attempt, and thought to get some f

Re: [dmarc-ietf] Ticket #64 - Contained Data PII Concerns

[Ken O'Driscoll]

In hindsight, it looks a bit strange to have the first paragraph say "don't 
worry about PII" and the next paragraph say "if you're worried about PII, 
here's how to mitigate".

But it's a genuine concern (misguided or not) and I've been in enough meetings 
to at least understand where it comes from, even if I don't agree. So I'd 
propose something like the below, which I think gets across what we all want to 
say.

===
Aggregate feedback reports contain anonymized data relating to messages 
purportedly originating from the Domain Owner. The data does not contain any 
identifying characteristics about individual senders or receivers. No personal 
information such as individual email addresses, IP addresses of individuals, or 
the content of any messages, is included in reports.

Mail Receivers should have no concerns in sending reports as they do not 
contain personal information. In all cases, the data within the reports relates 
to the authentication information provided by mail servers sending messages on 
behalf of the Domain Owner. This information is necessary to assist Domain 
Owners in implementing and maintaining DMARC.

Domain Owners should have no concerns in receiving reports as they do not 
contain personal information. The reports only contain aggregated anonymized 
data related to the authentication details of messages claiming to originate 
from their domain. This information is essential for the proper implementation 
and operation of DMARC. Domain Owners who are unable to receive reports for 
organizational reasons, can choose to exclusively direct the reports to an 
external processor.
===

And, I agree - it's a bit weird to be okay with having a policy to not see your 
own reports. But the "see no evil, hear no evil" risk mitigation strategy is 
tried and tested. The whole IG/DPO space is really crazy in some places too.

Ken.

> -Original Message-
> From: John Levine 
> Sent: Thursday 18 February 2021 02:46
> To: dmarc@ietf.org
> Cc: Ken O'Driscoll 
> Subject: Re: [dmarc-ietf] Ticket #64 - Contained Data PII Concerns
> 
> In article
>  angelabs.com> you write:
> >Aggregate feedback reports are essential for the proper implementation
> >and operation of DMARC. Domain Owners can choose to exclusively direct
> >reports to a processor external to their organization. In such cases,
> the content of the reports are never sent directly to the Domain Owner.
> 
> That is OK but I would also want to point out that the data are
> aggregated and contain no individual e-mail addresses of senders or
> recipients, nor IP addresses of individuals nor any contents of
> messages, so it is unlikely that they contain any PII.
> 
> I have to say it seems weird to me that it's OK to send whatever to
> external places but not to your own staff.
> 
> R's,
> John
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #64 - Contained Data PII Concerns

[Ken O'Driscoll]

I PM deployments for organisations and the concept of aggregate reports have 
caused problem more than once. Similar to the PII concerns of providers which 
originated this ticket, these organisations operate in heavily a regulated 
industry and have extensive DPO functions. To give a flavour of what those 
concerns translate to - I have been asked is it possible to implement DMARC 
without using reports! I have also had con-calls about training a new hire to 
read and classify the reports! That's just two examples. It's mostly driven by 
overzealous DPOs but I understand their concerns on some level. When they 
realise that we can distil the report data and it doesn't need to be on-site, 
they hand wave away any custodian concerns and the project moves forward.

So, assuming that my DMARC clients aren't unique, I'm wondering if this section 
could be split into two parts, one for Mail Receivers and one for Domain Owners?

If so, for Domain Owners, I'd propose something like this:

Aggregate feedback reports are essential for the proper implementation and 
operation of DMARC. Domain Owners can choose to exclusively direct reports to a 
processor external to their organization. In such cases, the content of the 
reports are never sent directly to the Domain Owner.

Thoughts?

Ken.

> -Original Message-
> From: dmarc  On Behalf Of Brotman, Alex
> Sent: Wednesday 17 February 2021 18:40
> To: Alessandro Vesely ; dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Ticket #64 - Contained Data PII Concerns
> 
> Incorporating some feedback:
> 
> ---
> ## Data Contained Within Reports (Tkt64)
> 
> Within the reports is contained an aggregated body of anonymized data
> pertaining to the sending domain.  The data is meant to aid the report
> processors and domain holders in verifying sources of messages
> pertaining to the DMARC Identifier.  The data should not contain any
> identifying characteristics about individual senders or receivers.  An
> entity sending reports should not be concerned with the data contained
> as it does not contain personal information, such as email addresses or
> usernames. There are typically three situations where data is reported
> to the aggregate receivers: messages properly authenticated, messages
> that fail to authenticate as the domain, or messages utilizing the DMARC
> Identifier that have no authentication at all.  In each of these cases,
> there exists no identifying information for individuals, and all content
> within the reports should be related to SMTP servers sending messages
> posing as that domain.
> ---
> 
> 
> --
> Alex Brotman
> Sr. Engineer, Anti-Abuse & Messaging Policy Comcast
> 
> > -Original Message-
> > From: dmarc  On Behalf Of Alessandro Vesely
> > Sent: Monday, February 15, 2021 8:31 AM
> > To: dmarc@ietf.org
> > Subject: Re: [dmarc-ietf] Ticket #64 - Contained Data PII Concerns
> >
> > On Fri 12/Feb/2021 21:30:38 +0100 Brotman, Alex wrote:
> > > Hello folks,
> > >
> > > In ticket #64
> >
> (https://urldefense.com/v3/__https://trac.ietf.org/trac/dmarc/ticket/64_
> _;!
> > !CQl3mcHX2A!W97hZ0-
> > iwRDi8wBssmRFF6OycVE12vM3xhGd9BmLhEzi6Vycp3bgzwji21xLQQgnnMRa
> > BuxGQg$ ), it was suggested that a Privacy Considerations section may
> > alleviate some concerns about the ownership of the data.  I created an
> > initial attempt, and thought to get some feedback.  I didn't think we
> > should go too far in depth, or raise corner cases.  Felt like doing so
> > could lead down a rabbit hole of trying to cover all cases. This would
> > go within a "Privacy Considerations" section.
> > >
> > > * Data Contained Within Reports (#64)
> > >
> > > Within the reports is contained an aggregated body of anonymized
> > > data pertaining to the sending domain.  The data is meant to aid the
> > > report processors and domain holders in verifying sources of
> > > messages pertaining to the 5322.From Domain.
> >
> >
> > I'd replace all those 5322.From Domain with main DMARC identifier.
> >
> >
> > > The data should not contain any identifying characteristics about
> > > individual senders or receivers.
> >
> >
> > The aggregated data refers to names and IP addresses of SMTP servers.
> > It cannot be used to identify individual users.
> >
> >
> > >  An entity
> > > sending reports should not be concerned with the data contained as
> > > it should not contain PII (NIST reference for PII definition), such
> > > as email
> > addresses or
> > > usernames.
> >
> >
> > I'd substitute /should not/does not/.  Even if a server has a unique
> > user, the domain name and the IP address are those of a public entity,
> > not those of a private citizen.
> >
> > The term Personally Identifiable Information (PII) is US-national.  I
> > think just personal information is of broader use.  Personal data is
> > also a valid alternative.
> >
> >
> > jm2c
> > Ale
> > --
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >

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

[Ken O'Driscoll]

> -Original Message-
> From: dmarc  On Behalf Of John R Levine
> Sent: Friday 4 December 2020 18:22
> To: Alessandro Vesely ; John R Levine ;
> dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI
> functionality
> 
> >> I meant "at the same time" as in during the same reporting run.  As
> >> Dave noted, if you sent any particular report by https, there's no
> >> need to send it again by mail.
> >
> > Got it.  However, the spec says it's a list of addresses to which
> > aggregate feedback is to be sent.  When there are multiple entries, up
> > to now, reports are sent to each.
> 
> Hm, we might want to revisit that.  If a domain wants mail sent to three
> places, it's not like it's hard to arrange for forwarding.  My intention
> is that if you send the report by https, you're done.

In many circumstances, mail forwarding may be quite difficult to arrange.

Many organisations use an external service to handle their reports. Currently, 
if such an organisation wishes to add another report receiver, they are in 
control of that process by modifying their DNS zone.

However, if they can only specify one report receiver then it is that report 
receiver who must handle any forwarding in the case of multiple parties.

The pre and post acceptance filtering that most mailbox providers implement can 
make them unreliable for delivering DMARC reports to user mailboxes. So, an 
organisation would likely have to set up a separate mail infrastructure should 
they wish to retain control of what parties receive their DMARC reports.

Of course, third party report processing services could also add support for 
such forwarding. But, given that such a feature could facilitate a competitor, 
I'm sceptical it would make business sense to many of them. On top of that, 
it's easier to receive than send so there is an ongoing cost in providing email 
forwarding.

As to the utility of having more than one report destination, I regularly 
receive client DMARC reports on top of their existing service as part of 
consultancy engagements. It is also the only way for an organisation without 
their own email infrastructure to simultaneously evaluate more than one report 
processing service. So I believe there is utility there.

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

Re: [dmarc-ietf] RESENT fields?

[Ken O'Driscoll]

The "resent" fields are currently used for their stated purpose, which as you 
correctly note, is to signal that a message has been re-introduced into the 
mail transport. These fields are typically used when a message which has 
already been delivered to a mailbox is resent unmodified (and possibly after a 
delay) to another email address.

A mailing list does not resend messages, it modifies and re-posts them to a 
subscriber list. The 5322.From and/or 5322.Sender fields are therefore more 
appropriate for mailing lists because they indicate the originator of the now 
re-posted/modified original message.

Ken.

From: dmarc  On Behalf Of Douglas E. Foster
Sent: Wednesday 7 October 2020 03:47
To: dmarc@ietf.org
Subject: [dmarc-ietf] RESENT fields?

Are the RESENT fields from RFC 5322 an interesting idea that everybody has 
ignored?For purposes of this discussion, they interest me because they 
provide a way of documenting changes to the SMTP sender, the From Header, and 
the recipient list.  RFC 5322 Section 3.6.6 says they SHOULD by added whenever 
a message is re-introduced to the transport system.   Mailing list activity 
seems to fit the language and intent of this section.   But I do not see any 
RESENT fields on the most recent posts to this list.   In fact, I am not sure 
that I have ever seen a message anywhere with these fields.

Application:
For forwarded messages, I don't want to trust the forwarder's spam filter, so I 
want to reconstruct the message identity as it appeared when the message 
entered the forwarder's ADMD.   The Resent fields would allow that logic to be 
developed, but I would also need forwarders to use those fields.   The usage 
would also need to apply to auto-forwarders, even though they are explicitly 
exempted from the RESENT header recommendation in the current RFC.

Doug Foster


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

Re: [dmarc-ietf] DMARC and Gateways?

[Ken O'Driscoll]

If you are referring to section 3.2.4. then I'm pretty sure that's referring to 
gateways in the protocol sense (see RFC 5598, section 5.4.) which convert 
internet mail into a different messaging protocol, such as SMS/MMS or 
(historically) UUCP. The interoperability concerns are still valid though there 
is much less of this in wild than there was 10 years ago and (for sending) you 
can normally put a compliant MTA in front of them.

Ken.

From: dmarc  On Behalf Of Douglas E. Foster
Sent: Tuesday 15 September 2020 11:59
To: dmarc@ietf.org
Subject: [dmarc-ietf] DMARC and Gateways?

I was surprised to see email technology gateways included in RFC 7960.

I would expect that a public gateway would use a from address within the 
gateway domain name, so that it can accept replies.   A gateway dedicated to a 
single organization would release messages into that organization on a trusted 
path, and anything forwarded out of that organization would be signed at the 
outbound mail gateway.

Can anyone who was involved with RFC 7960 comment on whether the gateway 
problem still exists?

DF

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

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

[Ken O'Driscoll]

On 03/08/2020 01:43, Douglas E. Foster wrote:
>
> I am not sure what "Internet Scale" means to you.   Most of the major
> recipients have bulk mailer registration systems.   It does not
> guarantee whitelisting, but it tends to produce that effect.   I have
> had occasion to register with most of them.   So "does not scale" is
> not obvious to me.

This is not correct. In the past some large providers did offer such
lists but these days most have moved away from that model for various
reasons. You'll still find someone offering such as service, and
pay-to-play is a thing too but none of this is a) widespread and b)
based on any type of standard - it's all proprietary. The same goes for
sender certification services such as ReturnPath.

"Internet Scale" means being able to scale to internet level of usage
and platform interoperability.  TCP/IP and DNS are good examples. Data
(e.g. lists of approved senders) maintained internally by individual
organisations can't scale to that level for the same reason that
organisations siloing their own DNS and routing information wouldn't
work. Interoperability.

Organisations publishing information (e.g. an SPF record) in their DNS
zone works because it's based on an existing internet scale
interoperable platform. While the "heavy lifting" of interpreting the
SPF record might be undertaken by a variety of different software and
system platforms, the mechanism is standardised based on the RFC. Again,
interoperability.

Ken.

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

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

[Ken O'Driscoll]

On 30/07/2020 11:39, Jeremy Harris wrote:
> That works at a domain-controlled level.  But people sign up for,
> and write to, mailinglists on an individual level.  Mismatch.

To be fair, this thread is specifically about a non-MLM use case at an
organisational level. But, I believe that any improvements to how DMARC
might handle use cases like mailing lists will likely have to be at the
domain-controlled level for there to be any chance of widespread adoption.

>From experience, the type of organisations that are deploying DMARC (in
p=reject) are not interested in allowing individual senders to delegate
which third-parties can send on their behalf. Banks etc. don't care
about mailing lists, most have HR policies that prevent employees from
interacting on external discussion groups so it's not on the radar.
However,  the use case presented 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.

Ken.

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

Re: [dmarc-ietf] Abolishing DMARC policy quarantine

[Ken O'Driscoll]

On Tue, 2019-06-11 at 21:00 +, Дилян Палаузов wrote:
> Dear all,
> 
> when DMARC passes, there is no difference between p=reject and
> p=quarantine.
[...snip...]
> However, it is ultimately up to the receiving site to decide, whether it
> wants to accept this extra work.  If it does not accept the extra work,
> it just handles quarantine as reject.  This does not violate the DMARC
> specitification.

Even in a moderately complex spam filtering engine, DMARC is just one
indicator / signal amongst many.

Who does the "extra work" is subjective. For example, a large mailbox
provider may consider support queries about missing or rejected emails as
unwanted "extra work" etc.

DMARC does not live in isolation - it's part to a greater ecosystem. 

> Do you have a story, why one wants to publish p=quaratnine?  What is the
> use case for it?  It just makes emails less reliable, as they end as Junk
> and this is very similar to discarding the emails.

There is a world of difference between requesting that a recipient flag an
incoming message as spam as opposed to asking them to discard it outright.
And that is regardless of how individual mailbox provides treat
p=quarantine.

A use case for p=quarantine is that when deploying DMARC for any reasonably
complex site, it forms part of a graduated approach (perhaps in conjunction
with pct=x) utilising aggregated reports to moving towards p=reject. 

The proactive nature of DMARC means that its deployment needs to be
properly planned with any risks mitigated as best as possible. The various
stages of p= can easily be articulated on a project plan / risk register.

And such sites that require such planning are often starting from a
position of improperly documented mail flows and inconsistently implemented
SPF/DKIM. In addition they often operate in regulated sectors and are
commonly top-heavy with risk-adverse middle management.

I accept that a small site with a simple mail flow which does not operate
in a regulated space and has thin governance could likely move straight
from p=none to p=reject without serious repercussions. Such sites are not
the majority of DMARC deployments.

DMARC changes how recipient mailbox providers treat email and therefore it
needs to be deployed in a controlled manner, p=quarantine being one
component of that. 

> Imagine a mailing lists, where the recipient of an email address expands
> to several mailboxes on different domains.  An incoming email fails DMARC
> validation before being distributed over the ML.  The domain owner for
> that mail origin has published p=quarantine, this email cannot be
> delivered in the Junk folder of the recipient, because the mailing list
> itself does not have a junk folder.

DMARC was never originally intended / scoped to work with domains which
interacted with mailing lists. The 5322.from address rewriting kludge 
allows such interaction by removing future DMARC tests.

A mailing list operator can also choose to reject emails from domains which
have a DMARC record.

DMARC has no use case to offer when working with mailing lists.

> How about, deleting policy Quarantine and instead rephrasing policy
> Reject:
> 
> It is up to the receiving server if it rejects messages failing DMARC, or
> accepts and delivers them as Junk.
> 
> (This does not change the protocol, just the wording)

I think this is completely unwarranted for (at a minimum) the above
mentioned reasons.

Ken.

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

Re: [dmarc-ietf] Rethinking DMARC for PSDs

[Ken O'Driscoll]

On Mon, 2019-04-08 at 09:50 -0400, Douglas E. Foster wrote:
[...snip...]
> My focus is on defining a framework for discussing product capabilities,
> while leaving room for vendors to add value above the minimum
> configuration.

That sounds more like what organisations such as Gartner are there for as
opposed to the IEFT. And they do a fairly good job in framing vendor
selection processes.

> Demonstrating email legitimacy is essentially a protocol between sender
> and receiver.   IETF has only defined one half of the protocol, so why
> should we be surprised that the conversation is broken.   Expertise can
> be assembled; the task is desperately needed.

That's not exactly true. The protocols do explain how a receiver should
implement them from a technical perspective. That ensures that there is no
divergence between how say a SPF record is interpreted on a product by
product basis. What they don't do, and what you appear to be alluding to,
is proscribe how receivers should filter spam, and more specifically forged
sender addresses from non-existent domains.

The IETF don't make such proscriptions because a) it's off-mission and b)
there is no one size fits all spam filter configuration.

What works for a small office would be unsuitable for a large corporation,
what works for a large corporation would be unsuitable for a hospital with
a similar number of users and in turn, dealing with millions of users
requires a completely different approach all together.

> In the interim, I am open to recommendations for good spam filters.   I
> have been trying to avoid disparaging the bad ones by name in a public
> forum.

This list isn't the appropriate place for that discussion as it does not
pertain to DMARC, despite the fact DMARC might be baked into some spam
filtering solutions.

Your starting point should be proper functional requirements specific to
your organisation.

Ken.

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

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-16.txt

[Ken O'Driscoll]

Apologies if this has already been caught by others.

Just spotted some small typos in section 8. Was reading this specific
section in connection with something GDPR (the fun!) related.

8.  Privacy Considerations

   The Authenticated Received Chain provides a verifiable record of the
   handlers for a message.  This record may include Personally
   Identifiable Information such as IP address and domain names.  Such
   information is also including in existing header fields such as the
   "Received" header field.


a) Suggest "IP addresses" to match plural for "domain names" or make it "an
IP address".

b) Replace "including" with "included" because it's grammatically
incorrect. 

c) Suggest "exiting non-ARC related header fields" to distinguish that
these are absolutely nothing to do with the protocol. It may be obvious to
us but  not to those who may discount implementation because they think it
adds new risk.

Ken.

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

Re: [dmarc-ietf] Valimail and DMARC

[Ken O'Driscoll]

MailMan has supported DMARC domains for ages through a simple address re-
writing mechanism. It works quite well. The version running this list
(2.1.22) definitely supports it, it just needs to be enabled.  

Unless there is a good reason which prevents it, turning it on is probably
a better long-term solution. ARC isn't going to be universally deployed
overnight and some personal domains (mine included) are no doubt DMARC
protect too.

Not to mention, the irony of the official DMARC mailing list discouraging
postings from DMARC protected domains due to compatibility issues!

Just my two cents, apologies if this was previously discussed by the list.

Ken.


-- 
Ken O'Driscoll / We Monitor Email 
t: +353 1 254 9400 | w: www.wemonitoremail.com

On Fri, 2017-06-02 at 11:08 -0400, Barry Leiba wrote:
> The valimail.com domain appears to have recently (it looks like it
> started 1 June) set a restrictive DMARC policy, and that's caused a
> boatload of disabled subscriptions.  Basically, whenever Seth (or any
> other valimail.com user, but recently that's been Seth) sends a
> message to the list now, anyone whose domain honours that policy has
> their copy of the message bounced back and not delivered.  After a few
> of those, mailman disables their subscriptions.
> 
> Seth, please (1) do not post messages to the list from your
> valimail.com address until this is resolved, and (2) do what you can
> to get this resolved.
> 
> Thanks,
> Barry, chairing
> 
> ___
> 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