Re: [dmarc-ietf] DMARC'ed reports, was Forensic report loops are a problem

[Seth Blank]

All-- this thread is unproductive and becoming increasingly combative.

Per our discussion on list decorum and BCP 94 warnings (
https://mailarchive.ietf.org/arch/msg/dmarc/ub6xFEU15w0HAW82ZEnHr_mS180/):

Finally, several members of this working group seem to be very
effective at
antagonizing each other. If a thread is spiralling, and a BCP 94
warning is
given and not heeded, all active participants in the thread after the
warning has been issued will be suspended, even if it’s to tell others
to
respect the warning.

This is an official BCP 94 warning. Everyone please disengage from this
thread.

Seth, as Chair

On Mon, Feb 1, 2021 at 6:37 PM Michael Thomas  wrote:

>
> On 2/1/21 6:31 PM, Douglas Foster wrote:
> > Michael, let it go.
> >
> > If someone stops you to say "your zipper is down", you will not ask
> > them for proof of identity, you will excuse yourself and investigate
> > the problem.   By my reckoning, DMARC reports are a lot like that.
> >
> 1. This is already part of DMARC, though it can use some work
>
> 2. If somebody says your zipper is down, they can clock you when you
> look down to check to steal your wallet. Do not underestimate what
> attackers can do with unauthenticated data.
>
> Mike
>
> ___
> 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] DMARC'ed reports, was Forensic report loops are a problem

[Dave Crocker]

On 2/1/2021 6:33 PM, Michael Thomas wrote:


On 2/1/21 6:24 PM, Dave Crocker wrote:
DMARC has been deployed for 6 or 7 years. Where is this onerous abuse 
on reporting that you feel is inevitable?


Email was around for 20 years until spam became a problem. 


Perhaps you missed the difference in scale between all of the last 5-7 
years versus pretty much all of that 20 years?


In other words, just to keep this simple:  They not in the least 
comparable.  Also, cf, my previous reference to incentives.



We know how this plays out: bad guys do the least amount of work 
possible until they have to react. When it becomes a barrier as 
p=reject does, they take action to protect their turf. Plugging an 
obvious security hole with a well known and trivial set of 
authentication mechanisms to prevent forgery should be the default 
posture. Anybody who is against that needs to explain in depth why it 
should not be the case. Especially since it's part of DMARC now.


Mike, security related specs thumbing their nose at security is a very 
peculiar stance.


Mechanical application of a high-level script, without attending to the 
details that make the script actually work in a specific case, tends to 
lead to counter-productive decisions.  cf my earlier reference to 
barriers to entry and lack of damaging effect.


And flamboyant, aggressively hostile language like 'thumbing their nose' 
is not merely wrong, it is another attempt at gaslighting.  cf my 
earlier reference to hostile work environment.


sigh.

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] DMARC'ed reports, was Forensic report loops are a problem

[Michael Thomas]

On 2/1/21 6:31 PM, Douglas Foster wrote:

Michael, let it go.

If someone stops you to say "your zipper is down", you will not ask 
them for proof of identity, you will excuse yourself and investigate 
the problem.   By my reckoning, DMARC reports are a lot like that.



1. This is already part of DMARC, though it can use some work

2. If somebody says your zipper is down, they can clock you when you 
look down to check to steal your wallet. Do not underestimate what 
attackers can do with unauthenticated data.


Mike

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

Re: [dmarc-ietf] DMARC'ed reports, was Forensic report loops are a problem

[Michael Thomas]

On 2/1/21 6:24 PM, Dave Crocker wrote:

On 2/1/2021 6:13 PM, Michael Thomas wrote:
Because we all know how well unauthenticated data worked out for 
email. I fail to see why anybody would be in favor of digesting 
unauthenticated data when the method of authenticating it is trivial 
and well known. It's an extraordinary claim that needs to be backed 
up. But you don't need to convince me; you need to convince the 
security AD's and cross area reviewers.



DMARC has been deployed for 6 or 7 years.  Where is this onerous abuse 
on reporting that you feel is inevitable?


Email was around for 20 years until spam became a problem. We know how 
this plays out: bad guys do the least amount of work possible until they 
have to react. When it becomes a barrier as p=reject does, they take 
action to protect their turf. Plugging an obvious security hole with a 
well known and trivial set of authentication mechanisms to prevent 
forgery should be the default posture. Anybody who is against that needs 
to explain in depth why it should not be the case. Especially since it's 
part of DMARC now.


Mike, security related specs thumbing their nose at security is a very 
peculiar stance.


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

Re: [dmarc-ietf] DMARC'ed reports, was Forensic report loops are a problem

[Douglas Foster]

Michael, let it go.

If someone stops you to say "your zipper is down", you will not ask them
for proof of identity, you will excuse yourself and investigate the
problem.   By my reckoning, DMARC reports are a lot like that.

Source Alpha says, "Server X is sending unauthenticated mail for Domain
Y."   Several possbilities exist:
- You already distrust information coming from Source Alpha, so you reject
or discard the information.
- You already have enough data to investigate, so you ignore this report.
- You decide to investigate this report, which produces one of three
outcomes:
 - Server X has a problem, and you fix it.
 - Server X is not your server, so you confirm that it is not your
problem.
 - Source Alpha is wrong, so you add a rule to reject or discard future
reports from that source.

I do not see any reason for a DMARC report to flow indirectly, so I would
be suspicious of any reports that appeared to come that way.   This means
all I really need is an SPF PASS.

But I do not need positive identification of the source.

On Mon, Feb 1, 2021 at 9:13 PM Michael Thomas  wrote:

>
> On 2/1/21 6:05 PM, Dave Crocker wrote:
>
> On 2/1/2021 5:58 PM, Michael Thomas wrote:
>
> This, on the other hand, should be measurable. Saying that we should
> ignore authentication requirements should require extraordinary proof that
> it is needed for practical as well as security reasons. The burden of proof
> is on the nay-sayers, especially since it is so trivial to implement these
> days.
>
> Or perhaps:
>
> 1. Barrier to adoption, for something that supposedly needs a lot more
> adoption
>
> 2. Doesn't seem to make much difference.
>
> I'd class those as suggesting rather strongly that the burden is on those
> that want to impose the barrier, rather than those who don't.
>
> The problem with arbitrarily claiming a requirement, without justify it
> carefully and in a balanced matter is that it is, well, arbitrary.
>
> Because we all know how well unauthenticated data worked out for email. I
> fail to see why anybody would be in favor of digesting unauthenticated data
> when the method of authenticating it is trivial and well known. It's an
> extraordinary claim that needs to be backed up. But you don't need to
> convince me; you need to convince the security AD's and cross area
> reviewers.
>
> 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] DMARC'ed reports, was Forensic report loops are a problem

[Dave Crocker]

On 2/1/2021 6:13 PM, Michael Thomas wrote:
Because we all know how well unauthenticated data worked out for 
email. I fail to see why anybody would be in favor of digesting 
unauthenticated data when the method of authenticating it is trivial 
and well known. It's an extraordinary claim that needs to be backed 
up. But you don't need to convince me; you need to convince the 
security AD's and cross area reviewers.



DMARC has been deployed for 6 or 7 years.  Where is this onerous abuse 
on reporting that you feel is inevitable?


I suspect you've assumed the incentives for sending problematic reports 
are the same as the incentives for abuse of generic mail, while they are 
likely quite different.


And no, it isn't trivial at all.  Setting this stuff up properly takes 
skill and effort, which means it's expensive.  And often is fragile.  
Hence the need to attend thoughtfully to pragmatics.


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] DMARC'ed reports, was Forensic report loops are a problem

[Michael Thomas]

On 2/1/21 6:05 PM, Dave Crocker wrote:

On 2/1/2021 5:58 PM, Michael Thomas wrote:
This, on the other hand, should be measurable. Saying that we should 
ignore authentication requirements should require extraordinary proof 
that it is needed for practical as well as security reasons. The 
burden of proof is on the nay-sayers, especially since it is so 
trivial to implement these days. 


Or perhaps:

1. Barrier to adoption, for something that supposedly needs a lot
more adoption

2. Doesn't seem to make much difference.

I'd class those as suggesting rather strongly that the burden is on 
those that want to impose the barrier, rather than those who don't.


The problem with arbitrarily claiming a requirement, without justify 
it carefully and in a balanced matter is that it is, well, arbitrary.



Because we all know how well unauthenticated data worked out for email. 
I fail to see why anybody would be in favor of digesting unauthenticated 
data when the method of authenticating it is trivial and well known. 
It's an extraordinary claim that needs to be backed up. But you don't 
need to convince me; you need to convince the security AD's and cross 
area reviewers.


Mike

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

Re: [dmarc-ietf] DMARC'ed reports, was Forensic report loops are a problem

[Dave Crocker]

On 2/1/2021 5:58 PM, Michael Thomas wrote:
This, on the other hand, should be measurable. Saying that we should 
ignore authentication requirements should require extraordinary proof 
that it is needed for practical as well as security reasons. The 
burden of proof is on the nay-sayers, especially since it is so 
trivial to implement these days. 


Or perhaps:

   1. Barrier to adoption, for something that supposedly needs a lot
   more adoption

   2. Doesn't seem to make much difference.

I'd class those as suggesting rather strongly that the burden is on 
those that want to impose the barrier, rather than those who don't.


The problem with arbitrarily claiming a requirement, without justify it 
carefully and in a balanced matter is that it is, well, arbitrary.


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] DMARC'ed reports, was Forensic report loops are a problem

[Michael Thomas]

On 2/1/21 5:42 PM, Dave Crocker wrote:

On 2/1/2021 5:38 PM, John R Levine wrote:
So I would say that from my small sample, a lot of people have 
figured out how to send aligned reports,


and, to be thorough, some/alot have not.

This, on the other hand, should be measurable. Saying that we should 
ignore authentication requirements should require extraordinary proof 
that it is needed for practical as well as security reasons. The burden 
of proof is on the nay-sayers, especially since it is so trivial to 
implement these days.


Mike

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

Re: [dmarc-ietf] DMARC'ed reports, was Forensic report loops are a problem

[Dave Crocker]

On 2/1/2021 5:38 PM, John R Levine wrote:
So I would say that from my small sample, a lot of people have figured 
out how to send aligned reports,


and, to be thorough, some/alot have not.


either by using their regular signing engines or with an SPF record 
for the host that sends the reports.  On the other hand, for reasons 
we've discussed that are evident to anyone familiar with DMARC, 
there's little reason to worry about fake reports, and authentication 
doesn't help even if there were.


exactly.


If we want to document existing practice, I guess we would say that 
reports should be authenticated and aligned if practical, but it's OK 
to send them if not.

exactly.


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] DMARC'ed reports, was Forensic report loops are a problem

[John R Levine]

On Mon, 1 Feb 2021, Dave Crocker wrote:


On 2/1/2021 3:21 PM, John Levine wrote:

I find it hard to believe that if you are going to enough effort to
maintain the data to create and send reports, you can't figure out how
to install an SPF record for your reporting domain.


Except that the tracking/reporting functions are completely separate from the 
'signing' side of DMARC and could easily be different parts of a company.


I took a look at my aggregate reports.  The DMARC policies of the senders 
are all over the place, some none, a few quarantine, some reject, a few 
small sites (trouble.is, gspam.co.il) have no DMARC record, one has 
neither SPF nor dmarc (itdseciron04.utep.edu). I'd say about 3/4 of the 
reports have DKIM signatures, the rest that have SPF records are aligned.


One was from mailer-dae...@esa1.hc1512-92.c3s2.iphmx.com and 
esa1.hc1512-92.c3s2.iphmx.com indeed has an SPF record.


So I would say that from my small sample, a lot of people have figured out 
how to send aligned reports, either by using their regular signing engines 
or with an SPF record for the host that sends the reports.  On the other 
hand, for reasons we've discussed that are evident to anyone familiar with 
DMARC, there's little reason to worry about fake reports, and 
authentication doesn't help even if there were.


If we want to document existing practice, I guess we would say that 
reports should be authenticated and aligned if practical, but it's OK to 
send them if not.


R's,
John

PS: Does anyone have a contact at antispamcloud.com aka hosteurope.de ? 
They send a lot of impressively broken failure reports.


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

Re: [dmarc-ietf] Forensic report loops are a problem

[Dave Crocker]

On 2/1/2021 4:41 PM, Michael Thomas wrote:
we're supposed to balance purported security considerations with 
pragmatic, real-world operational limits.

cost/benefit.  not an unusual concept.
We have no means of evaluating what you're complaining about. It's a 
Chimera, and a long tailed one at that. 



You're probably right.  Far better to offer requirements as absolutes, 
unanchored by practical concerns.


Except that cost/benefit isn't an illusion or fabrication, but is a 
common practice, so attempting to claim it is otherwise is gaslighting.


And gaslighting is a method that creates a hostile work environment.

It's a shame the working group management hasn't put serious effort into 
curbing such behavior.



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] Forensic report loops are a problem

[Michael Thomas]

On 2/1/21 4:16 PM, Dave Crocker wrote:

On 2/1/2021 4:12 PM, Michael Thomas wrote:
So we're supposed to ignore security considerations because... some 
companies are a mess?



we're supposed to balance purported security considerations with 
pragmatic, real-world operational limits.


cost/benefit.  not an unusual concept.

We have no means of evaluating what you're complaining about. It's a 
Chimera, and a long tailed one at that.


Mike

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

Re: [dmarc-ietf] Forensic report loops are a problem

[Dave Crocker]

On 2/1/2021 4:12 PM, Michael Thomas wrote:
So we're supposed to ignore security considerations because... some 
companies are a mess?



we're supposed to balance purported security considerations with 
pragmatic, real-world operational limits.


cost/benefit.  not an unusual concept.

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] Forensic report loops are a problem

[Michael Thomas]

On 2/1/21 4:05 PM, Dotzero wrote:



On Mon, Feb 1, 2021 at 6:49 PM Michael Thomas > wrote:




On 2/1/21 3:23 PM, Dave Crocker wrote:
> On 2/1/2021 3:21 PM, John Levine wrote:
>> I find it hard to believe that if you are going to enough effort to
>> maintain the data to create and send reports, you can't figure
out how
>> to install an SPF record for your reporting domain.
>
> Except that the tracking/reporting functions are completely
separate
> from the 'signing' side of DMARC and could easily be different
parts
> of a company.
>
> d/
>
It strains credulity that one part of a company would want to send
out
reports when some other can't even sign their email. Both need
access to
the email stream for starters.

It doesn't strain my credulity at all. You are assuming a single mail 
stream. I saw it at my own employer before we got centralized control 
of DNS and implemented email authentication. I actually know of one 
company where several hundred thousand dollars of marketing emails 
ended up not getting through because a marketer thought they could 
evade corporate policy and the ESP gladly took the money even though 
the mail was getting rejected. It's a crazy world out there.



So we're supposed to ignore security considerations because... some 
companies are a mess? That's what this really boils down to. If we're 
writing specs for the least common denominator we might just as well 
stop. But we're not, nor have we ever.


Mike

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

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

[Douglas Foster]

I think I finally understand the complexities of this issue.   SPF is two
different validations, largely unrelated.

Test One:
A connection comes in and a server asserts a HELO name.   Before
proceeding, the recipient was to check if the HELO name is plausible or
fraudulent.One way to do this would be to forward-confirm the HELO DNS
name to the source IP.  An alternate method is to use SPF to see if the SPF
policy says that the HELO domain can send from the Source IP.   I do not
understand why the domain owner would be able to configure the SPF policy
but not the host name in DNS.   Perhaps for organizations with 1000s of
servers, creating a DNS entry for each machine seemed onerous.   In
practice, the large organizations do have DNS entries for each server, and
they encourage others to do the same.

A recipient who gets a FAIL result from this HELO test could decide to
reject the connection without ever proceeding to MAILFROM.  This is why the
specification suggests testing HELO before MAILFROM.   We know that
internal host names, such as "mail.example.local", will fail both of these
tests because the local domain cannot be published in DNS.   I expect that
any attempt to require a PASS from this test will encounter an unacceptable
number of false positives, so I do not see it as particularly useful.
But the option exists.

Test Two:
If the conversation proceeds past HELO to MAILFROM, then the second
validation is performed:   Is the Source IP is authorized to send on behalf
of the SMTP domain?   When the SMTP address is null, then
postmaster@HeloDomain serves as a proxy for performing this test.

We have two different tests, and two paths for performing the second test.
 Organizations have the choice of whether to implement one, both, or
neither test.   But the two tests are complementary, not mutually exclusive.

HELO test violations will have nothing to do with message flow path, since
the test only examines whether the adjacent server name can be plausibly
linked to the adjacent IP address.  A DKIM signature is not a third way of
answering this question, because a DKIM signature cannot be reliably
associated with the server that applied the signature.   Nor do I think we
want a third solution to this question.  Consequently, the HEL:O test is
unrelated to DMARC.  The SMTP Address test is appropriate to DMARC, whether
it is evaluated using a supplied name or a derived name based on
postmaster@helodomain.

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

Re: [dmarc-ietf] Forensic report loops are a problem

[Michael Thomas]

On 2/1/21 3:21 PM, John Levine wrote:

In article <9aea1615-64a5-a310-b8c7-83ec0c316...@gmail.com> you write:

-=-=-=-=-=-

On 2/1/2021 10:08 AM, Alessandro Vesely wrote:

On Mon 01/Feb/2021 17:38:07 +0100 Dave Crocker wrote:

Consider the challenges to ensuring a DMARC pass.  That's a pretty
high barrier to entry against generating reports.

Well, if a mail site is unable to get a DMARC pass, they have more
urgent problems to solve than setting up aggregate report generation.


No, they probably don't have more urgent problems. Sites choose not to
adopt DMARC for a variety of reasons. It's probably a good idea to
respect that variety.

The model that a receiving site is not allowed to report DMARC traffic
unless that site is also generating DMARC authentication is
Procrustean.  And as I noted, is likely counter-productive.

Ah, we have a semantic question.  I consider a message with p=none to be 
aligned.


This is why that paragraph needs to be made a (sub) section stating its 
motivation and done in terms of what the requirements are on the sender 
and the receiver of the report. It has nothing at all to with the DMARC 
protocol. That's what I tried to clarify in #98.


Mike

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

Re: [dmarc-ietf] Forensic report loops are a problem

[Dotzero]

On Mon, Feb 1, 2021 at 6:49 PM Michael Thomas  wrote:

>
>
> On 2/1/21 3:23 PM, Dave Crocker wrote:
> > On 2/1/2021 3:21 PM, John Levine wrote:
> >> I find it hard to believe that if you are going to enough effort to
> >> maintain the data to create and send reports, you can't figure out how
> >> to install an SPF record for your reporting domain.
> >
> > Except that the tracking/reporting functions are completely separate
> > from the 'signing' side of DMARC and could easily be different parts
> > of a company.
> >
> > d/
> >
> It strains credulity that one part of a company would want to send out
> reports when some other can't even sign their email. Both need access to
> the email stream for starters.
>
> It doesn't strain my credulity at all. You are assuming a single mail
stream. I saw it at my own employer before we got centralized control of
DNS and implemented email authentication. I actually know of one company
where several hundred thousand dollars of marketing emails ended up not
getting through because a marketer thought they could evade corporate
policy and the ESP gladly took the money even though the mail was getting
rejected. It's a crazy world out there.

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

Re: [dmarc-ietf] Forensic report loops are a problem

[Dave Crocker]

On 2/1/2021 3:49 PM, Michael Thomas wrote:


It strains credulity that one part of a company would want to send out 
reports when some other can't even sign their email. Both need access 
to the email stream for starters. 


No it doesn'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] Forensic report loops are a problem

[Michael Thomas]

On 2/1/21 3:23 PM, Dave Crocker wrote:

On 2/1/2021 3:21 PM, John Levine wrote:

I find it hard to believe that if you are going to enough effort to
maintain the data to create and send reports, you can't figure out how
to install an SPF record for your reporting domain.


Except that the tracking/reporting functions are completely separate 
from the 'signing' side of DMARC and could easily be different parts 
of a company.


d/

It strains credulity that one part of a company would want to send out 
reports when some other can't even sign their email. Both need access to 
the email stream for starters.


Mike

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

Re: [dmarc-ietf] Forensic report loops are a problem

[Dave Crocker]

On 2/1/2021 3:21 PM, John Levine wrote:

I find it hard to believe that if you are going to enough effort to
maintain the data to create and send reports, you can't figure out how
to install an SPF record for your reporting domain.


Except that the tracking/reporting functions are completely separate 
from the 'signing' side of DMARC and could easily be different parts of 
a company.


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] Forensic report loops are a problem

[John Levine]

In article <9aea1615-64a5-a310-b8c7-83ec0c316...@gmail.com> you write:
>-=-=-=-=-=-
>
>On 2/1/2021 10:08 AM, Alessandro Vesely wrote:
>> On Mon 01/Feb/2021 17:38:07 +0100 Dave Crocker wrote:
>>> Consider the challenges to ensuring a DMARC pass.  That's a pretty 
>>> high barrier to entry against generating reports.
>>
>> Well, if a mail site is unable to get a DMARC pass, they have more 
>> urgent problems to solve than setting up aggregate report generation. 
>
>
>No, they probably don't have more urgent problems. Sites choose not to 
>adopt DMARC for a variety of reasons. It's probably a good idea to 
>respect that variety.
>
>The model that a receiving site is not allowed to report DMARC traffic 
>unless that site is also generating DMARC authentication is 
>Procrustean.  And as I noted, is likely counter-productive.

Ah, we have a semantic question.  I consider a message with p=none to be 
aligned.

R's,
John

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

Re: [dmarc-ietf] Forensic report loops are a problem

[John Levine]

In article  you write:
>-=-=-=-=-=-
>
>On 1/27/2021 7:17 PM, Steven M Jones wrote:
>> 3.3. Transport
>>
>>    Email streams carrying DMARC failure reports MUST conform to the
>>    DMARC mechanism, thereby resulting in an aligned "pass". 

>Mostly this will discourage reporting.  Legitimate reporting.

It's been like this for a decade.

>Consider the challenges to ensuring a DMARC pass.

Looking at the results I get (and understanding that the results that
arrive via private agreements are likely different), I get reports
from linkedin.com and seznam.cz that are aligned via SPF and are DMARC
reject and none, respectively, and from antispamcloud.com that are
totally broken, not even multipart/report.

I find it hard to believe that if you are going to enough effort to
maintain the data to create and send reports, you can't figure out how
to install an SPF record for your reporting domain.

R's,
John

___
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:
>On Mon 01/Feb/2021 01:10:01 +0100 Scott Kitterman wrote:
>> I think that we're well past learning anything new in this thread.
>> 
>> SPF is what it is (RFC 7208).  DMARC doesn't need to re-invent the protocol
>> (and shouldn't).  For any properly implemented SPF verifier, DMARC should be
>> able to consume the Mail From result.
>
>Perhaps Courier-MTA is not so properly implemented, but when mail from is 
>empty 
>it just omits the corresponding Received-SPF: header field.

That's a peculiarity of Courier.  My MTA adds an SPF clause in the A-R header
whether or not there's a null bounce address.

>OTOH, properly implemented SPF verifiers could skip producing a Mail From 
>result if the helo identity was verified successfully.

No, they could not.  That's not what the SPF spec says.

>It makes sense to add a section that modifies RFC 7208.  See below.

Please, can we stop the Mission Gallop?

R's,
John

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

Re: [dmarc-ietf] Report bombing is a prolem, Forensic report loops are not

[Dotzero]

On Sun, Jan 31, 2021 at 3:02 PM John Levine  wrote:

> In article <49b248dc-91a7-7f2d-ba28-72fe8d6d3...@tana.it> you write:
> >Rate limiting usually implies a number of buckets.  They are managed by
> >imposing limits per time periods, which can be either server-global or
> per
> >bucket.  Normally, for MSA usage, one has one bucket per user.  I have
> never
> >implemented failure reporting, but I'd guess buckets may vary.  Besides
> the
> >signing domain (which determines the report consumer), the receiving
> address,
> >the sender and the spam flag may deserve their own buckets.
>
> The only one that matters for DMARC reporting is the recipient
> address, since the purpose of rate limiting is to avoid overloading
> the recipient mail system. I wouldn't worry about trying to send a
> "representative" set of reports.
>
> Keep in mind that very few people send failure reports at all.
>

My experience is that most failure reports are provided through private
channels where there are contractual agreements in place to deal with
potential privacy and legal issues. This may be through intermediaries or
direct between the parties (sending organization and receiving
organization).

Understand that the DMARC effort came about because the original
participants felt it was useful in the private exchange of information
between senders and receivers. We felt it was better as an open standard
rather than as a private club.

>From my perspective it is unfortunate that we can't seem to find a way to
implement a system where failure reports are available other than through
private channels.

In my
> experience few of them are useful. Most of mine are ordinary mailing
> list messages where the failure is not surprising and does not mean
> that anything needs to be fixed.
>

I disagree with John about failure reports not being useful.  I have found
failure reports to be extremely useful in anti-abuse efforts. The value can
range from takedowns of images and links to maliciousness to shutting down
sources of maliciousness.In some cases it has proven useful to law
enforcement as documentation of activities.

Unfortunately, I think addressing some of this has to be beyond the scope
of the current effort.

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

Re: [dmarc-ietf] Forensic report loops are a problem

[Michael Thomas]

On 2/1/21 10:52 AM, Dave Crocker wrote:

On 2/1/2021 10:25 AM, Michael Thomas wrote:



On 2/1/21 10:13 AM, Dave Crocker wrote:
The model that a receiving site is not allowed to report DMARC 
traffic unless that site is also generating DMARC authentication is 
Procrustean.  And as I noted, is likely counter-productive. 


There is no such thing as "DMARC authentication".

Actually, there is.  DMARC's requirement for alignment with the 
author's From: field domain name asserts a specific bit of 
authenticated semantics that does not exist elsewhere.



The paragraph quoted is poorly written and should be rewritten to say 
that the report should pass either SPF or DKIM authentication as I 
wrote in issue #98.


It might be written better, but its requirement is for support of 
applying DMARC to generated reports.  That's more than just requiring 
SPF or DKIM.


This is separate from not asserting the requirement at all, of course.

The entire thrust of the paragraph needs to be rewritten to what the 
senders and receivers must do. It does not require invoking the policy 
lookup since it can make the determination to reject reports that do not 
authenticate with either SPF or DKIM itself. The section also needs to 
clarify whether spoofing the envelope-to domain in the report contents 
is allowed or not. I do not think it should be.


Mike

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

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

[Scott Kitterman]

On Monday, February 1, 2021 7:17:20 AM EST Alessandro Vesely wrote:
> On Mon 01/Feb/2021 01:10:01 +0100 Scott Kitterman wrote:
> > I think that we're well past learning anything new in this thread.
> > 
> > SPF is what it is (RFC 7208).  DMARC doesn't need to re-invent the
> > protocol
> > (and shouldn't).  For any properly implemented SPF verifier, DMARC should
> > be able to consume the Mail From result.
> 
> Perhaps Courier-MTA is not so properly implemented, but when mail from is
> empty it just omits the corresponding Received-SPF: header field.
> 
> OTOH, properly implemented SPF verifiers could skip producing a Mail From
> result if the helo identity was verified successfully.
> 
> In conclusion, the idiosyncratic requirement can hardly be implemented.

I have no idea why you would think that.  If mail from is null, use 
postmaster@HELO domain  as mail from is trivial to implement.  If an SPF 
verification implementation does not correctly implement RFC 7208, the 
appropriate solution is to fix it, not add work arounds to DMARC.

That said, I don't think there's harm is using HELO results in DMARC if they 
align, but I don't think it will come up very often and isn't worth worrying 
about enough to rewrite that part of the DMARC specification.



> > On Sunday, January 31, 2021 2:03:45 PM EST Douglas Foster wrote:
> >> I don't see any justification for using HELO unless the SMTP address is
> >> null.  If the SPF RFC says otherwise, this should be corrected.
> 
> It makes sense to add a section that modifies RFC 7208.  See below.

No.  Changes to SPF are out of scope for the working group.

Scott K

> On Sun 31/Jan/2021 03:27:41 +0100 Douglas Foster wrote:
> > My data, cited previously, indicates that HELO can be useful for both
> > blacklisting and whitelisting.   It should not be ignored.
> > 
> >> On Sun, Jan 31, 2021 at 11:52 AM John R Levine  wrote:
> >>> On Sun, 31 Jan 2021, Alessandro Vesely wrote:
>  One way to interpret RFC 7489 is that you can put dmarc=pass based on
>  the helo identity *only if* MAIL FROM is null. >>>
> >>> 
> >>> That would be consistent with 7489.
> >>> 
> >>> Sec 3.1.2 says
> >>> 
> >>> Note that the RFC5321.HELO identity is not typically used in the
> >>> context of DMARC (except when required to "fake" an otherwise null
> >>> reverse-path), even though a "pure SPF" implementation according to
> >>> [SPF] would check that identifier.
> 
> Does that mean that an implementation that uses the RFC5321.HELO identity
> without taking care of whether RFC5321.MailFrom is empty is *atypical*?
> 
> Please note that all the text occurring before that paragraph would suggest
> that any authenticated domain, if aligned, would do.  The quoted paragraph
> comes as a note, by surprise, without bringing any rationale.  That text
> needs to be revised whether or not we remove the idiosyncrasy.
> 
> And the only rationale learnt in this thread is that one could type whatever
> it wants in the helo/ehlo command, as if that weren't true for the whole
> SMTP session.
> >>> But then 4.1 says
> >>> 
> >>> o  [SPF], which can authenticate both the domain found in an [SMTP]
> >>> 
> >>>HELO/EHLO command (the HELO identity) and the domain found in an
> >>>SMTP MAIL command (the MAIL FROM identity).  DMARC uses the
> >>>result
> >>>of SPF authentication of the MAIL FROM identity.  Section 2.4 of
> >>>[SPF] describes MAIL FROM processing for cases in which the MAIL
> >>>command has a null path.
> >>> 
> >>> That section of 7208 says that if there's a null bounce address, SPF
> >>> pretends that the MAIL FROM was postmaster@HELO.
> 
> "Postmaster" is necessary, because SPF mechanisms can refer to the local
> part.
> 
> The SPF part I'd modify, however, is Section 2.3, where it says:
> 
> If a conclusive determination about the
> message can be made based on a check of "HELO", then the use of DNS
> resources to process the typically more complex "MAIL FROM" can be
> avoided.
> 
> I'd append to that sentence:
> 
>, unless downstream filters need it anyway.
> 
> Since we're at it, that paragraph continues with the following sentence:
> 
>  Additionally, since SPF records published for "HELO"
> identities refer to a single host, when available, they are a very
> reliable source of host authorization status.
> 
> Isn't that the exact opposite of what many of us are claiming?  And is it
> legit for a proposed standard to quietly counter an existing proposed
> standard without some kind of rationale?
> 
> >>> If we want, we can say not to use the SPF HELO identity, but that would
> >>> be
> >>> an incompatible change to 7489 and I suspect would not match what most
> >>> DMARC checking code does.
> 
> OTOH, relaxing the requirement that the SPF HELO identity be used only when
> MAIL FROM is empty brings no incompatibility.  It's just a cleanup.
> 
> 
>

Re: [dmarc-ietf] Forensic report loops are a problem

[Dave Crocker]

On 2/1/2021 10:25 AM, Michael Thomas wrote:



On 2/1/21 10:13 AM, Dave Crocker wrote:
The model that a receiving site is not allowed to report DMARC 
traffic unless that site is also generating DMARC authentication is 
Procrustean.  And as I noted, is likely counter-productive. 


There is no such thing as "DMARC authentication".

Actually, there is.  DMARC's requirement for alignment with the author's 
From: field domain name asserts a specific bit of authenticated 
semantics that does not exist elsewhere.



The paragraph quoted is poorly written and should be rewritten to say 
that the report should pass either SPF or DKIM authentication as I 
wrote in issue #98.


It might be written better, but its requirement is for support of 
applying DMARC to generated reports.  That's more than just requiring 
SPF or DKIM.


This is separate from not asserting the requirement at all, of course.

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] Forensic report loops are a problem

[Michael Thomas]

On 2/1/21 10:13 AM, Dave Crocker wrote:

On 2/1/2021 10:08 AM, Alessandro Vesely wrote:

On Mon 01/Feb/2021 17:38:07 +0100 Dave Crocker wrote:
Consider the challenges to ensuring a DMARC pass.  That's a pretty 
high barrier to entry against generating reports.


Well, if a mail site is unable to get a DMARC pass, they have more 
urgent problems to solve than setting up aggregate report generation. 



No, they probably don't have more urgent problems. Sites choose not to 
adopt DMARC for a variety of reasons. It's probably a good idea to 
respect that variety.


The model that a receiving site is not allowed to report DMARC traffic 
unless that site is also generating DMARC authentication is 
Procrustean.  And as I noted, is likely counter-productive.


There is no such thing as "DMARC authentication". The paragraph quoted 
is poorly written and should be rewritten to say that the report should 
pass either SPF or DKIM authentication as I wrote in issue #98. This has 
nothing to do with the DMARC at all. And if requiring authentication is 
"religious fervor", I really don't know what to say.


Mike


I understand the zeal that drives a lot of the effort to promote 
DMARC, but the danger with aggressive proselytizing is that it changes 
from serious technical and operational evaluation into purely 
religious fervor.



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
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Forensic report loops are a problem

[Dave Crocker]

On 2/1/2021 10:15 AM, Michael Thomas wrote:


On 2/1/21 9:25 AM, Dave Crocker wrote:

So, it's probably a good thing I emphasized:

"It should take a very, very substantial record of reporting problems 
to justify such a barrier."


Meanwhile in 2021, the internet is a dangerous place where the default 
posture is to assume that if something can be gamed it will be gamed.



Perhaps you'd put that comment into both a cost/benefit tradeoff 
consideration and in technical and operational terms that reflects 
practical limits?


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] Forensic report loops are a problem

[Michael Thomas]

On 2/1/21 10:08 AM, Alessandro Vesely wrote:

On Mon 01/Feb/2021 17:38:07 +0100 Dave Crocker wrote:


Consider the challenges to ensuring a DMARC pass.  That's a pretty 
high barrier to entry against generating reports.



Well, if a mail site is unable to get a DMARC pass, they have more 
urgent problems to solve than setting up aggregate report generation.



+1

Mike

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

Re: [dmarc-ietf] Forensic report loops are a problem

[Michael Thomas]

On 2/1/21 9:25 AM, Dave Crocker wrote:

On 2/1/2021 9:12 AM, Michael Thomas wrote:

On 2/1/21 8:38 AM, Dave Crocker wrote:
Mostly this will discourage reporting. Legitimate reporting. 


Versus illegitimate ones you'd assumedly want to ignore.



So, it's probably a good thing I emphasized:

"It should take a very, very substantial record of reporting problems 
to justify such a barrier."


Meanwhile in 2021, the internet is a dangerous place where the default 
posture is to assume that if something can be gamed it will be gamed.


Mike

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

Re: [dmarc-ietf] Forensic report loops are a problem

[Dave Crocker]

On 2/1/2021 10:08 AM, Alessandro Vesely wrote:

On Mon 01/Feb/2021 17:38:07 +0100 Dave Crocker wrote:
Consider the challenges to ensuring a DMARC pass.  That's a pretty 
high barrier to entry against generating reports.


Well, if a mail site is unable to get a DMARC pass, they have more 
urgent problems to solve than setting up aggregate report generation. 



No, they probably don't have more urgent problems. Sites choose not to 
adopt DMARC for a variety of reasons. It's probably a good idea to 
respect that variety.


The model that a receiving site is not allowed to report DMARC traffic 
unless that site is also generating DMARC authentication is 
Procrustean.  And as I noted, is likely counter-productive.


I understand the zeal that drives a lot of the effort to promote DMARC, 
but the danger with aggressive proselytizing is that it changes from 
serious technical and operational evaluation into purely religious fervor.



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] Forensic report loops are a problem

[Alessandro Vesely]

On Mon 01/Feb/2021 17:38:07 +0100 Dave Crocker wrote:


Consider the challenges to ensuring a DMARC pass.  That's a pretty high barrier 
to entry against generating reports.



Well, if a mail site is unable to get a DMARC pass, they have more urgent 
problems to solve than setting up aggregate report generation.



Best
Ale
--






















___
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)

[Alessandro Vesely]

On Mon 01/Feb/2021 16:11:51 +0100 Brotman, Alex wrote:
This came up in another thread elsewhere, and wanted to see if there was any 
more input before closing this as “wontfix”.  The only feedback I got during 
this thread was that this external check should remain as it may prevent abuse 
and it appears that many have already implemented this.



Yes, please close it.

For the record, two implementations are here:
https://github.com/trusteddomainproject/OpenDMARC/blob/master/libopendmarc/opendmarc_policy.c#L574
http://www.tana.it/svn/zdkimfilter/trunk/src/zaggregate.c#line=725
(if your browser doesn't implement RFC 5147, search "check_addr")


The original thread is here: 
https://mailarchive.ietf.org/arch/msg/dmarc/pL7dsXjXn9BmADxly0yO2cDC_ro/ 



That's the same thread we're in now.


Best
Ale
--










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

Re: [dmarc-ietf] Forensic report loops are a problem

[Dave Crocker]

On 2/1/2021 9:12 AM, Michael Thomas wrote:

On 2/1/21 8:38 AM, Dave Crocker wrote:
Mostly this will discourage reporting.  Legitimate reporting. 


Versus illegitimate ones you'd assumedly want to ignore.



So, it's probably a good thing I emphasized:

"It should take a very, very substantial record of reporting problems to 
justify such a barrier."



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] Forensic report loops are a problem

[Michael Thomas]

On 2/1/21 8:38 AM, Dave Crocker wrote:

On 1/27/2021 7:17 PM, Steven M Jones wrote:

3.3. Transport

   Email streams carrying DMARC failure reports MUST conform to the
   DMARC mechanism, thereby resulting in an aligned "pass". 



Mostly this will discourage reporting.  Legitimate reporting.


Versus illegitimate ones you'd assumedly want to ignore.

Mike

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

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

[Alessandro Vesely]

On Mon 01/Feb/2021 15:26:37 +0100 Douglas Foster wrote:


If Helo aligns with From, it says that the mail server has permission to send 
on behalf of the From domain, but it does not justify using a different domain 
in the SMTP address.   If the SMTP address is null, this is not a problem.   If 
it is not null and is different from the HELO domain, we have permitted domain 
abuse.



Who said a different MAIL FROM is abusive?  What if I have an account at gmail 
and, for convenience, prefer to collect bounces at that mailbox?  Would I need 
a special permission to do so?


What if helo is verified, bounce address is null, but there is a DKIM-Signature 
which is not aligned.  Is that domain abuse too?


Hm...


Best
Ale
--









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

Re: [dmarc-ietf] Forensic report loops are a problem

[Dave Crocker]

On 1/27/2021 7:17 PM, Steven M Jones wrote:

3.3. Transport

   Email streams carrying DMARC failure reports MUST conform to the
   DMARC mechanism, thereby resulting in an aligned "pass". 



   1. I haven't been tracking discussion closely.  So if this is
   something already sufficiently well-discussed and understood and
   still landed on the above normative text, I'll apologize for re-raising.

   2. But not really, because it strikes me as a serious operational
   mistake, though a well-motivated one.

Mostly this will discourage reporting.  Legitimate reporting.

Consider the challenges to ensuring a DMARC pass.  That's a pretty high 
barrier to entry against generating reports.  It should take a very, 
very substantial record of reporting problems to justify such a barrier.


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] Report bombing is a prolem, Forensic report loops are not

[John R Levine]

3.3.  Transport

  Email streams carrying DMARC failure reports MUST conform to the
  DMARC mechanism, thereby resulting in an aligned "pass".  Special
  care must be taken of authentication, as failure to authenticate
  failure reports may result in mail loops.

  Reporters SHOULD rate limit the number of failure reports sent to any
  recipient to avoid overloading recipient systems.

Not MUST?


You might have other ways to prevent mailbombing, e.g., only sending 
failure reports to people who you know have bigger mail systems than you 
do.


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] Discussion: Removal of validation for external destinations (Ticket #76)

[Brotman, Alex]

This came up in another thread elsewhere, and wanted to see if there was any 
more input before closing this as "wontfix".  The only feedback I got during 
this thread was that this external check should remain as it may prevent abuse 
and it appears that many have already implemented this.

The original thread is here: 
https://mailarchive.ietf.org/arch/msg/dmarc/pL7dsXjXn9BmADxly0yO2cDC_ro/

Thanks

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

From: dmarc  On Behalf Of Marc Bradshaw
Sent: Monday, December 7, 2020 5:25 PM
To: DMARC IETF 
Subject: Re: [dmarc-ietf] Discussion: Removal of validation for external 
destinations (Ticket #76)

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


--
[https://secure.gravatar.com/avatar/b214a020f4eb135ce2a6901d7540bdb1?s=44&d=404]

  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

[Douglas Foster]

An SPF check on MailFrom says that this host has permission to send on this
particular SMTP mail domain, and From alignment with that this SMTP mail
domain has permission to send on behalf of that same domain.

If Helo aligns with From, it says that the mail server has permission to
send on behalf of the From domain, but it does not justify using a
different domain in the SMTP address.   If the SMTP address is null, this
is not a problem.   If it is not null and is different from the HELO
domain, we have permitted domain abuse.



On Mon, Feb 1, 2021 at 7:17 AM Alessandro Vesely  wrote:

> On Mon 01/Feb/2021 01:10:01 +0100 Scott Kitterman wrote:
> > I think that we're well past learning anything new in this thread.
> >
> > SPF is what it is (RFC 7208).  DMARC doesn't need to re-invent the
> protocol
> > (and shouldn't).  For any properly implemented SPF verifier, DMARC
> should be
> > able to consume the Mail From result.
>
>
> Perhaps Courier-MTA is not so properly implemented, but when mail from is
> empty
> it just omits the corresponding Received-SPF: header field.
>
> OTOH, properly implemented SPF verifiers could skip producing a Mail From
> result if the helo identity was verified successfully.
>
> In conclusion, the idiosyncratic requirement can hardly be implemented.
>
>
> > On Sunday, January 31, 2021 2:03:45 PM EST Douglas Foster wrote:
> >> I don't see any justification for using HELO unless the SMTP address is
> >> null.  If the SPF RFC says otherwise, this should be corrected.
>
>
> It makes sense to add a section that modifies RFC 7208.  See below.
>
> On Sun 31/Jan/2021 03:27:41 +0100 Douglas Foster wrote:
> > My data, cited previously, indicates that HELO can be useful for both
> > blacklisting and whitelisting.   It should not be ignored.
>
>
> >> On Sun, Jan 31, 2021 at 11:52 AM John R Levine  wrote:
> >>> On Sun, 31 Jan 2021, Alessandro Vesely wrote:
>  One way to interpret RFC 7489 is that you can put dmarc=pass based on
>  the helo identity *only if* MAIL FROM is null. >>>
> >>> That would be consistent with 7489.
> >>>
> >>> Sec 3.1.2 says
> >>>
> >>> Note that the RFC5321.HELO identity is not typically used in the
> >>> context of DMARC (except when required to "fake" an otherwise null
> >>> reverse-path), even though a "pure SPF" implementation according to
> >>> [SPF] would check that identifier.
>
>
> Does that mean that an implementation that uses the RFC5321.HELO identity
> without taking care of whether RFC5321.MailFrom is empty is *atypical*?
>
> Please note that all the text occurring before that paragraph would
> suggest
> that any authenticated domain, if aligned, would do.  The quoted paragraph
> comes as a note, by surprise, without bringing any rationale.  That text
> needs
> to be revised whether or not we remove the idiosyncrasy.
>
> And the only rationale learnt in this thread is that one could type
> whatever it
> wants in the helo/ehlo command, as if that weren't true for the whole SMTP
> session.
>
>
> >>> But then 4.1 says
> >>>
> >>> o  [SPF], which can authenticate both the domain found in an [SMTP]
> >>>HELO/EHLO command (the HELO identity) and the domain found in an
> >>>SMTP MAIL command (the MAIL FROM identity).  DMARC uses the
> result
> >>>of SPF authentication of the MAIL FROM identity.  Section 2.4 of
> >>>[SPF] describes MAIL FROM processing for cases in which the MAIL
> >>>command has a null path.
> >>>
> >>> That section of 7208 says that if there's a null bounce address, SPF
> >>> pretends that the MAIL FROM was postmaster@HELO.
>
>
> "Postmaster" is necessary, because SPF mechanisms can refer to the local
> part.
>
> The SPF part I'd modify, however, is Section 2.3, where it says:
>
> If a conclusive determination about the
> message can be made based on a check of "HELO", then the use of DNS
> resources to process the typically more complex "MAIL FROM" can be
> avoided.
>
> I'd append to that sentence:
>
>, unless downstream filters need it anyway.
>
> Since we're at it, that paragraph continues with the following sentence:
>
>  Additionally, since SPF records published for "HELO"
> identities refer to a single host, when available, they are a very
> reliable source of host authorization status.
>
> Isn't that the exact opposite of what many of us are claiming?  And is it
> legit
> for a proposed standard to quietly counter an existing proposed standard
> without some kind of rationale?
>
>
> >>> If we want, we can say not to use the SPF HELO identity, but that
> would be
> >>> an incompatible change to 7489 and I suspect would not match what most
> >>> DMARC checking code does.
>
>
> OTOH, relaxing the requirement that the SPF HELO identity be used only
> when
> MAIL FROM is empty brings no incompatibility.  It's just a cleanup.
>
>
> Best
> Ale
> --
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

Re: [dmarc-ietf] Report bombing is a prolem, Forensic report loops are not

[Alessandro Vesely]

On Sun 31/Jan/2021 21:02:38 +0100 John Levine wrote:

In article <49b248dc-91a7-7f2d-ba28-72fe8d6d3...@tana.it> you write:
Rate limiting usually implies a number of buckets.  They are managed by 
imposing limits per time periods, which can be either server-global or per 
bucket.  Normally, for MSA usage, one has one bucket per user.  I have never 
implemented failure reporting, but I'd guess buckets may vary.  Besides the 
signing domain (which determines the report consumer), the receiving address, 
the sender and the spam flag may deserve their own buckets.


The only one that matters for DMARC reporting is the recipient
address, since the purpose of rate limiting is to avoid overloading
the recipient mail system. I wouldn't worry about trying to send a
"representative" set of reports.

Keep in mind that very few people send failure reports at all.



True, it's not worth suggesting a super duper rate limiting.

Committed text:


3.3.  Transport

   Email streams carrying DMARC failure reports MUST conform to the
   DMARC mechanism, thereby resulting in an aligned "pass".  Special
   care must be taken of authentication, as failure to authenticate
   failure reports may result in mail loops.

   Reporters SHOULD rate limit the number of failure reports sent to any
   recipient to avoid overloading recipient systems.


Not MUST?

Best
Ale
--





















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

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

[Alessandro Vesely]

On Mon 01/Feb/2021 01:10:01 +0100 Scott Kitterman wrote:

I think that we're well past learning anything new in this thread.

SPF is what it is (RFC 7208).  DMARC doesn't need to re-invent the protocol
(and shouldn't).  For any properly implemented SPF verifier, DMARC should be
able to consume the Mail From result.



Perhaps Courier-MTA is not so properly implemented, but when mail from is empty 
it just omits the corresponding Received-SPF: header field.


OTOH, properly implemented SPF verifiers could skip producing a Mail From 
result if the helo identity was verified successfully.


In conclusion, the idiosyncratic requirement can hardly be implemented.



On Sunday, January 31, 2021 2:03:45 PM EST Douglas Foster wrote:

I don't see any justification for using HELO unless the SMTP address is
null.  If the SPF RFC says otherwise, this should be corrected.



It makes sense to add a section that modifies RFC 7208.  See below.

On Sun 31/Jan/2021 03:27:41 +0100 Douglas Foster wrote:

My data, cited previously, indicates that HELO can be useful for both
blacklisting and whitelisting.   It should not be ignored.




On Sun, Jan 31, 2021 at 11:52 AM John R Levine  wrote:

On Sun, 31 Jan 2021, Alessandro Vesely wrote:
One way to interpret RFC 7489 is that you can put dmarc=pass based on 
the helo identity *only if* MAIL FROM is null. >>>

That would be consistent with 7489.

Sec 3.1.2 says

Note that the RFC5321.HELO identity is not typically used in the
context of DMARC (except when required to "fake" an otherwise null
reverse-path), even though a "pure SPF" implementation according to
[SPF] would check that identifier.



Does that mean that an implementation that uses the RFC5321.HELO identity 
without taking care of whether RFC5321.MailFrom is empty is *atypical*?


Please note that all the text occurring before that paragraph would suggest 
that any authenticated domain, if aligned, would do.  The quoted paragraph 
comes as a note, by surprise, without bringing any rationale.  That text needs 
to be revised whether or not we remove the idiosyncrasy.


And the only rationale learnt in this thread is that one could type whatever it 
wants in the helo/ehlo command, as if that weren't true for the whole SMTP session.




But then 4.1 says

o  [SPF], which can authenticate both the domain found in an [SMTP]
   HELO/EHLO command (the HELO identity) and the domain found in an
   SMTP MAIL command (the MAIL FROM identity).  DMARC uses the result
   of SPF authentication of the MAIL FROM identity.  Section 2.4 of
   [SPF] describes MAIL FROM processing for cases in which the MAIL
   command has a null path.

That section of 7208 says that if there's a null bounce address, SPF
pretends that the MAIL FROM was postmaster@HELO.



"Postmaster" is necessary, because SPF mechanisms can refer to the local part.

The SPF part I'd modify, however, is Section 2.3, where it says:

   If a conclusive determination about the
   message can be made based on a check of "HELO", then the use of DNS
   resources to process the typically more complex "MAIL FROM" can be
   avoided.

I'd append to that sentence:

  , unless downstream filters need it anyway.

Since we're at it, that paragraph continues with the following sentence:

Additionally, since SPF records published for "HELO"
   identities refer to a single host, when available, they are a very
   reliable source of host authorization status.

Isn't that the exact opposite of what many of us are claiming?  And is it legit 
for a proposed standard to quietly counter an existing proposed standard 
without some kind of rationale?




If we want, we can say not to use the SPF HELO identity, but that would be
an incompatible change to 7489 and I suspect would not match what most
DMARC checking code does.



OTOH, relaxing the requirement that the SPF HELO identity be used only when 
MAIL FROM is empty brings no incompatibility.  It's just a cleanup.



Best
Ale
--




























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