Re: [dmarc-ietf] Seeking volunteers to edit DMARCbis

[Hector Santos]

On 6/12/2020 8:02 PM, Jim Fenton wrote:

On 6/12/20 10:49 AM, Alexey Melnikov wrote:

About a year ago, I had suggested [1] that the reporting and policy
mechanisms of DMARC be split, and was, I think, the only one supporting
that idea.


Jim, I supported the proposal as well.

https://mailarchive.ietf.org/arch/msg/dmarc/s-UTti8Hlye6mYSMODDoYvfvKCs/

We even exchanged emails about it.


Although you have only had a preliminary discussion, do you have in mind
an editorial split (different functional pieces, but DMARC is still one
thing) or an actual split into separate specifications?

Someone (not sure who) said in yesterday's interim that DMARC could run
into trouble in IETF Last Call or in IESG review because of the breakage
to mailing lists, etc. If we had independent specifications, at least
the reporting pieces could proceed. So I (still) support the split.

[1] https://mailarchive.ietf.org/arch/msg/dmarc/HJwOvLspQKo-_GuW7W9xZPvv370/


+1, I also support the split. It worked with DKIM, separating your SSP 
Policy as a proposed standard allowing us to move forward with 
DKIM-base as a STD.  Unfortunately, ADSP was never completed and dropped.


I see the following:

DMARC-Base   proposed standard
DMARC-Reporting proposed standard
DMARC-TPA (Third Party Authorization) Experimental

Get it done.

--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos


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

Re: [dmarc-ietf] MUAs showing From: address field, was Re: DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields D

[Hector Santos]

On 6/13/2020 12:37 AM, Steven M Jones wrote:

On 6/2/20 5:45 PM, Douglas E. Foster wrote:

And consider the fact that today mobile devices are the MUA of choice
for many/most end users. Mobile MUAs are much less likely to show an
rfc5322.From address field even in the message body view.


On my iPhone, All I had to do is tap the from field and it shows up.
On Tbird, I hover of the From and its shown.

I think the concern with this is a bit overblown, however, if we 
continue to do allow and accept things like Rewriting in lieu of 
simply honoring the policy, then we have open the door for "bad guy" 
do the same thing.


Honor the policy.

--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos


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

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

[Hector Santos]

On 6/13/2020 1:19 AM, Hector Santos wrote:

A DKIM Policy compliant list server simply needs to do two things:

1) Prohibit new subscribers using addresses with restrictive domains,
just like it is done here:

https://secure.winserver.com/public/code/html-subscribe?list=winserver

2) Prohibit submission from existing subscribers using addresses with
restrictive domains. The existing subscriber becomes a read-only
subscriber.

We had very little complaints at the beginning. But the member, for is
own domain protection, had to use another list restrictive domain to
participate. Right now, it works this way and it works without
complaints.


That should be "another less restrictive or non-restricted domain"

--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos


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

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

[Hector Santos]

On 6/12/2020 4:02 AM, Alessandro Vesely wrote:

Hi all,




*From rewriting is the real thing*
==

Rewriting From: is the de-facto standard.


I don't support it.


In a (science-fictitious) scenario where all mailing lists
rewrite the From: header field, DMARC would just work
smoothly.


Occam's razor. The simplest and most honorable protocol solution is to 
follow the specs.  DMARC will work just fine without tampering with 
headers if the list server simply honored the restrictive policy. It 
works greats!!


A DKIM Policy compliant list server simply needs to do two things:

1) Prohibit new subscribers using addresses with restrictive domains, 
just like it is done here:


https://secure.winserver.com/public/code/html-subscribe?list=winserver

2) Prohibit submission from existing subscribers using addresses with 
restrictive domains. The existing subscriber becomes a read-only 
subscriber.


We had very little complaints at the beginning. But the member, for is 
own domain protection, had to use another list restrictive domain to 
participate. Right now, it works this way and it works without complaints.



Hence, we have to specify an acceptable way to rewrite From:.


This is no acceptable way to tamper the mail in this way.  But I did 
suggest with following. For an example of what it did to my headers:


X-Original-From: Hector Santos 
From: Hector Santos 

In order to close the loophole the rewriting has opened, in addition, 
to falsely associate my name with dmarc.ietf.org domain,  the rewriter 
needs to use a signer domain that matches the original protection.


dmarc.ietf.org is currently using::

v=DMARC1; p=none; 
rua=mailto:dmarc_agg@vali.email,mailto:dmarc-rep...@ietf.org


The dmarc.ietg.org policy should be, at a minimum, p=quarantine. 
dmarc.ietf.org is only used for rewriting when the submission has a 
restrictive author domain, so the dmarc.ietf.org should be restrictive.


--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos


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

[dmarc-ietf] MUAs showing From: address field, was Re: DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields D

[Steven M Jones]

On 6/2/20 5:45 PM, Douglas E. Foster wrote:


As to visibility: The business world still runs on Microsoft Outlook, 
and **Outlook presents the From Address** when a message is read. So 
it is odd to assert that no one ever sees that data.


[Emphasis added]

Regarding this and a subsequent message in this thread from Ale, that 
may be true in the message body display, but usually not in folder 
views. Once the message is opened the body pane may show the full fields 
or not, but often a hasty or preoccupied user is busy reading and 
engaging with the content, and it's too late.


Also, I believe this is relatively recent behavior for Outlook. My 
recollection is that for many years Outlook was notorious for only 
showing the display name (or perhaps in some cases certain Active 
Directory fields it looked up) even in the body view. This has changed 
at some point but I believe it was true during the original DMARC 
effort, and I believe it was still true while this WG was working on the 
drafts that led to RFC7489.


However, the versions of Outlook I just checked (Outlook/macOS and 
Outlook Web Access) do show both rfc5322.From display name and address 
field in the body view  some of the time, perhaps most of the time -- 
but not all of the time. Viewing two messages from the same mailing list 
in OWA, one showed both fields and one only showed the display name. 
Window size did not appear to be a factor. The same applied for a 
periodic message sent from a vendor - both fields displayed in 
Outlook/macOS, only the display name in OWA.


And consider the fact that today mobile devices are the MUA of choice 
for many/most end users. Mobile MUAs are much less likely to show an 
rfc5322.From address field even in the message body view.


--S.



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

Re: [dmarc-ietf] why ARC

[Dave Crocker]

ARC lets the recipient look back and retroactively do the filtering
the list didn't.


The concern about the creator of an ARC chain spoofing the purported 
origin of a message is valid.  The above statement is correct, but needs 
to be augmented:


 Based on the reputation of the creator of an ARC chain, ARC let's 
the receiving filtering engine do filtering based on the proffered 
address of the originator.


(Recipient end-users are irrelevant to this process.)

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] why ARC

[John Levine]

In article <45af2d9b-a2d9-4d5c-b1fd-aae906d3a...@kitterman.com> you write:
>Which still leaves the question of what the value proposition is since
>if you trust the source, what more does ARC really do (I suspect that
>the answer is more tokens to run through your bayesian or whatever
>filter)?

When I asked that a while ago I got a quite reasonable response.

Mailing lists do a lousy job of spam filtering, often only checking
that the From: address is a subscriber, and it is quite common for a
legit list to start leaking or even gushing spam. I've often seen it
when someone's address book gets stolen, spammers start taking 
(from, to) from) pairs from the address book, and one of the pairs happens
to be (another subscriber, list).

ARC lets the recipient look back and retroactively do the filtering
the list didn't. As a concrete example, I find that it is extremely
rare for legit mail coming into a list to be DMARC unaligned (as
opposed to mail coming out of the list) so if you can look back at the
ARC chain and demote mail which failed DMARC coming in, you will catch
a lot of spam without a lot of mistakes.

R's,
John

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

[dmarc-ietf] spf helo considered in arc ?

[Benny Pedersen]

i just like to know

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

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

[Scott Kitterman]

On June 12, 2020 11:33:13 PM UTC, "Kurt Andersen (b)"  wrote:
>I would like to understand what you mean by:
>
>On Fri, Jun 12, 2020 at 1:02 AM Alessandro Vesely 
>wrote:
>
>> . . . ARC chains can be forged.

Not sure what is confusing about that.  There's no requirement that signatures 
from previous hops still verify, so anyone can build an ARC chain that claims 
they got something from an arbitrary source.  ARC is only usable if you know 
you trust the source.

Which still leaves the question of what the value proposition is since if you 
trust the source, what more does ARC really do (I suspect that the answer is 
more tokens to run through your bayesian or whatever filter)?

Scott K

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

Re: [dmarc-ietf] Seeking volunteers to edit DMARCbis

[Jim Fenton]

On 6/12/20 10:49 AM, Alexey Melnikov wrote:
> Hi Alessandro,
>
> On Fri, Jun 12, 2020, at 5:51 PM, Alessandro Vesely wrote:
>> Hi,
>>
>> On Fri 12/Jun/2020 18:09:41 +0200 Alexey Melnikov wrote:
>>> On behalf of DMARC chairs I would like to ask for volunteers to edit future 
>>> revisions of draft-kucherawy-dmarc-dmarcbis. We are likely to split up the 
>>> current document into multiple drafts that can be progressed in parallel, 
>>> so we are seeking multiple editors to help with this.
>>
>> Is it already defined which and how many I-Ds will the WG do?
> We (chairs) only had a preliminary discussion. I think at least 3 (aggregated 
> reports, failure reports, the rest).

About a year ago, I had suggested [1] that the reporting and policy
mechanisms of DMARC be split, and was, I think, the only one supporting
that idea. There were quite a few comments along the line of, "it's not
broken, so why should we go to the trouble?"

Although you have only had a preliminary discussion, do you have in mind
an editorial split (different functional pieces, but DMARC is still one
thing) or an actual split into separate specifications?

Someone (not sure who) said in yesterday's interim that DMARC could run
into trouble in IETF Last Call or in IESG review because of the breakage
to mailing lists, etc. If we had independent specifications, at least
the reporting pieces could proceed. So I (still) support the split.

-Jim

[1] https://mailarchive.ietf.org/arch/msg/dmarc/HJwOvLspQKo-_GuW7W9xZPvv370/



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

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

[Kurt Andersen (b)]

I would like to understand what you mean by:

On Fri, Jun 12, 2020 at 1:02 AM Alessandro Vesely  wrote:

> . . . ARC chains can be forged.
>

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

Re: [dmarc-ietf] Seeking volunteers to edit DMARCbis

[Alexey Melnikov]

Hi Alessandro,

On Fri, Jun 12, 2020, at 5:51 PM, Alessandro Vesely wrote:
> Hi,
> 
> On Fri 12/Jun/2020 18:09:41 +0200 Alexey Melnikov wrote:
> > 
> > On behalf of DMARC chairs I would like to ask for volunteers to edit future 
> > revisions of draft-kucherawy-dmarc-dmarcbis. We are likely to split up the 
> > current document into multiple drafts that can be progressed in parallel, 
> > so we are seeking multiple editors to help with this.
> 
> 
> Is it already defined which and how many I-Ds will the WG do?

We (chairs) only had a preliminary discussion. I think at least 3 (aggregated 
reports, failure reports, the rest).

> 
> > If you are interested or know somebody who might be interested, please 
> > email dmarc-cha...@ietf.org directly. Also feel free to email 
> > dmarc-cha...@ietf.org if you have questions about expectations, time 
> > commitment, process, etc.
> 
> 
> I'd be interested, if there are no better editors...
> 
> I know Tim is maintaining a draft on GitHub[*].  Is that the doc to be split?

Yes.

> 
> Best
> Ale
> -- 
> 
> [*] https://github.com/moonshiner/draft-kucherawy-dmarc-dmarcbis

Best Regards,
Alexey

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

Re: [dmarc-ietf] Seeking volunteers to edit DMARCbis

[Alessandro Vesely]

Hi,

On Fri 12/Jun/2020 18:09:41 +0200 Alexey Melnikov wrote:


On behalf of DMARC chairs I would like to ask for volunteers to edit future 
revisions of draft-kucherawy-dmarc-dmarcbis. We are likely to split up the 
current document into multiple drafts that can be progressed in parallel, so we 
are seeking multiple editors to help with this.



Is it already defined which and how many I-Ds will the WG do?



If you are interested or know somebody who might be interested, please email 
dmarc-cha...@ietf.org directly. Also feel free to email dmarc-cha...@ietf.org 
if you have questions about expectations, time commitment, process, etc.



I'd be interested, if there are no better editors...

I know Tim is maintaining a draft on GitHub[*].  Is that the doc to be split?

Best
Ale
--

[*] https://github.com/moonshiner/draft-kucherawy-dmarc-dmarcbis

























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

[dmarc-ietf] Seeking volunteers to edit DMARCbis

[Alexey Melnikov]

Hi all,

On behalf of DMARC chairs I would like to ask for volunteers to edit future 
revisions of draft-kucherawy-dmarc-dmarcbis. We are likely to split up the 
current document into multiple drafts that can be progressed in parallel, so we 
are seeking multiple editors to help with this.

If you are interested or know somebody who might be interested, please email 
dmarc-cha...@ietf.org directly. Also feel free to email dmarc-cha...@ietf.org 
if you have questions about expectations, time commitment, process, etc.

Best Regards,
Alexey, as DMARC co-chair

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

Re: [dmarc-ietf] More redacted RUF reports better than no RUF reports

[Tõnu Tammer]

Hi,

RUF reports are useful for the organizations to understand that an
attack has actually begun (i.e. phishing of bank). This is extremely
useful and helpful tool for security teams. It helps them to act faster
in reacting to such events i.e. via take down requests of phishing sites. 

Kind regards,

-- 
Tõnu Tammer
CERT-EE juht / Executive Director of CERT-EE
Riigi Infosüsteemi Amet / Estonian Information System Authority

Email: t...@cert.ee
Mobile: +372 53 284 054
Web: https://cert.ee

PGP:0x77A8997 / 9477 6B86 6A1E 849B C456  46D6 9CA8 9E41 77A8 997B


On 12.06.2020 15:58, Shehzad Mirza wrote:
> Hi All,
>
> I've been following conversations as best I can via the digest (which
> was a bad idea), so switched to single emails. 
>
> Based on what I've heard from those just starting off with DMARC and
> have received very few failure reports, it's actually useful to get
> some form of them (redacted or not).  In one case, all the failure
> reports were spam messages.  This helped to push the org to get to a
> policy of reject as soon as they could.  
>
> For other organizations, which were not getting any failure reports,
> the question continuously comes up on how can they determine which
> messages are the ones that are failing (and not having to try and dig
> through a day's worth of messages to try and figure it out).  I think
> this is where the failure reports can help to some extent.
>
> Just my 2 cents, for what it's worth.
>
> - Shehzad
>
>  
> • • • • 
> Shehzad Mirza
> Director of Operations
> Global Cyber Alliance
> smi...@globalcyberalliance.org 
> (+1) 646 677 5535 (Option 3)
> GCA Website 
>
>                                                                      
>                                   
> GCA Twitter  GCA Facebook
>    GCA LinkedIn
>  GCA YouTube
> GCA GitHub
>  GCA Email Signup
>  GCA Instagram
>   GCA Forums
> 
>
> GCA takes your privacy seriously. To review
> our privacy policy, please click here
> .
>
>
>   
>   
>   
>   
>   
>
>
>
>
>
>
> On Thu, Jun 11, 2020 at 11:40 PM Steven M Jones  > wrote:
>
> On 6/11/20 5:22 PM, Scott Kitterman wrote:
> >> On June 11, 2020 6:28:13 PM UTC, Steven M Jones >  wrote:
> >> ... I also suggested that perhaps potential failure report
> generators
> >> would be encouraged if they could see examples of reports with
> >> different levels of redaction.
> >
> > I think it's entirely sensible to assess demand before investing
> a lot of time in this.  ...  I think the real question on this
> issue is for receivers.  Is there anyone working that side of the
> equation that would be inspired to send some kind of limited
> feedback report where they send none now is they had clearer
> examples to work from.
>
>
> I should have said "I speculated," I suppose... While listening to
> Autumn I couldn't recall having seen such examples, so I threw the
> idea
> out there.
>
> Anyway yes, we should be guided by data where we can get it. But if
> we're looking for something better than "anecdata," at the moment
> I can
> only imagine getting that through a careful survey of a large
> number of
> non-reporting receivers. And I don't see that happening unless it
> covers
> a lot more questions than just whether examples of redacted failure
> reports would have changed the decision not to send failure reports...
>
> If there's no sense that it would be useful, no need for further
> discussion.
>
> --S.
>
>
> ___
> 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

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

Re: [dmarc-ietf] More redacted RUF reports better than no RUF reports

[Shehzad Mirza]

Hi All,

I've been following conversations as best I can via the digest (which was a
bad idea), so switched to single emails.

Based on what I've heard from those just starting off with DMARC and have
received very few failure reports, it's actually useful to get some form of
them (redacted or not).  In one case, all the failure reports were spam
messages.  This helped to push the org to get to a policy of reject as soon
as they could.

For other organizations, which were not getting any failure reports, the
question continuously comes up on how can they determine which messages are
the ones that are failing (and not having to try and dig through a day's
worth of messages to try and figure it out).  I think this is where the
failure reports can help to some extent.

Just my 2 cents, for what it's worth.

- Shehzad


• • • •
Shehzad Mirza
Director of Operations
Global Cyber Alliance
smi...@globalcyberalliance.org
(+1) 646 677 5535 (Option 3)
[image: GCA Website] 


[image: GCA Twitter]  [image: GCA
Facebook]  [image: GCA
LinkedIn]  [image:
GCA YouTube]  [image:
GCA GitHub]  [image: GCA Email
Signup]  [image: GCA Instagram]
 [image: GCA Forums]


GCA takes your privacy seriously. To review
our privacy policy, please click here
.





On Thu, Jun 11, 2020 at 11:40 PM Steven M Jones  wrote:

> On 6/11/20 5:22 PM, Scott Kitterman wrote:
> >> On June 11, 2020 6:28:13 PM UTC, Steven M Jones  wrote:
> >> ... I also suggested that perhaps potential failure report generators
> >> would be encouraged if they could see examples of reports with
> >> different levels of redaction.
> >
> > I think it's entirely sensible to assess demand before investing a lot
> of time in this.  ...  I think the real question on this issue is for
> receivers.  Is there anyone working that side of the equation that would be
> inspired to send some kind of limited feedback report where they send none
> now is they had clearer examples to work from.
>
>
> I should have said "I speculated," I suppose... While listening to
> Autumn I couldn't recall having seen such examples, so I threw the idea
> out there.
>
> Anyway yes, we should be guided by data where we can get it. But if
> we're looking for something better than "anecdata," at the moment I can
> only imagine getting that through a careful survey of a large number of
> non-reporting receivers. And I don't see that happening unless it covers
> a lot more questions than just whether examples of redacted failure
> reports would have changed the decision not to send failure reports...
>
> If there's no sense that it would be useful, no need for further
> discussion.
>
> --S.
>
>
> ___
> 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

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

[Alessandro Vesely]

Hi all,
I'm sorry I didn't queue to talk yesterday.  After so many months without
speaking one word of English, I really didn't feel like...


*Why ARC cannot solve the mailing list problem*
===

Assume all mailing lists in the world duly did ARC.  Somewhat
science-fictitious, given that some of them are not even able to add valid DKIM
signatures.  Let's hypothesize they all did ARC, anyway.  Would the mailing
list problem be solved?  No, because recipients cannot blindly accept DMARC
failures just because there is an ARC-chain claiming authenticity.  Doing so
would completely defeat DMARC, because ARC chains can be forged.

In order to safely override a reject or quarantine policy based on ARC, a
receiver needs a complete list of legitimate mailing lists.  Conversely, having
such a list, a receiver can override DMARC failures also based on DKIM or SPF
authentication.  ARC adds nothing to the mailing list problem.  (However, huge
mailbox providers do have a complete list of legitimate MTAs.  That's where ARC
is useful, AIUI.)


*From rewriting is the real thing*
==

Rewriting From: is the de-facto standard.  In a (science-fictitious) scenario
where all mailing lists rewrite the From: header field, DMARC would just work
smoothly.

Hence, we have to specify an acceptable way to rewrite From:.


I'd have said so.

Best
Ale
-- 


































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