date:20201123

In article  you write:
>What I'm struggling to understand is what having authenticated auth-res 
>from a previous hop helps. this is what i found:

See some of the previous messages. My usual example is a mailing list
message that fails DMARC at the final recipient but passed DMARC (as
recorded in AAR) when it arrived at the list. This lets the final
recipient distinguish between real messages from subscribers and mail
from spambots that happened to scrape both the list address and some
subscribers' address and sends mail to one pretending to be from the
other. (That definitely happens, I've seen it on lists I'm on.)

I agree that the ARC document does not do a great job of explaining that.

>It would be kind of nice to understand what gap ARC actually plugs and 
>why it's important if you ask me. Also: there seem to be a lot of ways 
>to achieve this, but this one is probably the most complicated one that 
>I can envision.

If you want to pass the A-R results through multiple rounds of
forwarding, you can't do much less.

R's,
John

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

Re: [dmarc-ietf] ARC questions


On 11/23/2020 4:13 PM, Brandon Long wrote:



On Mon, Nov 23, 2020 at 12:48 PM Dave Crocker > wrote:


On 11/23/2020 12:15 PM, Brandon Long wrote:

On Mon, Nov 23, 2020 at 11:53 AM Dave Crocker mailto:dcroc...@gmail.com>> wrote:
DKIM often ties a domain to reputation and other anti-spam
features.  If you
forward spam to another host and sign it while forwarding, then
the other host
will think you send spam.


Well, ummm... e... yes.  That's because, in such
circumstances, you do.

More significantly, the signature makes sure that such as an
assessment will only be made accurately, rather than penalizing
you for problematic mail that is attributed to you but that you
did not handle.

If the result is marking all of the mail from that mailing list as 
spam, then you've likely done your users a disservice.


Why would you put forward a hypothetical that might reasonably be 
characterized as unreasonable, especially given that you also make clear 
why it is unreasonable? (*)



Being able to differentiate is useful.  Also, forwarders often don't 
have all of
the signals that the user's mailbox does.. not the least of which is 
that different recipients have different judgements on what is spam, 
and the "this is spam" signal rarely makes it back to the forwarder.


Except that mailing lists are also recipients, notably including likely 
history from authors, and possibly more history than a final recipient?


There are, of course, possible signals a final recipient might have 
about an author, that the mailing list won't have. Equally there might 
be others the list has that the final recipient doesn't, such as knowing 
about other mail from the author, to other lists the mailing list system 
operates...




DMARC ties DKIM to the From header and at least is interpreted as
being an
anti-phishing feature.  DKIM signing mail that you forward could
mean upgrading
a phishing message to passing DMARC.


I don't understand.  The first sentence makes sense to me, but the
second doesn't.

"Upgrading...to passing DMARC only applies if a) the signature
matches the From: field domain, and b) that domain has an
associated DMARC record.  But if you don't watch DMARC to apply in
that case, what is the DMARC record there fore?

I send a phishing message to a mailing list or alias at a domain with 
a From header of that domain, and the list blindly
re-signs all mail sent to the list, I've now "authenticated" the 
spoofed message, and it will now "pass" DMARC.


There are so many different ways this represents really poor mailing 
list setup, operation and possibly design, I again wonder at your 
offering it as an example of any point relevant to this exchange.


It's not that what you suggest hasn't happened, it's that the fact that 
it represents multiple problems also suggests it can -- and probably 
should -- have multiple solutions.




Perhaps it
upgraded from a quarantine to none, since the mailing list doesn't 
have the concept of a spam folder, or perhaps the sales@ team
has decided they want all of the forwarded messages, even if probably 
spam, so that they can go through them to make sure...
but it lost the quarantine disposition on the forward when it gained 
authentication.


More problematic hypotheticals, all of which arguably represent poor 
services, just as originators can be poorly run services.




Perhaps this all means that DKIM has been used for more than it
was intended for.


"More than" suggests that the use has legitimacy.  It doesn't.

We don't always have control over how our work is used.


No, but we do have control over a) how we write about it, b) how we talk 
about it, and c) what we do about misuses of the work.


You appear to be taking the view that however others choose to interpret 
a specification is what the specification is for and how it operates.  
Except that that is only one -- and I'd argue highly problematic -- 
approach to misuses of a specification.




If I proposed extending a standard in a new direction that would
be perfectly fine with the original intent of the standard, and that 
clashed with how the standard had come to be used in

practice, my extension is DOA.


Possibly.  But not automatically.

For reference, note that 90+% of email is spam.  Does that mean that a 
proposal to counter that (inappropriate) use of email is DOA?  That 
seems to be the logic you've applied.




Forgive me but I think that:


Authenticated Received Chain (ARC) creates a mechanism for individual
Internet Mail Handlers to add their authentication assessment to a
message's ordered set of handling results.


specifies a nature and responsibility pretty much identical to
what DKIM claims.  The enhancements are a) chaining, and b)
carriage of earlier assessments.  But in terms of
'responsibility', this reads the

Re: [dmarc-ietf] ARC questions



On 11/23/20 3:00 PM, Dave Crocker wrote:

On 11/23/2020 2:58 PM, John R Levine wrote:
And, again, when ARC work was pursued, I don't recall anyone 
claiming that mailing lists were (significant) sources of misbehavior.
Well, OK.  Please feel free to provide footnoted documentation of 
what the actual motivation for ARC was if you believe it was 
something else.



Typically, the burden of substantiating a claim falls on the person 
making the affirmative claim.


What I'm struggling to understand is what having authenticated auth-res 
from a previous hop helps. this is what i found:


"With this information, Internet Mail Handlers MAY inform local policy 
decisions regarding disposition of messages that experience 
authentication failure due to intermediate processing."


that and:

"When an Authenticated Received Chain is used to determine message 
disposition, the DMARC processor can communicate this local policy 
decision to Domain Owners as described in Section 7.2.2."


seems to be the only motivation I can find. without ARC, a receiver 
could always check the new DKIM signature from, say, the mailing list 
and look up its reputation to decide whether to pass it along or not 
overriding the originating domain's policy. my recollection was that 
this was the "you break it, you own it" policy which i recall being the 
consensus. and indeed, there is nothing to stop a filter to look at the 
mailing list's auth-res and take it into account even if it's not part 
of the headers in the signature. maybe there is some attack there i'm 
not seeing off the top of my head, but it seems like this really hinges 
on reputation as was pointed out to me earlier.


It would be kind of nice to understand what gap ARC actually plugs and 
why it's important if you ask me. Also: there seem to be a lot of ways 
to achieve this, but this one is probably the most complicated one that 
I can envision.


Mike

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

Re: [dmarc-ietf] ARC questions


On 11/23/2020 2:58 PM, John R Levine wrote:
And, again, when ARC work was pursued, I don't recall anyone claiming 
that mailing lists were (significant) sources of misbehavior.
Well, OK.  Please feel free to provide footnoted documentation of what 
the actual motivation for ARC was if you believe it was something else.



Typically, the burden of substantiating a claim falls on the person 
making the affirmative claim.



d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

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

Re: [dmarc-ietf] ARC questions

I believe that Brandon has specifically said that Gmail sees this problem 
and that is why whitelisting mail from mailing lists isn't adequate. 


And that constitute "meaningfully document[ing]"?


Works for me.  I doubt I was the only person wondering why it needed all 
that mechanism when whitelisting mailing lists got you most of the way 
there, particularly since you need that whitelist anyway to know when to 
start ARC analysis.


And, again, when ARC work was pursued, I don't recall anyone claiming that 
mailing lists were (significant) sources of misbehavior.


Well, OK.  Please feel free to provide footnoted documentation of what 
the actual motivation for ARC was if you believe it was something else.


R's,
John

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

Re: [dmarc-ietf] ARC questions


On 11/23/2020 2:42 PM, John R Levine wrote:
Forgive me but I believe misbehavior by mailing lists has never been 
meaningfully documented for this work.  Quite the contrary.


I believe that Brandon has specifically said that Gmail sees this 
problem and that is why whitelisting mail from mailing lists isn't 
adequate. 


And that constitute "meaningfully document[ing]"?

My point wasn't that it isn't a valid concern, but that it was not 
explicitly stated as the motivation. Again:



ARC deals with the problem that most list software forwards everything
with a subscriber's address on the From: line and does a lousy job of
spam filtering. 

offers a characterization of mailing lists that hasn't been documented.

And, again, when ARC work was pursued, I don't recall anyone claiming 
that mailing lists were (significant) sources of misbehavior.


d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

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

Re: [dmarc-ietf] ARC questions


You know that a message came from a mailing list because you have your
list of IPs or DKIM signatures of lists you trust.


Except that was not stated or, really, even implied in the text of the 
message I was replying to.  Rather, something like that seemed to be taken as 
an assumption, but without any clear foundation.


Well, OK, but it's still true.


ARC deals with the problem that most list software forwards everything
with a subscriber's address on the From: line and does a lousy job of
spam filtering.


Forgive me but I believe misbehavior by mailing lists has never been 
meaningfully documented for this work.  Quite the contrary.


I believe that Brandon has specifically said that Gmail sees this problem 
and that is why whitelisting mail from mailing lists isn't adequate.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions


On 11/23/2020 1:27 PM, John Levine wrote:

In article ,
Dave Crocker   wrote:

I believe, though, that the intent of ARC is that it be scalable in
ways that manual enumeration of known legit mailing lists and
forwarders is not.

"if you know which hosts are legit" buries an assumption that is
problematic, namely that you know who handled the message.  The fact
that a message purports to be handled by a mailing list you trust does
not mean it actually was.

Pretty close, but not quite.

You know that a message came from a mailing list because you have your
list of IPs or DKIM signatures of lists you trust.


Except that was not stated or, really, even implied in the text of the 
message I was replying to.  Rather, something like that seemed to be 
taken as an assumption, but without any clear foundation.


For these kinds of discussions, which are mostly about understanding 
these capabilities clearly, accurately, and precisely, the core 
requirement is to separate the essential bits of information and the 
basis for knowing each bit.




ARC deals with the problem that most list software forwards everything
with a subscriber's address on the From: line and does a lousy job of
spam filtering.


Forgive me but I believe misbehavior by mailing lists has never been 
meaningfully documented for this work.  Quite the contrary.


List mail has been collateral damage, not because lists have misbehaved 
but because they got caught by a spontaneous change in the email service 
by some providers.



d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

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

Re: [dmarc-ietf] ARC questions



On 11/23/20 12:48 PM, Dave Crocker wrote:

This recent article also goes into things that DKIM signatures imply:
https://blog.cryptographyengineering.com/2020/11/16/ok-google-please-publish-your-dkim-secret-keys/ 



The level of condescension, ignorance, and error throughout that 
article is impressive.  Given that it was written by someone whose 
profession requires extreme care about complex matters, the level of 
carelessness in the article is especially unfortunate.


Conveniently, he put his biggest error in bold font:

 "*DKIM provides a life-long guarantee of email authenticity that 
anyone can use to cryptographically verify the authenticity of stolen 
emails, even years after they were sent."*


DKIM does no such thing.



Yeah, that was pretty bad. "DKIM can be used to verify a piece of mail 
due to operator practices, but there are absolutely no guarantee that a 
signature will verify in the future due to those same practices."




ps. making sure that DKIM signature become invalid  relatively soon -- 
I think that removing the keys is simpler and just as effective as 
publishing the private keys -- seems like a reasonable suggestion.



Stephen Farrell is threatening to write an ID on the subject of 
publishing private keys. Frankly the stakeholders -- providers and users 
-- are not very well aligned on when where and why a provider would do 
such a thing. And writing an ID to say how to invalidate key when just 
unpublishing old selectors when you rotate keys is an easy second best 
shows that inertia is the actual issue, not the technical shortcoming.


Mike

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

Re: [dmarc-ietf] ARC questions

In article  
you write:
>I suppose that an approach to building up an ARC reputation might be one
>where over time a receiving site can compare indirect mail flow that is
>purported to have X as an authenticated identifier with mail that comes
>direct to the receiving site with X as an authenticated identifier. ...

I think it's more likely to be ad-hoc, does this source send mail that
looks like mailing lists and the recipients don't flag or complain
about it.

R's,
John

PS:

>This email and all data transmitted with it contains confidential and/or
>proprietary information intended solely for the use of individual(s)
>authorized to receive it. If you are not an intended and authorized
>recipient you are hereby notified of any use, disclosure, copying or
>distribution of the information included in this transmission is prohibited
>and may be unlawful. Please immediately notify the sender by replying to
>this email and then delete it from your system.

Too late.

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

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

In article <9f388e33-c15d-9fcc-e9d3-d7719288f...@gmail.com> you write:
>On 11/23/2020 1:04 PM, Jesse Thompson wrote:
>> I meant to suggest that the requirement for a tree walk would be that the 
>> Organizational Domain would need to have that in its policy. 
>It seems like a decent compromise for the people worried about unnecessary DNS 
>lookup overhead.

If I'm going to go to the effort to download and decode a PSL and find the OD, 
I'll just use the OD.

One of the points of the tree walk is to get rid of the PSL processing.

It looks to me that a tree walk limited to some modest number of
levels like 7 or 10 would handle close enough to 100% of real mail.
When I brought this up in dnsop last week there was some concern about
super long tree walks but I didn't get the NO NO NO that we got in the
old days. DNS operators now realize that an amazingly large fraction
of DNS traffic is garbage, and a little extra noise from the
occasional tree walk is not a big deal.

In normal mail, the number of labels is usually quite low, here's my 
distribution by
number of dots:

2404 .
1215 ..
 152 ...
  10 

R's,
John

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

Re: [dmarc-ietf] ARC questions

In article ,
Dave Crocker   wrote:
>> I believe, though, that the intent of ARC is that it be scalable in 
>> ways that manual enumeration of known legit mailing lists and 
>> forwarders is not.
>
>"if you know which hosts are legit" buries an assumption that is 
>problematic, namely that you know who handled the message.Â  The fact
>that a message purports to be handled by a mailing list you trust does 
>not mean it actually was.

Pretty close, but not quite.

You know that a message came from a mailing list because you have your
list of IPs or DKIM signatures of lists you trust.

ARC deals with the problem that most list software forwards everything
with a subscriber's address on the From: line and does a lousy job of
spam filtering. The question is if the entity sending the message to
the list was who it purported to be. 

For example, if a message from a list fails DMARC alignment, but ARC
says it was aligned on the way in, it's likely a real message from a
subscriber. If it was unaligned on the way in, it's likely wpam.

R's,
John
-- 
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup


On 11/23/2020 1:04 PM, Jesse Thompson wrote:

I meant to suggest that the requirement for a tree walk would be that the 
Organizational Domain would need to have that in its policy.  It seems like a 
decent compromise for the people worried about unnecessary DNS lookup overhead.


Except that it can't 'trigger' a tree walk.

On the other hand, it might declare itself to be the (an?) OD.

d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

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

Re: [dmarc-ietf] tree walk and Org and PSD, Second WGLC for draft-ietf-dmarc-psd

In article 
<553d43c8d961c14bb27c614ac48fc0312811f...@umechpa7d.easf.csd.disa.mil> you 
write:
>-=-=-=-=-=-
>
>Even for .mil, the vast majority of email domains are fairly short with four 
>or fewer labels. Most of the other ones tend to be
>individual servers that send automatic performance emails, and I think should 
>be considered more of an edge case and less of our concern.

I scraped my logs for the past few months and that's what I found.
Nearly everything was four labels or less. Spot checking the few
five-label names, I found that most of the mail was all from
MAILER-DAEMON@ and it appeared to be spam
blowback.  There was a trickle of what looked like real mail
from stumail.zcs.k12.in.us and feedback.retail.voice-your-views.hsbc.com,

I found nothing at all with six labels or longer.

So if we made the tree walk limit six or seven I think we'd be
unlikely to lose any mail that anyone would miss.

R's,
John


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

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

2020-11-23 Thread Jesse Thompson

On 11/23/20 1:00 PM, Dave Crocker wrote:
> On 11/23/2020 10:50 AM, Jesse Thompson wrote:
>> Would it help if there was a new DMARC policy tag to trigger the tree walk?
> 
> 
> policy tags are useful when one has a dmarc record that might contain it.  
> the challenge here is to find that record.

I meant to suggest that the requirement for a tree walk would be that the 
Organizational Domain would need to have that in its policy.  It seems like a 
decent compromise for the people worried about unnecessary DNS lookup overhead.

Jesse

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

Re: [dmarc-ietf] ARC questions



On 11/23/20 12:15 PM, Brandon Long wrote:



This recent article also goes into things that DKIM signatures imply:
https://blog.cryptographyengineering.com/2020/11/16/ok-google-please-publish-your-dkim-secret-keys/ 



Perhaps this all means that DKIM has been used for more than it was 
intended for.


It is a quirk that we didn't consider at the time. You can't count on 
that property because providers can change their selectors at any time. 
That said, there is an awful lot of hand wringing for not much gain. 
It's not like you need cryptographic non-repudiation to be pretty sure 
something wasn't forged. That and non-repudiation has its benefits as well.


Mike

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

Re: [dmarc-ietf] ARC questions

On 11/23/2020 12:15 PM, Brandon Long wrote:
On Mon, Nov 23, 2020 at 11:53 AM Dave Crocker > wrote:

> Yes, of course, a handling agent can do it, but there are plenty
of reasons
> why they shouldn't.

Please enumerate and explain. If it's that dangerous, we should
document it, especially I don't recall that constraint being in
any of
the design or standardization discussions.

DKIM often ties a domain to reputation and other anti-spam features.
If you
forward spam to another host and sign it while forwarding, then the
other host

will think you send spam.

Well, ummm... e... yes. That's because, in such circumstances, you do.

More significantly, the signature makes sure that such as an assessment
will only be made accurately, rather than penalizing you for problematic
mail that is attributed to you but that you did not handle.

DMARC ties DKIM to the From header and at least is interpreted as being an
anti-phishing feature. DKIM signing mail that you forward could mean
upgrading

a phishing message to passing DMARC.

I don't understand. The first sentence makes sense to me, but the
second doesn't.

"Upgrading...to passing DMARC only applies if a) the signature matches
the From: field domain, and b) that domain has an associated DMARC
record. But if you don't watch DMARC to apply in that case, what is the
DMARC record there fore?

This recent article also goes into things that DKIM signatures imply:
https://blog.cryptographyengineering.com/2020/11/16/ok-google-please-publish-your-dkim-secret-keys/

The level of condescension, ignorance, and error throughout that article
is impressive. Given that it was written by someone whose profession
requires extreme care about complex matters, the level of carelessness
in the article is especially unfortunate.

Conveniently, he put his biggest error in bold font:

"*DKIM provides a life-long guarantee of email authenticity that
anyone can use to cryptographically verify the authenticity of stolen
emails, even years after they were sent."*

DKIM does no such thing.

and this was quickly followed by the normal-font:

"The key design goal of DKIM was to prevent spammers from forging
emails /while in transit/. "

This, too, is not what DKIM does. DKIM provides a noise-free channel
for assessing signers, not for detecting spammers. The difference is
important; and I claim fundamental.

ps. making sure that DKIM signature become invalid relatively soon -- I
think that removing the keys is simpler and just as effective as
publishing the private keys -- seems like a reasonable suggestion.

Perhaps this all means that DKIM has been used for more than it was
intended for.

"More than" suggests that the use has legitimacy. It doesn't.

> > Intermediaries don't want to take ownership of the
message in that
> > sense, though there
> > are some mailing lists that do.
>
> Signing with DKIM does not take 'ownership'.
>
>
> Yes, responsibility is the proper word. My point survives the
word change.

I disagree.

> DKIM says the domain takes responsibility for the message, while
ARC says
> the domain takes responsibility for evaluating the status of the
message
> when
> they received and forwarded it.

This implies that the word 'some' is irrelevant. It isn't. And it
was
included intentionally.

Automated systems can't really tell how much responsibility an
intermediary was

intending to take for the message.

People who write them can.

OTOH, they typically are using it only for a certain
purpose, so they assume that the intermediary took responsibility in
the sense that they
want... or rather, the people who wrote the code do. Or the
journalist writing the story.

ARC was specified to have a more specific responsibility,

Forgive me but I think that:

Authenticated Received Chain (ARC) creates a mechanism for individual
Internet Mail Handlers to add their authentication assessment to a
message's ordered set of handling results.

specifies a nature and responsibility pretty much identical to what DKIM
claims. The enhancements are a) chaining, and b) carriage of earlier
assessments. But in terms of 'responsibility', this reads the same as DKIM.

and as different from DKIM so
that it wasn't mistaken for the uses that people were already using
DKIM for.

Oh?

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

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

Re: [dmarc-ietf] ARC questions



On 11/23/20 12:29 PM, John R Levine wrote:

1) A mailing list creates an auth-res on the incoming mail to the list

2) It modified the message

3) It resigns the message with DKIM

4) It is then delivered to the subscriber's mail server

5) The destination mail server can look at the incoming message 
including the mailing list's auth-res and decide whether to trust it 
or not just like ARC.


It seems to me this covers the vast majority of cases. What are the 
other cases where this is not sufficient and how significant are they 
in reality?


Two or more levels of forward are quite common, particularly in large 
mail systems.  Look at mail coming out of Google and Microsoft's 
hosted mail and you'll see a lot of ARC headers.


Considering that the ARC RFC was published over a year ago, and it is 
implemented all over the place, could you explain what the point of 
this discussion is?  The people who designed ARC are not idiots.  If 
we could have fixed the mailing list problem with existing DKIM 
signatures, we would have.


Then why is it not standards track? And am I to understand that I'm not 
allowed to comment on an experiment? Perhaps the working group chairs or 
AD can clarify that.


In any case, if this all boils down to whether I trust the intermediary 
who resigned the message, then that is a previously solved problem: you 
can base the reputation check based on the resigned signature. I'm not 
entirely sure what the value of  the previous auth-res is. If I recall 
correctly, the document was sort of short on what the specific utility 
is, but I may have missed it.


Mike

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

Re: [dmarc-ietf] ARC questions


1) A mailing list creates an auth-res on the incoming mail to the list

2) It modified the message

3) It resigns the message with DKIM

4) It is then delivered to the subscriber's mail server

5) The destination mail server can look at the incoming message including the 
mailing list's auth-res and decide whether to trust it or not just like ARC.


It seems to me this covers the vast majority of cases. What are the other 
cases where this is not sufficient and how significant are they in reality?


Two or more levels of forward are quite common, particularly in large mail 
systems.  Look at mail coming out of Google and Microsoft's hosted mail 
and you'll see a lot of ARC headers.


Considering that the ARC RFC was published over a year ago, and it is 
implemented all over the place, could you explain what the point of this 
discussion is?  The people who designed ARC are not idiots.  If we could 
have fixed the mailing list problem with existing DKIM signatures, we 
would have.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [dmarc-ietf] ARC questions




On 11/23/20 12:09 PM, John R Levine wrote:


Since this is an experiment, do we have an idea of what the rest of 
the problem is after the typical mailing list-like signature breakers 
are excluded?


Sorry, this question makes no sense. The point of ARC is to deal with
the kind of breakage that mailing lists cause.



1) A mailing list creates an auth-res on the incoming mail to the list

2) It modified the message

3) It resigns the message with DKIM

4) It is then delivered to the subscriber's mail server

5) The destination mail server can look at the incoming message 
including the mailing list's auth-res and decide whether to trust it or 
not just like ARC.


It seems to me this covers the vast majority of cases. What are the 
other cases where this is not sufficient and how significant are they in 
reality?


Mike

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

Re: [dmarc-ietf] ARC questions

2020-11-23 Thread Brandon Long

On Mon, Nov 23, 2020 at 11:53 AM Dave Crocker  wrote:

> On 11/23/2020 11:42 AM, Brandon Long wrote:
> >
> >
> > On Mon, Nov 23, 2020 at 11:34 AM Dave Crocker  > > wrote:
> >
> > On 11/23/2020 11:29 AM, Brandon Long wrote:
> >  > The DKIM-Signature is an "ownership" thing, it's a message
> > originator
> >  > that is saying
> >  > "associate this message to me".
> >
> > That is not DKIM's semantics:
> >
> >  "DomainKeys Identified Mail (DKIM) permits a person, role, or
> >  organization to claim some responsibility for a message by
> >  associating a domain name"
> >
> > This says nothing about whether the organization has anything to do
> > with
> > origination.
> >
> > There is nothing to prohibit or preclude handling agents other than
> the
> > originator from signing.
> >
> >
> > Yes, of course, a handling agent can do it, but there are plenty of
> reasons
> > why they shouldn't.
>
> Please enumerate and explain.  If it's that dangerous, we should
> document it, especially I don't recall that constraint being in any of
> the design or standardization discussions.
>

DKIM often ties a domain to reputation and other anti-spam features.  If you
forward spam to another host and sign it while forwarding, then the other
host
will think you send spam.

DMARC ties DKIM to the From header and at least is interpreted as being an
anti-phishing feature.  DKIM signing mail that you forward could mean
upgrading
a phishing message to passing DMARC.

This recent article also goes into things that DKIM signatures imply:
https://blog.cryptographyengineering.com/2020/11/16/ok-google-please-publish-your-dkim-secret-keys/

Perhaps this all means that DKIM has been used for more than it was
intended for.

> >  > Intermediaries don't want to take ownership of the message in that
> >  > sense, though there
> >  > are some mailing lists that do.
> >
> > Signing with DKIM does not take 'ownership'.
> >
> >
> > Yes, responsibility is the proper word.  My point survives the word
> change.
>
> I disagree.
>
>
> > DKIM says the domain takes responsibility for the message, while ARC says
> > the domain takes responsibility for evaluating the status of the message
> > when
> > they received and forwarded it.
>
> This implies that the word 'some' is irrelevant.  It isn't.  And it was
> included intentionally.
>

Automated systems can't really tell how much responsibility an intermediary
was
intending to take for the message.  OTOH, they typically are using it only
for a certain
purpose, so they assume that the intermediary took responsibility in the
sense that they
want... or rather, the people who wrote the code do.  Or the journalist
writing the story.

ARC was specified to have a more specific responsibility, and as different
from DKIM so
that it wasn't mistaken for the uses that people were already using DKIM
for.

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

Re: [dmarc-ietf] ARC questions

If auth-res is sometimes deleted, why wouldn't we expect the arc auth-res to 
not be deleted too?


Please see RFC 7001, section 5.

Since this is an experiment, do we have an idea 
of what the rest of the problem is after the typical mailing list-like 
signature breakers are excluded?


Sorry, this question makes no sense. The point of ARC is to deal with
the kind of breakage that mailing lists cause.

Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [dmarc-ietf] ARC questions



On 11/23/20 11:34 AM, Brandon Long wrote:


From the other direction, one could say that ARC is a superset of A-R 
and DKIM with
different purpose, and you might be able to subsume them into ARC, but 
you couldn't

build ARC out of the originals.



It's seems to me that the superset involves explicitly binding an 
auth-res to a dkim-like signature. Is there more beyond that?


Mike

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

Re: [dmarc-ietf] ARC questions



On 11/23/20 11:49 AM, Brandon Long wrote:


I imagine that the vast majority of intermediaries that break
signatures
number exactly one extra domain, so it's not very hard to reconstruct
the chain of custody from origin to destination. Assuming the
intermediary resigns with the incoming auth-res, the destination can
choose to believe that auth-res or not, right? Since this is an
experiment, do we have an idea of what the rest of the problem is
after
the typical mailing list-like signature breakers are excluded?


No, as in the RFC says to remove them, so it's a standard part of 
implementation.


RFC 7601 4.1:

instances of the header field that appear to originate within the
ADMD but

are actually added by foreign MTAs will be removed before delivery.


That's very different than "just maybe it might be removed"

The receiving MTA in the next domain doesn't have to discard the 
information before removing it. The act of removing it is so there isn't 
confusion about the ultimate auth-res, especially with MUA's. The 
incoming MTA is free to consider the previous auth-res just like it's 
free to consider the previous arc auth-res.


Mike

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

Re: [dmarc-ietf] ARC questions

On 11/23/2020 11:42 AM, Brandon Long wrote:

On Mon, Nov 23, 2020 at 11:34 AM Dave Crocker > wrote:

On 11/23/2020 11:29 AM, Brandon Long wrote:
 > The DKIM-Signature is an "ownership" thing, it's a message
originator
 > that is saying
 > "associate this message to me".

That is not DKIM's semantics:

     "DomainKeys Identified Mail (DKIM) permits a person, role, or
     organization to claim some responsibility for a message by
     associating a domain name"

This says nothing about whether the organization has anything to do
with
origination.

There is nothing to prohibit or preclude handling agents other than the
originator from signing.

Yes, of course, a handling agent can do it, but there are plenty of reasons
why they shouldn't.

Please enumerate and explain.  If it's that dangerous, we should 
document it, especially I don't recall that constraint being in any of 
the design or standardization discussions.

 > Intermediaries don't want to take ownership of the message in that
 > sense, though there
 > are some mailing lists that do.

Signing with DKIM does not take 'ownership'.

Yes, responsibility is the proper word.  My point survives the word change.

I disagree.

DKIM says the domain takes responsibility for the message, while ARC says
the domain takes responsibility for evaluating the status of the message 
when

they received and forwarded it.

This implies that the word 'some' is irrelevant.  It isn't.  And it was 
included intentionally.

d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

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

Re: [dmarc-ietf] ARC questions



On 11/23/20 11:42 AM, Brandon Long wrote:


Yes, responsibility is the proper word.  My point survives the word 
change.


DKIM says the domain takes responsibility for the message, while ARC says
the domain takes responsibility for evaluating the status of the 
message when

they received and forwarded it.


But it can already do that be re-signing its auth-res.

Mike

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

Re: [dmarc-ietf] ARC questions



On 11/23/20 11:28 AM, John R Levine wrote:
From what I can tell, the main thing that ARC is doing is binding an 
auth-res to a dkim signature-like thing. But as I recall -- it's been 
a long time -- there were ordering requirements ala received headers 
for where new dkim-signatures and auth-res go in the header. Assuming 
my memory is correct, that means you can reconstruct "what this 
looked like before i messed with it" already by signing the incoming 
auth-res as part of the new DKIM signature.


Is there something more going on here?


Not really.  There are ordering rules but mail systems do not follow 
them reliably, DKIM signatures in practice are not ordered.  Also, A-R 
can be deleted in some situations, so ARC makes copies of them to be 
more robust in transit.


If auth-res is sometimes deleted, why wouldn't we expect the arc 
auth-res to not be deleted too?


I imagine that the vast majority of intermediaries that break signatures 
number exactly one extra domain, so it's not very hard to reconstruct 
the chain of custody from origin to destination. Assuming the 
intermediary resigns with the incoming auth-res, the destination can 
choose to believe that auth-res or not, right? Since this is an 
experiment, do we have an idea of what the rest of the problem is after 
the typical mailing list-like signature breakers are excluded?


Mike

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

Re: [dmarc-ietf] ARC questions


On 11/23/2020 11:29 AM, Brandon Long wrote:
The DKIM-Signature is an "ownership" thing, it's a message originator 
that is saying

"associate this message to me".


That is not DKIM's semantics:

   "DomainKeys Identified Mail (DKIM) permits a person, role, or
   organization to claim some responsibility for a message by
   associating a domain name"

This says nothing about whether the organization has anything to do with 
origination.


There is nothing to prohibit or preclude handling agents other than the 
originator from signing.





Intermediaries don't want to take ownership of the message in that 
sense, though there

are some mailing lists that do.


Signing with DKIM does not take 'ownership'.



d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] ARC questions

From what I can tell, the main thing that ARC is doing is binding an auth-res 
to a dkim signature-like thing. But as I recall -- it's been a long time -- 
there were ordering requirements ala received headers for where new 
dkim-signatures and auth-res go in the header. Assuming my memory is correct, 
that means you can reconstruct "what this looked like before i messed with 
it" already by signing the incoming auth-res as part of the new DKIM 
signature.


Is there something more going on here?


Not really.  There are ordering rules but mail systems do not follow them 
reliably, DKIM signatures in practice are not ordered.  Also, A-R can be 
deleted in some situations, so ARC makes copies of them to be more robust 
in transit.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup


On 11/23/2020 10:50 AM, Jesse Thompson wrote:

Would it help if there was a new DMARC policy tag to trigger the tree walk?



policy tags are useful when one has a dmarc record that might contain 
it.  the challenge here is to find that record.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

2020-11-23 Thread Jesse Thompson

On 11/20/20 6:02 PM, John R Levine wrote:
> Here's a draft about how DMARC might do a tree walk rather than look up an 
> organizational domain in the PSL.
> 
> https://datatracker.ietf.org/doc/draft-levine-dmarcwalk/

Would it help if there was a new DMARC policy tag to trigger the tree walk?  
It's still the same number of DNS lookups, but changes the order and doesn't 
happen unless the organization wants it, so (aside from potential abuse) it 
should minimize the overall DNS lookup overhead.

Look up _dmarc.sales.east.widgets.bigcorp.com - find no policy
Look up _dmarc.bigcorp.com - finds a policy with a tw=1 tag
Look up _dmarc.east.widgets.bigcorp.com - find no policy
Look up _dmarc.widgets.bigcorp.com - finds a valid sp tag

Is it also worth considering changing the direction of the lookups under the 
assumption that the consistency of/control over the sub-organization's sending 
practices increases with each branch?  This would potentially reduce the number 
of DNS lookups.

Look up _dmarc.sales.east.widgets.bigcorp.com - find no policy
Look up _dmarc.bigcorp.com - finds a policy with a valid tw=true tag
Look up _dmarc.widgets.bigcorp.com - finds a valid sp tag and no additional 
tw=1 tag

Jesse

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

Re: [dmarc-ietf] ARC questions



On 11/22/20 11:56 AM, John R Levine wrote:

On Sun, 22 Nov 2020, Michael Thomas wrote:
The ARC signature has a sequence number so you can track the chain 
of custody.  You are right that it is similar to the DKIM signature 
but the extra ovehead doesn't seem excessive.


Did the wg consider just grafting that onto the DKIM signature itself 
instead of having essentially a duplicate signature? Receivers are 
already supposed to ignore any tags they don't understand so it 
shouldn't hurt backward compatibility.


ARC is an experiment that came from the people who designed DMARC.  
It's not a WG product.


Having adapted the perl DKIM module to handle ARC signing and 
verification, I can say that the extra signature is not a big deal.  
If you look at mail coming from large mail systems, they're full of 
other junk headers and the extra overhead of AMS along with DKIM is 
not important.


From what I can tell, the main thing that ARC is doing is binding an 
auth-res to a dkim signature-like thing. But as I recall -- it's been a 
long time -- there were ordering requirements ala received headers for 
where new dkim-signatures and auth-res go in the header. Assuming my 
memory is correct, that means you can reconstruct "what this looked like 
before i messed with it" already by signing the incoming auth-res as 
part of the new DKIM signature.


Is there something more going on here?

Mike

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

Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

2020-11-23 Thread Doug Foster

I was misinterpretation the language to require detection whether any host 
existed in the zone, rather than checking whether there is a host name which 
matches the domain name.  Thank you to Murray for straightening me out.

 

That aside, we still have a problem.   The specification is applying SPF-type 
logic to an address that has no necessary connection to SPF.   A typical 
advertising message, sent be a third party, will pass SPF using the third-party 
sender’s domain.The message From address becomes a label to identify the 
client organization in some manner, and possibly to identify the identity of 
the marketing campaign.  The domain name used for that purpose may not exist 
anywhere else, often does not accept replies, and may not exist as a mail 
server domain anywhere.Consequently, these may very well be unregistered 
domains, but it may be reasonable to insist that domain owners get them 
registered to avoid false positives from the test.   The least disruptive test 
will be for NS.   Anything stricter will produce false positives.

 

The logic that seems to work is:

-  Check SPF and DKIM for domain alignment.   If the DMARC criteria are 
satisfied by either method, the message domain does not need to exist, because 
it has been validated.

-  If the message does not pass DMARC alignment, then we need to look 
for a DMARC policy to see if P/SP/NP applies.  If NP applies, and NS does not 
exist, the NP policy is applied.

 

Using the example domain from the document, I am assuming that we are trying to 
block all three of these non-existent domains:

-  T4x.gov.example

-  Spammer.t4x.gov.example

-  Spammer.tax.gov.example

If the goal is only to block t4x.gov.example, then the current NP algorithm is 
slightly less problematic.

 

Doug Foster

 

 

From: Tim Wicinski [mailto:tjw.i...@gmail.com] 
Sent: Thursday, November 19, 2020 11:04 PM
To: fost...@bayviewphysicians.com
Cc: IETF DMARC WG
Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

 

Doug

 

In looking for domain presence most folks will look at the domain itself.  
There are a few web tools to enumerate

such as https://dnschecker.org/ 

 

Some examples

https://dnschecker.org/#MX/dmarc.org

https://dnschecker.org/#TXT/dmarc.org

https://dnschecker.org/#TXT/_dmarc.dmarc.org

 

There are unix tools - such as 'dig' - which are also quite useful.

 

hope this helps

tim

 

 

On Thu, Nov 19, 2020 at 10:44 PM Douglas E. Foster 
 wrote:

Time to show my ignorance again.

 

How do I check a domain for presence or absence of A, , or MX records?

I thought most domains were protected from enumeration, so one had to know a 
name to find out if it is defined

 

DF

 

 


  _  


From: "Douglas E. Foster" 
Sent: 11/19/20 9:27 PM
To: "IETF DMARC WG" 
Subject: RE: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

 

Thank you for the pointer Eric.

 

Can someone explain why the chosen algorithm, which requires testing multiple 
conditions, is preferable to a single query for a name server record?   
Minimizing DNS traffic has been part of our recent discussion, and minimizing 
software complexity is always a good thing.

 

Can someone also explain why the DMARC appendix takes such a strong stance 
against all queries for non-existent domains, regardless of technique?  It 
seems like the philosophical incompatibilities need to be addressed before both 
documents advance.

 

DMARC is specified only as a test for the RFC5322.From domain.   
RFC5321.MailFrom domains may also be non-existent.  They will return SPF NONE, 
but that is an ambiguous result, and SPF has no organization default mechanism. 
  

*   Is there data to indicate whether evaluators have found that checking 
the RFC5321.MailFrom for non-existence is useful?   
*   Suppose that the NP policy becomes generalized, and a domain has 
asserted a "must-exist" DMARC policy.   Should a non-existent subdomain used in 
the RFC5321.MailFrom address be treated skeptically?

I can imagine a scenario where a spammer uses a bogus subdomain of a legitimate 
organization, in an attempt to get whitelisted by spam filters which primarily 
evaluate the RFC5321.MailFrom address.   This attack could be paired with an 
unrelated and non-DMARC RFC5322.From address which is newly minted or otherwise 
not generally known to be suspicious,   So my instinct is that some extension 
of DMARC to the SMTP address will be beneficial.

 

Doug Foster

 

 

 

 


  _  


From: "Chudow, Eric B CIV NSA DSAW (USA)" 
Sent: 11/19/20 5:31 PM
To: 'Doug Foster' , 'IETF DMARC WG' 

Cc: "'dmarc-cha...@ietf.org'" 
Subject: RE: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

 

Section 2.7. defines a non-existent domain as "a domain for which there is an 
NXDOMAIN or NODATA response for A, , and MX records. This is a broader 
definition than that in NXDOMAIN [RFC8020]."

Re: [dmarc-ietf] ARC questions


On 11/23/2020 10:34 AM, Todd Herr wrote:
Yes, but knowing it really was handled by who is saying it was handled 
by isn't the entirety of the problem.



Of course.  But it helps (quite a lot) to be clear about what this 
specific mechanism does do.


d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

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

Re: [dmarc-ietf] ARC questions

2020-11-23 Thread Todd Herr

On Mon, Nov 23, 2020 at 12:02 PM Dave Crocker  wrote:

> On 11/23/2020 7:38 AM, Todd Herr wrote:
>
> On Mon, Nov 23, 2020 at 9:50 AM Joseph Brennan 
> wrote:
> On Sat, Nov 21, 2020 at 7:14 PM John Levine  wrote:
>
>>
>>
>>> This also means that ARC isn't useful if you don't have a reputation
 system to tell you where the lists and other forwarders that might add
 legit ARC signatures are.

>>>
>> And if you know which hosts are legit mailing lists or forwarders, you
>> already know what ARC would tell you.
>>
>
> I believe, though, that the intent of ARC is that it be scalable in ways
> that manual enumeration of known legit mailing lists and forwarders is not.
>
>
> "if you know which hosts are legit" buries an assumption that is
> problematic, namely that you know who handled the message.  The fack that a
> message purports to be handled by a mailing list you trust does not mean it
> actually was.
>
> That's the issue that ARC resolves.
>
> ARC (and DKIM) produce noise-free uses of identifiers.  If the
> authentication validates, the receiver knows is really was handled by who
> is saying it was handled by.  Without these, you don't.
>
>
> Yes, but knowing it really was handled by who is saying it was handled by
isn't the entirety of the problem.

I can know from ARC headers that X handled the message and what email
authentication checks X purports to have done when handling the message and
what results X claims to have obtained. What I have to decide in that case
is "do I trust X to record correct and valid results?" because the answer
to that question will impact my disposition of the message when it reaches
me.

It's obviously not the place of the ARC protocol spec to proscribe how
trust in ARC results can be determined, but without some system in place
for assigning trust levels to ARC Sealers, ARC has limited utility for
sites that serve as the terminal destination for a message.

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.h...@valimail.com
*p:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] tree walk and Org and PSD, Second WGLC for draft-ietf-dmarc-psd

2020-11-23 Thread Jesse Thompson

On 11/23/20 8:28 AM, eric.b.chudow.civ=40mail@dmarc.ietf.org wrote:
> Even for .mil, the vast majority of email domains are fairly short with four 
> or fewer labels. Most of the other ones tend to be individual servers that 
> send automatic performance emails, and I think should be considered more of 
> an edge case and less of our concern. 

This is the case for us as well (e.g. our comp sci high throughput compute 
cluster servers send automatic emails to both internal and external research 
collaborators).  I suppose universities are different than the military since 
the military probably doesn't want their servers to be sending email 
externally, whereby with a research university cross-institutional 
collaboration is inherent.

I suppose I consider it an edge case too (a large edge case - I see over 200 of 
these 4th level domains in or DMARC aggregate reports for the example cluster I 
cite), but the long tail of servers also aren't likely to change the way they 
are sending email nor will sysadmins implement SPF/DKIM for every server 
hostname, etc, so these subdomains are a blocker for publishing sp=reject at 
the org domain (hence a concern within the context of tree walking).

While I understand that there are implementation challenges that may make this 
infeasible, what I would *like* to do is ask each of these departments/research 
teams to publish sp=none at their 3rd level domains (and take over DMARC 
responsibilities for their parts of the tree) so that we can publish sp=reject 
at the org domain to protect/manage the rest of the university.

Jesse

P.S. Here are some stats.  Unique domains used in the RFC5322.From resulting 
from mail sent externally to DMARC reporting organizations in the past 2 weeks:
23 2nd level (org domains)
464 3rd level (359 are subdomains of wisc.edu)
522 4th level (all are subdomains of wisc.edu)
13 5th level
2 6th level

> 
>  
> 
> Thanks,
> 
>  
> 
> Eric Chudow
> 
> DoD Cybersecurity Mitigations
> 
>  
> 
> --
> *From:* Laura Atkins [la...@wordtothewise.com]
> *Sent:* Monday, November 23, 2020 8:19 AM
> *To:* Murray S. Kucherawy
> *Cc:* IETF DMARC WG
> *Subject:* Re: [dmarc-ietf] tree walk and Org and PSD, Second WGLC for 
> draft-ietf-dmarc-psd
> 
> 
> 
>> On 22 Nov 2020, at 06:06, Murray S. Kucherawy > > wrote:
>>
>> On Sat, Nov 21, 2020 at 6:23 PM John Levine > > wrote:
>>
>> It is my impression that most real From: domains are pretty short. I
>> don't think I've ever seen one more than four labels long that wasn't
>> deliberately contrived. Anyone got data on that?
>>
>>
>> I'd bet there are some in .gov or .mil, especially the latter, but otherwise 
>> I think the longest one I've seen is five, and that was not a host that 
>> receives mail.
>>
>> I'm sure we can all scrape our own mail logs for evidence either way.
> 
> This might be a place where one (or more) of the big ESPs can help. They’re 
> going to have billions of email addresses and know which ones have MXs. I’m 
> happy to ask for that data if it would be of use. 
> 
> laura 
> 
> -- 
> Having an Email Crisis?  We can help! 800 823-9674 
> 
> Laura Atkins
> Word to the Wise
> la...@wordtothewise.com 
> (650) 437-0741
> 
> Email Delivery Blog: https://wordtothewise.com/blog 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> 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] ARC questions


On 11/23/2020 9:15 AM, Doug Foster wrote:
ARC tells me that somebody changed some data, but it does not tell me 
which MTA performed the forwarding operation, added content, or 
performed address rewriting.  If we could get HELO names into the ARC 
data, then those names could be correlated with the Received header 
chain to make better filtering decisions.



That's not ARC.  Feel free to recruit others to support a new 
initiative, for a different protocol.


d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

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

Re: [dmarc-ietf] ARC questions

2020-11-23 Thread Doug Foster

My wishlist for ARC:

 

ARC tells me that somebody changed some data, but it does not tell me which MTA 
performed the forwarding operation, added content, or performed address 
rewriting.  If we could get HELO names into the ARC data, then those names 
could be correlated with the Received header chain to make better filtering 
decisions.

 

DF   

 

From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Dave Crocker
Sent: Monday, November 23, 2020 12:02 PM
To: Todd Herr; Joseph Brennan
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] ARC questions

 

On 11/23/2020 7:38 AM, Todd Herr wrote:

On Mon, Nov 23, 2020 at 9:50 AM Joseph Brennan  wrote:

On Sat, Nov 21, 2020 at 7:14 PM John Levine  wrote:

 

This also means that ARC isn't useful if you don't have a reputation
system to tell you where the lists and other forwarders that might add
legit ARC signatures are. 

 

And if you know which hosts are legit mailing lists or forwarders, you already 
know what ARC would tell you.

 

I believe, though, that the intent of ARC is that it be scalable in ways that 
manual enumeration of known legit mailing lists and forwarders is not. 

 

"if you know which hosts are legit" buries an assumption that is problematic, 
namely that you know who handled the message.  The fack that a message purports 
to be handled by a mailing list you trust does not mean it actually was.

That's the issue that ARC resolves.

ARC (and DKIM) produce noise-free uses of identifiers.  If the authentication 
validates, the receiver knows is really was handled by who is saying it was 
handled by.  Without these, you don't.

d/

-- 

Dave Crocker
dcroc...@gmail.com
408.329.0791
 
Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions