Re: [dmarc-ietf] A-R results for DMARC

[John R Levine]

On Mon, 7 Dec 2020, Murray S. Kucherawy wrote:

The original intent back in RFC 5451 was to relay only those details that
an MUA might care about, such as the DKIM result (so you can display
something representing a "pass" or "fail" on a message) and maybe the
domain name found in a passing signature (an early shot at caring about
alignment when rendering a message). ...


I suppose but 5451 also says it might be useful to message filters.


So that ship has sailed, meaning yes, we could register these too if
they're going to be useful to downstream agents.  Though for that matter,
you could just start using them even without registering them to see if it
would be helpful, because 8601 allows for local conventions (the
tried-and-true "ignore what you don't know" thing that DKIM introduced).


Sure, I can write the code to stick them in but it would be nice to have 
some expectation that I'm not going to collide with something else, or 
other people use different tags for the same thine.


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] A-R results for DMARC

[Murray S. Kucherawy]

On Mon, Dec 7, 2020 at 7:16 PM John Levine  wrote:

> I have never understood all of the indirection involved in defining
> stuff for A-R but I'm hoping Murray can help out.
>

What I think you're referring to is a distinction between the way we seem
to want to use A-R now versus how it was originally intended.

The original intent back in RFC 5451 was to relay only those details that
an MUA might care about, such as the DKIM result (so you can display
something representing a "pass" or "fail" on a message) and maybe the
domain name found in a passing signature (an early shot at caring about
alignment when rendering a message).  The community seems to have shifted
toward that being too strict and instead wanting to use it as a transport
mechanism for any evaluation detail about the message that might be
interesting to the MUA or any other downstream agent once it reaches its
final ADMD.  RFC 8601, for instance, registered "header.a" and "header.s",
DKIM properties that are almost certainly of no interest to MUAs.

So that ship has sailed, meaning yes, we could register these too if
they're going to be useful to downstream agents.  Though for that matter,
you could just start using them even without registering them to see if it
would be helpful, because 8601 allows for local conventions (the
tried-and-true "ignore what you don't know" thing that DKIM introduced).

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

Re: [dmarc-ietf] Ticket #1 - SPF alignment

[Douglas Foster]

Is there an identifiable attack vector which can be based on using the
(forward confirmed) HELO name for SPF pass?

If not, why change?



On Mon, Dec 7, 2020, 6:09 AM Dotzero  wrote:

>
>
> On Mon, Dec 7, 2020 at 2:13 AM Murray S. Kucherawy 
> wrote:
>
>> On Tue, Dec 1, 2020 at 2:17 PM John R Levine  wrote:
>>
>>> We would like to close this ticket by Dec 15, two weeks from now, so
>>> short
>>> trenchant comments are welcome.
>>>
>>> Ticket #1 is about SPF alignment.  We need to replace references to 4408
>>> with 7408, ando clarify what if anything we do with SPF HELO checks if
>>> the MAIL FROM is null.  One possibility is to say only MAIL FROM SPF
>>> counts, if you want to align your bounces, sign them.  The other is to
>>> explicitly say that HELO alignment is OK on bounces.
>>>
>>
>> I have a slight preference for the first option.  HELO is too arbitrary
>> in the protocol for me to put much value in using it in any of these
>> systems.
>>
>> -MSK
>>
>
> +1
>
> Michael Hammer
> ___
> 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] A-R results for DMARC

[Seth Blank]

Please open a ticket, agreed that standardization here is a good thing.

I have some further thoughts as an individual once the ticket is opened.

On Mon, Dec 7, 2020 at 19:16 John Levine  wrote:

> I don't think there is a ticket for this, but it would be nice if
> there were standard ways to put a few more items into the DMARC part
> of an A-R header, in particular the p= and pct= values and the
> location of the policy record if it's not the same as header.from.
>
> None of the existing ptypes really apply here (in particular "policy" is
> for local policy, not a policy you found somewhere else.)  Perhaps call
> it polrec for policy record and add polrec.p polrec.pct and polrec.domain.
>
> I have never understood all of the indirection involved in defining
> stuff for A-R but I'm hoping Murray can help out.
>
> R's,
> John
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
-- 

*Seth Blank* | VP, Standards and New Technologies
*e:* s...@valimail.com
*p:* 415.273.8818


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] A-R results for DMARC

[John Levine]

I don't think there is a ticket for this, but it would be nice if
there were standard ways to put a few more items into the DMARC part
of an A-R header, in particular the p= and pct= values and the
location of the policy record if it's not the same as header.from.

None of the existing ptypes really apply here (in particular "policy" is
for local policy, not a policy you found somewhere else.)  Perhaps call
it polrec for policy record and add polrec.p polrec.pct and polrec.domain.

I have never understood all of the indirection involved in defining
stuff for A-R but I'm hoping Murray can help out.

R's,
John

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

Re: [dmarc-ietf] Ticket #39 - remove p=quarantine

[John Levine]

In article  
you write:
>Anyways, +1 to keeping p=quarantine as a concept, but willing to go along
>with the consensus on naming.

I'm modestly in favor of keeping p=quarantine as a feature but utterly opposed
to changing the keywords such as "p=quarantine" in the DMARC record.

It's fine to improve the text in the RFC that describes what they mean but let
us please not make gratuitously incompatible changes.

R's,
John

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

Re: [dmarc-ietf] not ADSP, was is DMARC informational?

[John R Levine]

On Mon, 7 Dec 2020, Jim Fenton wrote:
Agree, the reporting is great. But so much of the marketing/mandates I see 
around DMARC doesn’t tell domain owners to turn on reporting first to see 
what’s broken, it tells them to publish a DMARC p=reject policy because they 
have a security vulnerability if they don’t. If the guidance around DMARC was 
to publish a p=reject policy only “if it’s safe to do so” (meaning mostly for 
transactional domains), I’d be a lot happier with it.


Yes indeed.  It's pretty much the same issue as people who have DMARC on 
a checklist so they publish an SPF record and p=reject, check the item, 
and I'm stuck with mail that disappears when I forward it to its intended 
recipient.


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] not ADSP, was is DMARC informational?

[Tim Wicinski]

There are a number of open issues and you open more.
https://trac.ietf.org/trac/dmarc/report/1

I think it is being serialized for lack of people and also WG energy.

tim

On Mon, Dec 7, 2020 at 8:20 PM Michael Thomas  wrote:

>
> On 12/7/20 5:15 PM, Tim Wicinski wrote:
>
>
> A good section of our charter is collection Operational experiences. Doing
> an Operational BCP on DMARC based on data collected is what the WG should
> do after DMARC-bis.
>
> I guess I don't understand why this should be serialized. When I read over
> DMARC I completely recognized ADSP/SSP with the addition of SPF policy and
> reporting. I wouldn't expect a whole lot of changes beyond wordsmithing and
> some nits around the edges. If this is really because large mail providers
> have started using p=reject, that seems to be pushing off the actual
> payload way down the line. Standards track is not going to change this
> much, IMO.
>
> Mike
>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] not ADSP, was is DMARC informational?

[Michael Thomas]

On 12/7/20 5:15 PM, Tim Wicinski wrote:


A good section of our charter is collection Operational experiences. 
Doing an Operational BCP on DMARC based on data collected is what the 
WG should do after DMARC-bis.


I guess I don't understand why this should be serialized. When I read 
over DMARC I completely recognized ADSP/SSP with the addition of SPF 
policy and reporting. I wouldn't expect a whole lot of changes beyond 
wordsmithing and some nits around the edges. If this is really because 
large mail providers have started using p=reject, that seems to be 
pushing off the actual payload way down the line. Standards track is not 
going to change this much, IMO.


Mike


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

Re: [dmarc-ietf] not ADSP, was is DMARC informational?

[Tim Wicinski]

A good section of our charter is collection Operational experiences. Doing
an Operational BCP on DMARC based on data collected is what the WG should
do after DMARC-bis.

tim

On Mon, Dec 7, 2020 at 7:50 PM Michael Thomas  wrote:

>
> On 12/7/20 4:44 PM, Dave Warren wrote:
> > On Sun, Dec 6, 2020, at 22:31, Michael Thomas wrote:
> >> there are clearly many use cases where that isn't a problem -- like bank
> >> transactional mail -- and ADSP was just fine for that.
> > There were still surprises to be had here. I still, to this day, find
> mail direct from various senders that are wanted by the recipient but that
> fails SPF without forwarding (with a -all) or hits a dmarc=reject. I
> quarantine such for review and release to users as needed.
> >
> > Obviously lots is spam, or forwarding that broke SPF or whatever, but
> just as often it is a small piece of a big company doing something without
> fully understanding how modern email works. Oddly it is often security
> sensitive stuff, not crazy long ago it was Facebook password resets, often
> it is 2FA codes (which are probably going through a separate channel to get
> immediate delivery without risking backlog?), and other reasonably
> important things from parts of the company that I would expect to be at
> least moderately aware of the email security world.
> >
> > I agree that ADSP was theoretically fine for this type of use, but in
> practice, DMARC's feedback simplifies things a lot when a client complains
> their outbound mail isn't making it and we can quickly see what is being
> rejected.
> >
> > it is an imperfect world.
>
> I fear that DMARC's reporting only confirmed the obvious: this is hard.
> It gave numbers to anecdotes. That's really useful, don't get me wrong.
> Hopefully it can be used to suss out how to demarcate the long tail of
> don't care use cases.
>
> Mike
>
> ___
> 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] not ADSP, was is DMARC informational?

[Michael Thomas]

On 12/7/20 4:44 PM, Dave Warren wrote:

On Sun, Dec 6, 2020, at 22:31, Michael Thomas wrote:

there are clearly many use cases where that isn't a problem -- like bank
transactional mail -- and ADSP was just fine for that.

There were still surprises to be had here. I still, to this day, find mail 
direct from various senders that are wanted by the recipient but that fails SPF 
without forwarding (with a -all) or hits a dmarc=reject. I quarantine such for 
review and release to users as needed.

Obviously lots is spam, or forwarding that broke SPF or whatever, but just as 
often it is a small piece of a big company doing something without fully 
understanding how modern email works. Oddly it is often security sensitive 
stuff, not crazy long ago it was Facebook password resets, often it is 2FA 
codes (which are probably going through a separate channel to get immediate 
delivery without risking backlog?), and other reasonably important things from 
parts of the company that I would expect to be at least moderately aware of the 
email security world.

I agree that ADSP was theoretically fine for this type of use, but in practice, 
DMARC's feedback simplifies things a lot when a client complains their outbound 
mail isn't making it and we can quickly see what is being rejected.

it is an imperfect world.


I fear that DMARC's reporting only confirmed the obvious: this is hard. 
It gave numbers to anecdotes. That's really useful, don't get me wrong. 
Hopefully it can be used to suss out how to demarcate the long tail of 
don't care use cases.


Mike

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

Re: [dmarc-ietf] not ADSP, was is DMARC informational?

[Dave Warren]

On Sun, Dec 6, 2020, at 22:31, Michael Thomas wrote:
> there are clearly many use cases where that isn't a problem -- like bank 
> transactional mail -- and ADSP was just fine for that.

There were still surprises to be had here. I still, to this day, find mail 
direct from various senders that are wanted by the recipient but that fails SPF 
without forwarding (with a -all) or hits a dmarc=reject. I quarantine such for 
review and release to users as needed.

Obviously lots is spam, or forwarding that broke SPF or whatever, but just as 
often it is a small piece of a big company doing something without fully 
understanding how modern email works. Oddly it is often security sensitive 
stuff, not crazy long ago it was Facebook password resets, often it is 2FA 
codes (which are probably going through a separate channel to get immediate 
delivery without risking backlog?), and other reasonably important things from 
parts of the company that I would expect to be at least moderately aware of the 
email security world.

I agree that ADSP was theoretically fine for this type of use, but in practice, 
DMARC's feedback simplifies things a lot when a client complains their outbound 
mail isn't making it and we can quickly see what is being rejected.

it is an imperfect world.

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

Re: [dmarc-ietf] not ADSP, was is DMARC informational?

[Jim Fenton]

On 6 Dec 2020, at 21:18, John Levine wrote:

In article 
 
you write:



As I recall, people took a run at trying ADSP and it was largely
unsuccessful.  I recall at least Yahoo, PayPal, and Google trying it 
but
finding that it interfered with their employees' participation in 
lists, so
they each invented new domains for their employees to use as separate 
from

their operational public services.  This basically led to its demise.


IIRC, Yahoo! And Google had separate domains for their employees well 
before ADSP. Which makes sense, because you want to differentiate your 
employees from your customers. Although I’m not sure that matters 
here.



Among ADSP's shortcomings was that there was no way to test it other
than to turn it on and see how much damage it caused.  The answer was
frequently a lot, so they turned it back off and that was that.

DMARC certainly has its problems but the reporting is great. It makes
the surprises when you turn DMARC on a lot less, at least if your name
is not AOL or Yahoo.


Agree, the reporting is great. But so much of the marketing/mandates I 
see around DMARC doesn’t tell domain owners to turn on reporting first 
to see what’s broken, it tells them to publish a DMARC p=reject policy 
because they have a security vulnerability if they don’t. If the 
guidance around DMARC was to publish a p=reject policy only “if it’s 
safe to do so” (meaning mostly for transactional domains), I’d be a 
lot happier with it.


-Jim

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

Re: [dmarc-ietf] ARC vs reject

[Seth Blank]

On Mon, Dec 7, 2020 at 2:28 PM Kurt Andersen (b)  wrote:

> On Sun, Dec 6, 2020 at 10:46 AM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>>
>> I ask the chairs to formally endorse development of an alternative to ARC
>> as an additional approach to the mailing list problem...
>>
>
> So you are asking the WG to go back to our second milestone and put the
> current work on milestone 3 on hold?
>

This thread is now extremely off topic.

As Kurt rightly mentioned, addressing indirect mailflow was a WG milestone
that has been completed. We are now in another phase of work -- driving
DMARC to a standards track document -- which has open tickets and editors
waiting on WG consensus. This conversation around indirect mail streams,
which the chairs had hoped would run its own course, is now counter
productive.

The Chairs are officially calling discussion of indirect mail flows OFF
TOPIC until all open bis tickets in trac are resolved. After all tickets
are resolved, but prior to WGLC on the bis documents, we will return to a
discussion of indirect mail flow and where ARC stands. For now, move on to
open tickets.

Seth, for the Chairs

-- 

*Seth Blank* | VP, Standards and New Technologies
*e:* s...@valimail.com
*p:* 415.273.8818


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] ARC vs reject

[Kurt Andersen (b)]

On Sun, Dec 6, 2020 at 10:46 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

>
> I ask the chairs to formally endorse development of an alternative to ARC
> as an additional approach to the mailing list problem...
>

So you are asking the WG to go back to our second milestone and put the
current work on milestone 3 on hold?

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

Re: [dmarc-ietf] Discussion: Removal of validation for external destinations (Ticket #76)

[Marc Bradshaw]

Removing this opens up the potential for abuse, I don't see the value in 
removing it.

On Sun, 6 Dec 2020, at 11:06 PM, Alessandro Vesely wrote:
> On Sat 05/Dec/2020 14:51:52 +0100 Brotman, Alex wrote:
> > 
> > There's currently a ticket that suggests that the requirement for external 
> > validation be removed.  Today, if example.com has an RUA that points at 
> > example.net, the latter must create a record as such:
> > 
> > example.com._report._dmarc.example.net TXT "v=DMARC1"
> 
> 
> Actually, the record can also be:
> 
> example.com._report._dmarc.example.net TXT "v=DMARC1; 
> rua=updated-addr...@example.net"
> 
> or even, considering a parallel thread:
> 
> example.com._report._dmarc.example.net TXT "v=DMARC1; rua=rep...@example.net, 
> /https://www.example.net/report/";
> 
> 
> That way, external services have the ability to control or suspend  their 
> service.  I think this is an essential requirement.  Let's keep it.
> 
> 
> > The original thought was that a bad actor could overwhelm a target with 
> > unrequested reports.  It seems in reality, most report generators only send 
> > once per day.
> 
> 
> Once-per-day has to be amended.  See ticket #71.
> 
> 
> > Additionally, there appear to be some generators who ignore the absence of 
> > these records.
> 
> 
> Aggregate reports are often tagged as spam anyway, but when sent in violation 
> of the spec such tagging is certainly deserved.
> 
> 
> > https://tools.ietf.org/html/rfc7489#section-7.1
> 
> 
> Why don't you refer to either of the drafts we're editing:
> https://tools.ietf.org/html/draft-ietf-dmarc-aggregate-reporting-00#section-2.1
> https://tools.ietf.org/html/draft-ietf-dmarc-failure-reporting-00#section-3.2
> 
> BTW, this duplication is worth yet another ticket.
> 
> 
> Best
> Ale
> -- 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
> 

--

  Marc Bradshaw
  marcbradshaw.net | @marcbradshaw 

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

Re: [dmarc-ietf] ARC vs reject

[Kurt Andersen (b)]

On Sat, Dec 5, 2020 at 5:21 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> ...much of this is about AOL in particular, and the currently available
> information suggests that AOL is not on board with ARC.
>

I would point you to
https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-22#section-12.2
(note that per normal IETF procedure, section 12 is removed in the
editorial conversion from an I-D to an RFC).

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

Re: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket #56)

[Marc Bradshaw]

There is value in including these in one report, especially where the extended 
property being reported on influences how DMARC is evaluated.

Using ARC as the example, when a p=reject policy was overriden by the receiver 
because of an ARC evaluation, when that data is included in the report the 
indirect mail flow can be clearly seen, which would not be the case if ARC were 
included as a separate report.

This could be included in an  element, or could be included directly 
in the auth_results section of the report, based on an assumption that the 
things being reported SHOULD have an authentication results entry in processed 
mail.


...
...
 (as defined in arc standard) 
 (as defined in foo standard) 


These would be defined in a registry with reference to each standard, and 
parsers would ignore any sections they did not understand.

On Fri, 4 Dec 2020, at 6:43 AM, Alessandro Vesely wrote:
> On Thu 03/Dec/2020 19:54:51 +0100 Brotman, Alex wrote:
> > 
> >> -Original Message-
> >> From: dmarc  On Behalf Of Alessandro Vesely
> >> Sent: Thursday, December 3, 2020 6:24 AM
> >> To: dmarc@ietf.org
> >> Subject: Re: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket 
> >> #56)
> >>
> >> On Wed 02/Dec/2020 20:46:54 +0100 Brotman, Alex wrote:
> >>>
> >>> While this ticket/enhancement specifically mentions ARC, I could
> >>> perhaps see the usefulness in other places.  It seems like it would be
> >>> more beneficial to create a method by which other documents could
> >>> provide XML- based "extensions" to the report.  This would allow
> >>> mechanisms relying on DMARC to independently define their reporting
> >>> schema to be included in DMARC aggregate reports.  Alternately, we could
> >>> focus specifically on ARC, and work to include that in the base XML.
> >>> This means that any later reporting requirements could again require
> >>> changes to the core drafts.>>>
> >>
> >>
> >> Another possibility is for ARC to define its own report format.  Hijacking
> >> rua= targets to send a different kind of report should be allowed.
> >> Otherwise, we could define a new tag, e.g. rue= (e for Extension).>>
> >> In either case, as we're introduce variations in aggregate report content,
> >> we have to devise a method for determining what version/kind of report is 
> >> attached to a given message.>>
> > 
> > We could add an element called "", and we allow ARC or whatever
> > it may be to exist under that element.  The Aggregate Reporting document
> > needs to specify that any extensions are expected to be proper XML, and if
> > there are no extensions, an empty element is sufficient.  We could create a
> > bit more structure as a requirement if we wanted:> 
> > 
> > > standard="ARC_DMARC_REPORTING_EXTENSION_DEFINITION">
> >  ... (as defined in referenced standard)
> >
> > 
> > 
> > If a report parser doesn't know what ARC is (or any of the extensions), it 
> > could skip the processing.  I do understand this means that  
> > element may break existing parsers, even when empty, though, I expect many 
> > of the things we're proposing may fracture the expected XML.
> 
> 
> We can do a better job at producing aggregate reports with an automatically 
> verifiable content.  For example, prepending stuff like this:
> 
> 
> http://www.w3.org/2001/XMLSchema-instance";
> xmlns:dmarc="http://dmarc.org/dmarc-xml/0.1";
> xs:schemaLocation="http://dmarc.org/dmarc-xml/0.1 rua.xsd">
> 
> ...
> 
> (Perhaps something better than "http://dmarc.org/dmarc-xml/0.1"; for the 
> version)
> 
> But then, would the  imply dmarc-xml grammar should be upgraded 
> every time ARC (or whatever) is upgraded?
> 
> Separate reports sounds simpler.
> 
> 
> Best
> Ale
> -- 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
> 

--

  Marc Bradshaw
  marcbradshaw.net | @marcbradshaw 

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

Re: [dmarc-ietf] Ticket #1 - SPF alignment

[John Levine]

In article  
you write:
>> I have a slight preference for the first option.  HELO is too arbitrary in
>> the protocol for me to put much value in using it in any of these systems.
>
>There's a bit of an implementation detail though. If one is relying on an
>encapsulated ck_host() function then you may not know whether it checked
>the HELO or the MAIL FROM. Imposing a requirement like this from DMARC
>seems like it verges on a layering violation.

You should be able to look at the bounce address and if it's null,
skip the SPF check.  No need to peek inside SPF for that.

R's,
John

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

Re: [dmarc-ietf] Ticket #1 - SPF alignment

[Kurt Andersen (b)]

On Sun, Dec 6, 2020 at 11:13 PM Murray S. Kucherawy 
wrote:

> On Tue, Dec 1, 2020 at 2:17 PM John R Levine  wrote:
>
>> We would like to close this ticket by Dec 15, two weeks from now, so
>> short
>> trenchant comments are welcome.
>>
>> Ticket #1 is about SPF alignment.  We need to replace references to 4408
>> with 7408, ando clarify what if anything we do with SPF HELO checks if
>> the MAIL FROM is null.  One possibility is to say only MAIL FROM SPF
>> counts, if you want to align your bounces, sign them.  The other is to
>> explicitly say that HELO alignment is OK on bounces.
>>
>
> I have a slight preference for the first option.  HELO is too arbitrary in
> the protocol for me to put much value in using it in any of these systems.
>

There's a bit of an implementation detail though. If one is relying on an
encapsulated ck_host() function then you may not know whether it checked
the HELO or the MAIL FROM. Imposing a requirement like this from DMARC
seems like it verges on a layering violation.

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

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

[John Levine]

>I don't understand the security or GDPR references.

Well this is amusing. I wondered if anyone had ever implemented some
version of the http reporting in early DMARC drafts, so I set up a new domain
with a server that will accept POST or PUT requests and added its URI to my
DMARC records.

I didn't get any of those (the POSTs below are not to the right URI)
but it's impressive how fast Russian bots started to probe it, within
hours.

This is not a reason to avoid https reporting. Every web site gets
probed like this and so long as your web server rejects unknown URIs,
they're harmless. After all, my e-mail reporting addresses get a
certain amount of spam, too.

R's,
John



139.162.113.204 dmreport.abuse.net - [07/Dec/2020:03:15:11 -0500] "GET / 
HTTP/1.1" 404 719 "HTTP Banner Detection (https://security.ipip.net)"
192.241.209.169 dmreport.abuse.net - [07/Dec/2020:05:26:29 -0500] "GET / 
HTTP/1.1" 404 719 "Mozilla/5.0 zgrab/0.x"
192.241.237.68 dmreport.abuse.net - [07/Dec/2020:05:49:18 -0500] "GET 
/owa/auth/logon.aspx?url=https%3a%2f%2f1%2fecp%2f HTTP/1.1" 404 786 
"Mozilla/5.0 zgrab/0.x"
91.241.19.84 dmreport.abuse.net - [07/Dec/2020:06:44:01 -0500] "POST 
/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 823 
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like 
Gecko) Chrome/78.0.3904.108 Safari/537.36"
91.241.19.84 dmreport.abuse.net - [07/Dec/2020:06:44:01 -0500] "POST 
/api/jsonws/invoke HTTP/1.1" 404 757 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) 
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36"
91.241.19.84 dmreport.abuse.net - [07/Dec/2020:06:44:07 -0500] "GET 
/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 823 
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like 
Gecko) Chrome/78.0.3904.108 Safari/537.36"
91.241.19.84 dmreport.abuse.net - [07/Dec/2020:06:44:07 -0500] "GET 
/index.php?s=/Index/\\think\\app/invokefunction&function=call_user_func_array&vars[0]=md5&vars[1][]=HelloThinkPHP21
 HTTP/1.1" 404 858 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) 
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36"
91.241.19.84 dmreport.abuse.net - [07/Dec/2020:06:44:09 -0500] "GET 
/?XDEBUG_SESSION_START=phpstorm HTTP/1.1" 404 753 "Mozilla/5.0 (Windows NT 
10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 
Safari/537.36"
91.241.19.84 dmreport.abuse.net - [07/Dec/2020:06:44:11 -0500] "POST 
/mifs/.;/services/LogService HTTP/1.1" 404 779 "Mozilla/5.0 (Windows NT 10.0; 
Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 
Safari/537.36"
91.241.19.84 dmreport.abuse.net - [07/Dec/2020:06:44:12 -0500] "GET 
/wp-content/plugins/wp-file-manager/readme.txt HTTP/1.1" 404 813 "Mozilla/5.0 
(Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) 
Chrome/78.0.3904.108 Safari/537.36"
193.118.53.202 dmreport.abuse.net - [07/Dec/2020:11:45:14 -0500] "GET / 
HTTP/1.1" 404 719 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 
(KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36"
67.205.149.169 dmreport.abuse.net - [07/Dec/2020:12:50:40 -0500] "GET / 
HTTP/1.0" 400 362 "-"
83.97.20.31 dmreport.abuse.net - [07/Dec/2020:14:46:30 -0500] "GET / HTTP/1.1" 
404 723 "-"
185.141.63.14 dmreport.abuse.net - [07/Dec/2020:14:47:37 -0500] "GET / 
HTTP/1.1" 404 723 "libwww-perl/6.49"

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

Re: [dmarc-ietf] ARC vs reject

[Michael Thomas]

On 12/7/20 1:00 PM, Tim Wicinski wrote:



On Mon, Dec 7, 2020 at 2:26 PM Michael Thomas > wrote:



This is why we need actual numbers instead of anecdotes about the
long
tail. We know that there is no silver bullet. Mailing lists who are
configured in a way that causes their traffic to not get delivered
can
be configured in a way that will. It's not our problem.


Are you talking about integrating ARC?  Then you are correct, operational
data. This is why until that happens, we're not talking about adding 
ARC into

the DMARC flow, and it's why the ARC work is Out Of Scope in this WG.




Do you mean that it is out of scope wrt DMARC? I can understand that 
since it's an experiment. It would probably be best documented in the 
context of ARC itself and dealt with if it ever becomes standards track. 
In the mean time, reject should mean reject.


As it turns out, rfc 7489 does seem to document the issue though.

Mike

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

Re: [dmarc-ietf] ARC vs reject

[Tim Wicinski]

On Mon, Dec 7, 2020 at 2:26 PM Michael Thomas  wrote:

>
> On 12/7/20 11:19 AM, John Levine wrote:
> > In article  you write:
> >> Compared with the use of "l=" tag (Section 8.2 of [RFC6376]), the
> >> fact that footers are written in plain text ...
> > They are?  Some are, some are added as MIME parts.
> >
> > We really need to keep in mind that there is a lot of list management
> > software with a vast array of configuration options.
>
> This is why we need actual numbers instead of anecdotes about the long
> tail. We know that there is no silver bullet. Mailing lists who are
> configured in a way that causes their traffic to not get delivered can
> be configured in a way that will. It's not our problem.
>
>
Are you talking about integrating ARC?  Then you are correct, operational
data.  This is why until that happens, we're not talking about adding ARC
into
the DMARC flow, and it's why the ARC work is Out Of Scope in this WG.

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

Re: [dmarc-ietf] Ticket #28 - Failure report mail loops

[John Levine]

In article <0408ae98-e1c1-71fe-fdd4-8bc7a7c15...@tana.it> you write:
>We would like to close this ticket by Dec 18, two weeks from now, so please 
>get 
>on it.
>
>The ticket originated from John's comment, in May 2019:
>
> Apropos recent discussions, we could recommend that failure reports be
> rate limited per recipient both to break loops and to deter indirect
> mail bombing.

>4.  Some explicit loop prevention specification may be added.  For example:
>4.1.  send reports from a subdomain having a DMARC record without ruf=, or
>4.2.  never send failure reports about failed reports.

4.0.  Make your failure reports DMARC aligned.

Looking at the failure reports in my file, all of the messages
actually are aligned, so this is a solved problem.

Other than the the possibility of indirect mail bombing via failure
reports, which I believe has never happened, I don't understand what
problem we are trying to solve here.

Since the original comment was mine, I would suggest closing this one
as nothing to fix.

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

Re: [dmarc-ietf] Ticket #28 - Failure report mail loops

[John Levine]

In article ,
Alessandro Vesely   wrote:
>> 4.  Some explicit loop prevention specification may be added.  For example:
>>> 4.1.  send reports from a subdomain having a DMARC record without ruf=, or
>>> 4.2.  never send failure reports about failed reports.
>> 
>> The latter, which is consistent with SMTP never generating a bounce about a
>> bounce.
>
>However, SMTP has an operational definition of bounce, MAIL FROM:<>.  Should 
>we 
>take the same stance?  That is, send failure reports with an empty bounce 
>address and never send failure reports to bounces or failure reports?

We're talking about DMARC failures, not SMTP delivery failures. I
don't see what the latter has to do with the former.

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] ARC vs reject

[Michael Thomas]

On 12/7/20 11:19 AM, John Levine wrote:

In article  you write:

Compared with the use of "l=" tag (Section 8.2 of [RFC6376]), the
fact that footers are written in plain text ...

They are?  Some are, some are added as MIME parts.

We really need to keep in mind that there is a lot of list management
software with a vast array of configuration options.


This is why we need actual numbers instead of anecdotes about the long 
tail. We know that there is no silver bullet. Mailing lists who are 
configured in a way that causes their traffic to not get delivered can 
be configured in a way that will. It's not our problem.


Mike

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

Re: [dmarc-ietf] ARC vs reject

[John Levine]

In article  you write:
>Compared with the use of "l=" tag (Section 8.2 of [RFC6376]), the
>fact that footers are written in plain text ...

They are?  Some are, some are added as MIME parts.

We really need to keep in mind that there is a lot of list management
software with a vast array of configuration options.

R's,
John

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

Re: [dmarc-ietf] ARC vs reject

[Michael Thomas]

On 12/7/20 10:33 AM, Murray S. Kucherawy wrote:
On Mon, Dec 7, 2020 at 8:59 AM Michael Thomas > wrote:


Btw, what is PSD?


A working group document: 
https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/ 




Oh that. I figured out the acronym and obviously immediately forgot 
about it. Graci.


Mike

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

Re: [dmarc-ietf] ARC vs reject

[Seth Blank]

On Mon, Dec 7, 2020 at 10:34 AM Murray S. Kucherawy 
wrote:

> On Mon, Dec 7, 2020 at 4:05 AM Dotzero  wrote:
>
>> I've asked here and in other places that validators/receivers consuming
>> ARC headers provide data regarding the results of such consumption. To date
>> we have not seen any data provided by participants in the ARC experiment.
>> It may be that ARC is a useful standard or it may not be. So far I'm seeing
>> a lot of supposition and speculation but no useful data for evaluation.
>>
>
> I wonder if we might ask our compatriots at M3AAWG if they might be
> willing or able to undertake a data collection project in this area.  Most
> of the ARC proponents are also participants there.
>

This data collection is taking place at M3AAWG; Kurt Andersen is leading,
with myself and Todd Herr supporting. However, this got slowed dramatically
due to COVID-- we won't realistically see data that's useful to this
working group for another few months. In the meantime, ARC discussions
continue between many international receivers, and the DMARC WG chairs are
being kept in the loop. Once there's something material to bring back, that
will happen publicly.



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


-- 

*Seth Blank* | VP, Standards and New Technologies
*e:* s...@valimail.com
*p:* 415.273.8818


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] ARC vs reject

[Michael Thomas]

On 12/7/20 10:32 AM, Murray S. Kucherawy wrote:
On Mon, Dec 7, 2020 at 4:05 AM Dotzero > wrote:


I've asked here and in other places that validators/receivers
consuming ARC headers provide data regarding the results of such
consumption. To date we have not seen any data provided by
participants in the ARC experiment. It may be that ARC is a useful
standard or it may not be. So far I'm seeing a lot of supposition
and speculation but no useful data for evaluation.


I wonder if we might ask our compatriots at M3AAWG if they might be 
willing or able to undertake a data collection project in this area.  
Most of the ARC proponents are also participants there.


What I'm particularly curious about is what the difference is with the 
arc auth-res on the filtering decisions. Why would a decision turn on 
that result? That's something I've been trying to understand, but 
haven't managed to get. Naively it seems like it could be useful, but is 
it in reality? Like can somebody show some A-B kind of examples, and 
whether or not they are statistical noise?


Mike

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

Re: [dmarc-ietf] ARC vs reject

[Murray S. Kucherawy]

On Mon, Dec 7, 2020 at 8:59 AM Michael Thomas  wrote:

> Btw, what is PSD?
>

A working group document:
https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/

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

Re: [dmarc-ietf] ARC vs reject

[Murray S. Kucherawy]

On Mon, Dec 7, 2020 at 4:05 AM Dotzero  wrote:

> I've asked here and in other places that validators/receivers consuming
> ARC headers provide data regarding the results of such consumption. To date
> we have not seen any data provided by participants in the ARC experiment.
> It may be that ARC is a useful standard or it may not be. So far I'm seeing
> a lot of supposition and speculation but no useful data for evaluation.
>

I wonder if we might ask our compatriots at M3AAWG if they might be willing
or able to undertake a data collection project in this area.  Most of the
ARC proponents are also participants there.

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

Re: [dmarc-ietf] ARC vs reject

[Michael Thomas]

On 12/6/20 9:30 PM, Murray S. Kucherawy wrote:
On Sun, Dec 6, 2020 at 9:24 PM Michael Thomas > wrote:


An idea that i've been rolling around in my head is that the MLM
could give a sed-like script to rollback the changes. since they
know their modifications, they can obviously express how to
unmodify them. it may have less issue with the mime hackery you
were thinking about.


You'd need a way to assert, and then evaluate, that something 
equivalent to "s/.*/spam/g" is a transformation you're not willing to 
reverse and say "yep, we're good."  I don't know how you'd go about 
automating that.


But as far as your point about spam vectors it is surely just as
true about ARC, right? at least with recovering the original text
i have the ability to remove all of the transforms and deliver the
original text.  ARC not so much. it's all or nothing on the trust
front.

But I really think the key thing about all of this is figuring out
what defines success. That is the most important thing by far.

I think ARC, like PSD, is meant to run for a while and see what we've 
learned from it.  Maybe it's the silver bullet, or maybe it's 
ineffective complexity.  That should be part of the experiment's 
definition; Section 11 of the ARC RFC does try to capture all of that.



Btw, what is PSD?

Mike

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

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

[John R Levine]

poorly defined http report which we took out.  I propose we add back
https reporting similar to that for mta-sts, with a POST of the gzipped report
to the HTTPS URI.


Was this requested by someone?


I don't recall a strong security and privacy concerns discussion around
HTTP(S) reporting. Presumably the report contents are protected in transit
but to what extent is access by arbitrary parties an issue. Notwithstanding
that things like GDPR are political issues, they are worth noting as a real
life operational consideration.


The original motivation was performance, since uploading a big file via 
https is a lot faster than base64 encoding it and relaying it by mail.


I don't understand the security or GDPR references.  For one thing, these 
are aggregate reports which generally don't have any PII.  For another, 
https reporting would be considerably more secure than mail reporting. 
The report goes via an encrypted channel directly to the target server 
which is identified by its ssl certificate.  There's no relaying through 
intermediate servers.  If the report can't be delivered, the upload just 
fails and there's no possibility of it being diverted by spam filters or 
bouncing into some random admin mailbox.


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 vs reject

[Michael Thomas]

On 12/7/20 1:35 AM, Alessandro Vesely wrote:

On Sun 06/Dec/2020 19:47:24 +0100 Michael Thomas wrote:
It seems a lot simpler for the originating domain to just be explicit 
about how they feel about transformations by intermediaries. It's not 
like another short ascii string is going to break the bank.



A stated policy is certainly more explicit about the intent. However, 
it is subject to receivers interpretation and I-dont-care syndrome.



Yes, the best the sending domain can ever do is state their wishes. But 
they should be able to state their wishes concisely. We're only talking 
about code points here. As a standards organization, we shouldn't be 
hung up about whether people will care. That is extremely defeatist and 
begs the question of why bother doing anything.


Mike

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

Re: [dmarc-ietf] DMARC and ARC

[Douglas Foster]

Thanks for engaging Murray.

On the usefulness of source blacklisting:

I have been using the model I described for about a year.I have two
categories of mailers that account for nearly all of my spam:
 spamer-owned infrastructure which sends direct, and email service
providers that accept all customers, including criminals.   ESP messages
will arrive SPF-aligned with the ESP domain, the From address indicates the
client, and DKIM signing is used when necessary for DMARC compliance.

I don't think I have seen any problems with infected servers or even
infected accounts from trusted sources, which is surprising.   Compliments
to GMail that the worst that I get from them is unwanted-but-persistent
advertising.

Our employee base is measured in 4 digits, not 6, so our volume is smaller
than many, and my desired-sender list is correspondingly small.   That has
meant that I have not had false positives with blacklisting.

When a confirmed spam is received from spam infrastructure, the best
defense is to blacklist the IP, the host domain, and the address domains
(unless one of these has been spoofed.)In practice, this is tedious to
do consistently.   Blocking on server domain has proved pretty effective.
 When blocking on IP, we often block a subnet.   Depending how quickly we
identify the spam source, the message history sometimes provides a good
outline of the boundaries of the spam infrastructure.   Bottom line:
 spammer domains do change frequently, and spammers often have a bunch of
servers.  But their servers do not actually change very much.   Obviously,
this means I have not yet been attacked by a thousand-member bot-net.

For spam received from ESPs, blocking on the From address works, because
the ESP does verify the client identity and does not allow clients to spoof
each other.   They just don't vet client integrity.So I classify
messages arriving from the ESP into known-bad=block, known-good=allow, and
unknown=quarantine.   Forwarded messages will typically rewrite the SMTP
domain for SPF compliance.   This means that I no longer know that the
unclassified From address is from the untrusted ESP and therefore needs to
be quarantined.DMARC is a great solution for authorizing ESPs to send
direct messages on behalf of a domain, because SPF did not work well for
those messages.   It is not a perfect solution for forwarded mail because
even unmodified messages are subjected to data loss during forwarding.

On Accountability:

A message from A to B to C to Gmail does not mean that Gmail has a
relationship with A.Gmail is acting as your agent, and it does a pretty
good job of protecting you.A to B to C do have a relationship with each
other, or one of them would have been bypassed.For legitimate senders,
I expect that the organizational hops will be at most two:the source
domain, and the outbound email filtering service used by the source domain.

Mailing lists should be the cleanest traffic on the internet, because it
should be a small matter for the list to verify sources and minimize risk
by rejecting even slightly-doubtful messages.Yet we have had exchanges
about how mailing list do not want to sign messages because they think
it will make them accountable for what they forward.   They are accountable
for what they forward, with or without DKIM.

Auto-forwarding operations are much more problematic because they have
strong incentives to minimize false positives.   They are still
accountable, but they will be perceived by recipient as unreliable - the
same way that I handle my problem ESPs.

New vs Existing messages:

For these purposes, mailing list output is only a new message if the
mailing list is the only party responsible for its content.  I am focused
on identifying malicious and unwanted message sources, and the mailing list
is asserting that it is not the originating source.

DF

--


On Mon, Dec 7, 2020 at 12:15 AM Murray S. Kucherawy 
wrote:

> On Fri, Dec 4, 2020 at 7:58 PM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> First, lets begin with the obvious:   malicious messages come from
>> enterprises that are in the malicious message business.   They rarely send
>> just one message, and their content changes continually.   Therefore, my
>> priority is to block malicious sources.   Messages that are correctly
>> blocked on content, rather than source, are the canary-in-the-mine which
>> warns me that my sender blocks need to be tightened.
>>
>
> I was under the impression from my work in the anti-spam world that
> sources also change.  It's trivial to come from a new IP address or sign
> with a new domain name when I think you're blocking me.  Thus, negative
> reputations are generally not useful to accumulate long term.  On the
> contrary, the thing that's mostly reliable is static sources that have good
> reputations, because they tend to remain (mostly) static, and they work to
> preserve their reputations.  I tend to give them prefere

Re: [dmarc-ietf] ARC vs reject

[Dotzero]

On Mon, Dec 7, 2020 at 12:30 AM Murray S. Kucherawy 
wrote:

> On Sun, Dec 6, 2020 at 9:24 PM Michael Thomas  wrote:
>
>> An idea that i've been rolling around in my head is that the MLM could
>> give a sed-like script to rollback the changes. since they know their
>> modifications, they can obviously express how to unmodify them. it may have
>> less issue with the mime hackery you were thinking about.
>>
>
> You'd need a way to assert, and then evaluate, that something equivalent
> to "s/.*/spam/g" is a transformation you're not willing to reverse and say
> "yep, we're good."  I don't know how you'd go about automating that.
>
>> But as far as your point about spam vectors it is surely just as true
>> about ARC, right? at least with recovering the original text i have the
>> ability to remove all of the transforms and deliver the original text.  ARC
>> not so much. it's all or nothing on the trust front.
>>
>> But I really think the key thing about all of this is figuring out what
>> defines success. That is the most important thing by far.
>>
> I think ARC, like PSD, is meant to run for a while and see what we've
> learned from it.  Maybe it's the silver bullet, or maybe it's ineffective
> complexity.  That should be part of the experiment's definition; Section 11
> of the ARC RFC does try to capture all of that.
>

I've asked here and in other places that validators/receivers consuming ARC
headers provide data regarding the results of such consumption. To date we
have not seen any data provided by participants in the ARC experiment. It
may be that ARC is a useful standard or it may not be. So far I'm seeing a
lot of supposition and speculation but no useful data for evaluation.

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

Re: [dmarc-ietf] DMARC and ARC

[Dotzero]

On Mon, Dec 7, 2020 at 12:15 AM Murray S. Kucherawy 
wrote:

> On Fri, Dec 4, 2020 at 7:58 PM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> First, lets begin with the obvious:   malicious messages come from
>> enterprises that are in the malicious message business.   They rarely send
>> just one message, and their content changes continually.   Therefore, my
>> priority is to block malicious sources.   Messages that are correctly
>> blocked on content, rather than source, are the canary-in-the-mine which
>> warns me that my sender blocks need to be tightened.
>>
>
> I was under the impression from my work in the anti-spam world that
> sources also change.  It's trivial to come from a new IP address or sign
> with a new domain name when I think you're blocking me.  Thus, negative
> reputations are generally not useful to accumulate long term.  On the
> contrary, the thing that's mostly reliable is static sources that have good
> reputations, because they tend to remain (mostly) static, and they work to
> preserve their reputations.  I tend to give them preferential treatment.
>
> If a message is not forwarded, every organization involved in its delivery
>> is assumed to have a relationship to the sender and therefore a shared
>> responsibility for the final product.   DMARC, SPF, and many spam filters
>> assume that the adjacent MTA is the only source that needs to be evaluated.
>>
> This seems overly general.  A message going from A to B to C to me here at
> Gmail means Gmail has a relationship with A?
>
> Forwarding introduces an intermediary organization which presumably
>> operates on behalf of the recipient, rather than the sender.   It is not
>> involved in the creation of the message and has no economic relationship
>> with most of the message sources.   More importantly, because it will be
>> forwarding messages from sources with a variety of reputations, the
>> forwarder will be perceived as having a very unreliable reputation –
>> sending both very much unwanted content and very much wanted content from
>> the same or overlapping identifiers.   SPF and DMARC force the forwarder to
>> reliably identify itself, but in this process, they force the forwarder to
>> hide information that the receiving MTA needs for proper message
>> filtering.  This aggravates any effort to filter based on original-source
>> identity.
>>
> I'm also confused here, because it's ambiguous what you mean by
> Forwarder.  Some forwarders simply replace the envelope and send the
> message on its way with no body modifications and only trace header field
> changes.  They don't meet the definition you're describing because no
> details are hidden.  Others, like MLMs, may mutate the message and re-post
> it, but I would argue that's not forwarding, that's a new message; the list
> is the originator.
>

If there were truly a consensus on the list being the originator then the
>From would/should be from the list domain and a lot of the list as
intermediary issues would go away. As past discussions have shown, there is
not such a consensus.

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

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

[Dotzero]

On Mon, Dec 7, 2020 at 2:18 AM Murray S. Kucherawy 
wrote:

> On Tue, Dec 1, 2020 at 2:22 PM John R Levine  wrote:
>
>> We would like to close this ticket by Dec 15, two weeks from now, so
>> short
>> trenchant comments are welcome.
>>
>> Ticket #1 is about https reporting.  Early drafts of the DMARC spec had a
>> poorly defined http report which we took out.  I propose we add back
>> https
>> reporting similar to that for mta-sts, with a POST of the gzipped report
>> to the HTTPS URI.
>>
>
> Was this requested by someone?
>

I don't recall a strong security and privacy concerns discussion around
HTTP(S) reporting. Presumably the report contents are protected in transit
but to what extent is access by arbitrary parties an issue. Notwithstanding
that things like GDPR are political issues, they are worth noting as a real
life operational consideration.

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

Re: [dmarc-ietf] Ticket #28 - Failure report mail loops

[Alessandro Vesely]

On Mon 07/Dec/2020 08:15:57 +0100 Murray S. Kucherawy wrote:

On Fri, Dec 4, 2020 at 3:10 AM Alessandro Vesely  wrote:


We would like to close this ticket by Dec 18, two weeks from now, so
please get
on it.

The ticket originated from John's comment, in May 2019:

 Apropos recent discussions, we could recommend that failure reports be
 rate limited per recipient both to break loops and to deter indirect
 mail bombing.


The current draft discusses the topic toward the end of the introduction
of Section 3, before the first subsection:

An obvious consideration is the denial-of-service attack that can be
perpetrated by an attacker who sends numerous messages purporting to
be from the intended victim Domain Owner but that fail both SPF and
DKIM; this would cause participating Mail Receivers to send failure
reports to the Domain Owner or its delegate in potentially huge
volumes.  Accordingly, participating Mail Receivers are encouraged to
aggregate these reports as much as is practical, using the Incidents
field of the Abuse Reporting Format ([RFC5965]).  Various aggregation
techniques are possible, including the following:

*  only send a report to the first recipient of multi-recipient
   messages;

*  store reports for a period of time before sending them, allowing
   detection, collection, and reporting of like incidents;

*  apply rate limiting, such as a maximum number of reports per
   minute that will be generated (and the remainder discarded).


Some issues the WG may want to consider:

1.  That whole passage should be moved to its own subsection of Section 5,
"Security Considerations".  Only a reference should be left in the intro.



Sure (though it's also fine where it is, IMHO).



Thanks.


2.  In the first *-bullet above, the sense of multi-recipient is 
ambiguous.  An explicit mention of ruf= might help. >

I don't follow.



The two paragraphs before the one I quoted are:

   The destination(s) and nature of the reports are defined by the "ruf"
   and "fo" tags as defined in Section 6.3.

   Where multiple URIs are selected to receive failure reports, the
   report generator MUST make an attempt to deliver to each of them.

They make it clear the sense of "multi-recipient".  However, diagonal readers 
may miss that point, especially if the quoted part is moved.  They would 
attribute the usual meaning to the phrase "multi-recipient messages", which 
makes no sense.




3.  The 2nd and 3rd *-bullets may need expansion.  Propose text in case.


Has anyone complained that they're too terse?

4.  Some explicit loop prevention specification may be added.  For example:

4.1.  send reports from a subdomain having a DMARC record without ruf=, or
4.2.  never send failure reports about failed reports.


The latter, which is consistent with SMTP never generating a bounce about a
bounce.



However, SMTP has an operational definition of bounce, MAIL FROM:<>.  Should we 
take the same stance?  That is, send failure reports with an empty bounce 
address and never send failure reports to bounces or failure reports?



Best
Ale
--
















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

Re: [dmarc-ietf] Ticket #1 - SPF alignment

[Dotzero]

On Mon, Dec 7, 2020 at 2:13 AM Murray S. Kucherawy 
wrote:

> On Tue, Dec 1, 2020 at 2:17 PM John R Levine  wrote:
>
>> We would like to close this ticket by Dec 15, two weeks from now, so
>> short
>> trenchant comments are welcome.
>>
>> Ticket #1 is about SPF alignment.  We need to replace references to 4408
>> with 7408, ando clarify what if anything we do with SPF HELO checks if
>> the MAIL FROM is null.  One possibility is to say only MAIL FROM SPF
>> counts, if you want to align your bounces, sign them.  The other is to
>> explicitly say that HELO alignment is OK on bounces.
>>
>
> I have a slight preference for the first option.  HELO is too arbitrary in
> the protocol for me to put much value in using it in any of these systems.
>
> -MSK
>

+1

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

Re: [dmarc-ietf] ARC vs reject

[Alessandro Vesely]

On Mon 07/Dec/2020 06:05:29 +0100 Murray S. Kucherawy wrote:


A counter-argument I've heard often to the idea of reversible transformations 
is that it can become a spam vector, no different than the argument against 
"l=".



   Compared with the use of "l=" tag (Section 8.2 of [RFC6376]), the
   fact that footers are written in plain text removes the main security
   objection about footer additions.  Namely, footers cannot completely
   replace the original content in the end recipient's eyes by
   exploiting lax HTML parsing in the MUA.

https://tools.ietf.org/html/draft-vesely-dmarc-mlm-transform-00#section-6


Best
Ale
--


















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

Re: [dmarc-ietf] ARC vs reject

[Alessandro Vesely]

On Sun 06/Dec/2020 05:14:18 +0100 John R Levine wrote:

On Sat, 5 Dec 2020, Jim Fenton wrote:

... If the recipient domain accepts modifications by zero-reputation 
intermediaries (because there are so many of them, after all)


I wouldn't call that a reasonable implementation of ARC.  The set of hosts that 
are likely to send you mail with interesting ARC chains is relatively small, 
and I don't think it changes very fast.



Trustworthiness has to account for the probability that a trusted host is 
hacked, even occasionally, so as to spew phishing.  Reasonableness is a number 
in [0, 1].  In the presence of a chain, one must consider the joint probability 
that any intermediary is hacked.


Anyone observed long ARC chains?


I'd certainly be interested in hearing how people plan to compile and maintain 
their lists of ARC-worthy hosts.



There should be a means of exchanging trustworthiness values, so as to build 
the transitivity required to compute the joint probabilities.



Best
Ale
--



















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

Re: [dmarc-ietf] ARC vs reject

[Alessandro Vesely]

On Sun 06/Dec/2020 19:47:24 +0100 Michael Thomas wrote:

On 12/6/20 10:31 AM, Alessandro Vesely wrote:

On Sun 06/Dec/2020 18:01:04 +0100 Michael Thomas wrote:


This actually highlights why my observation is correct. If the intermediary 
showed how to reverse their changes perfectly to be able to validate the 
original signature, it says nothing about whether those changes to be 
delivered to the recipient are acceptable to the originating domain. for the 
case of a bank sending me sensitive mail, the answer is that it is never ok. 
for somebody working on internet standards working on ietf lists, the answer 
is that it is fine. hence trying to get two states of the one "reject" is 
insufficient.


For MLM transformations, this choice can be done by tuning DKIM signatures.  
A bank can choose to sign Sender: field (or lack thereof), or any other 
fields that a MLM has to change, and possibly use simple canonicalization.  
In that conditions, transformation reversion won't work.  It isn't a distinct 
DMARC state, formally. Yet, tuning DKIM signatures allows to harden or weaken 
the given DMARC state.


It seems a lot simpler for the originating domain to just be explicit about how 
they feel about transformations by intermediaries. It's not like another short 
ascii string is going to break the bank.



A stated policy is certainly more explicit about the intent.  However, it is 
subject to receivers interpretation and I-dont-care syndrome.



Best
Ale
--

















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