Re: [dmarc-discuss] RUA vs RUF reports

[John Levine via dmarc-discuss]

In article  you write:
>I don't think you can be held responsible if a "total stranger's" email 
>ends up in your inbox because they put your domain in the From line of 
>the email without your authorization. ...

Maybe.  I gather there's all sorts of cases where it is not clear how
the operator of a domain relates to people with mail in that domain or
in that subdomain.  For example, I expect that university faculty or
company CEOs might not be thrilled that random low level IT people were
getting copies of their mail just because it happened to be forwarded
in a mildly funky way.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] RUA vs RUF reports

[Jonathan Kamens via dmarc-discuss]

Can you elaborate on how typosquatting is relevant to this? I'm confused.

If one of your users sends email /to/ a typosquatted domain, and you've 
DKIM'd the email properly on the way out, then you're not going to get 
failure reports because the email does, in fact, pass DMARC.


If someone sends email /from/ a typosquatted domain, then you're not 
going to get failure reports because it's not your domain in the From line.


I'm just... confused. I don't understand what scenario you are implying. 
Can you clarify for me?


Thanks,

Jonathan Kamens

On 5/30/18 5:17 PM, Elizabeth Zwicky wrote:
It might be that you are correct about GDPR, but this has been a 
concern well before the GDPR, and whether or not it concerns the Data 
Protection Authorities, it concerns our privacy lawyers. Typosquatting 
is, after all, a thing.


Elizabeth
*
*
*Elizabeth Zwicky*
Mail Abuse Distinguished Engineer
My oath: 濾 ☕️ 




On Wednesday, May 30, 2018, 2:02:45 PM PDT, Jonathan Kamens via 
dmarc-discuss  wrote:



On 5/30/18 4:22 PM, John Levine wrote:

2) The people receiving the failure reports aren't "total strangers."
They are either (a) the same people who run the email infrastructure (if
failure reports are handled internally), who are presumably authorized
to look at email headers while troubleshooting issues, or (b)
third-party data processors (to use the GDPR terminology), which are
permitted as long as how they are using the data is disclosed to users.

They're sent to whoever some ruf= tag points to.  I get all the
failure reports for any message with one of my domains on the From:
line, even if if was forged or a typo or a configuration error and
nobody related to me sent it.  Sounds like total strangers to me.


I don't think you can be held responsible if a "total stranger's" 
email ends up in your inbox because they put your domain in the From 
line of the email without your authorization. Furthermore, of the 
cases you mentioned ("forged", "typo", "configuration error"), I don't 
think anything but "forged" happens with sufficient frequency to be 
worth your concern or the concern of the European Union's member 
states' Data Protection Authorities.


  Jonathan Kamens


___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org 
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note 
Well terms (http://www.dmarc.org/note_well.html)
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] RUA vs RUF reports

[Jonathan Kamens via dmarc-discuss]

On 5/30/18 4:22 PM, John Levine wrote:

2) The people receiving the failure reports aren't "total strangers."
They are either (a) the same people who run the email infrastructure (if
failure reports are handled internally), who are presumably authorized
to look at email headers while troubleshooting issues, or (b)
third-party data processors (to use the GDPR terminology), which are
permitted as long as how they are using the data is disclosed to users.

They're sent to whoever some ruf= tag points to.  I get all the
failure reports for any message with one of my domains on the From:
line, even if if was forged or a typo or a configuration error and
nobody related to me sent it.  Sounds like total strangers to me.


I don't think you can be held responsible if a "total stranger's" email 
ends up in your inbox because they put your domain in the From line of 
the email without your authorization. Furthermore, of the cases you 
mentioned ("forged", "typo", "configuration error"), I don't think 
anything but "forged" happens with sufficient frequency to be worth your 
concern or the concern of the European Union's member states' Data 
Protection Authorities.


  Jonathan Kamens


___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] RUA vs RUF reports

[John Levine via dmarc-discuss]

In article  you write:
>1) Most of the failure reports I've seen haven't included the message 
>body, they've only included the headers.

Depends who you get them from.  The ones from Netease are just the
headers, the ones from Linkedin give you the whole message.


>2) The people receiving the failure reports aren't "total strangers." 
>They are either (a) the same people who run the email infrastructure (if 
>failure reports are handled internally), who are presumably authorized 
>to look at email headers while troubleshooting issues, or (b) 
>third-party data processors (to use the GDPR terminology), which are 
>permitted as long as how they are using the data is disclosed to users.

They're sent to whoever some ruf= tag points to.  I get all the
failure reports for any message with one of my domains on the From:
line, even if if was forged or a typo or a configuration error and
nobody related to me sent it.  Sounds like total strangers to me.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] RUA vs RUF reports

[Jonathan Kamens via dmarc-discuss]

Two comments:

1) Most of the failure reports I've seen haven't included the message 
body, they've only included the headers. So the exposure is limited. I 
assume limiting the exposure is the whole reason why the reports don't 
include message bodies.


2) The people receiving the failure reports aren't "total strangers." 
They are either (a) the same people who run the email infrastructure (if 
failure reports are handled internally), who are presumably authorized 
to look at email headers while troubleshooting issues, or (b) 
third-party data processors (to use the GDPR terminology), which are 
permitted as long as how they are using the data is disclosed to users.


There /could be/ a GDPR issue if failure reports are sent to a 
third-party processor /and/ that isn't disclosed to the user, but it 
isn't /ipso facto/ a GDPR issue to use a third-party processor to manage 
failure reports.


  jik

(I know more about the GDPR than I would like, and less than I should. :-/ )

On 5/30/18 10:56 AM, Richard via dmarc-discuss wrote:



Date: Tuesday, May 29, 2018 19:35:27 -0400
From: John Levine via dmarc-discuss 

In article

you write:
I'm surprised to learn of the low value of failure reports.

It's a lawyer thing.  Failure reports send copies of your users'
mail to total strangers.  Maybe those strangers had something to do
with that mail, maybe not.  You can make various arguments about
why even if the strangers didn't have anything to do with the mail
they should get to see it anyway, but you know how lawyers are,
always telling you to spend $1000 to defend against a $10 risk.



I realize that enforcement of GDPR is still a work in progress, but:

   > Failure reports send copies of your users'
   > mail to total strangers.

would seem to run directly against its intent.


___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] RUA vs RUF reports

[Richard via dmarc-discuss]

> Date: Tuesday, May 29, 2018 19:35:27 -0400
> From: John Levine via dmarc-discuss 
>
> In article
>  > you write:
>> I'm surprised to learn of the low value of failure reports.
> 
> It's a lawyer thing.  Failure reports send copies of your users'
> mail to total strangers.  Maybe those strangers had something to do
> with that mail, maybe not.  You can make various arguments about
> why even if the strangers didn't have anything to do with the mail
> they should get to see it anyway, but you know how lawyers are,
> always telling you to spend $1000 to defend against a $10 risk.
> 


I realize that enforcement of GDPR is still a work in progress, but:

  > Failure reports send copies of your users'
  > mail to total strangers.

would seem to run directly against its intent.


___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] RUA vs RUF reports

[John Levine via dmarc-discuss]

In article 
 you 
write:
>I'm surprised to learn of the low value of failure reports.

It's a lawyer thing.  Failure reports send copies of your users' mail
to total strangers.  Maybe those strangers had something to do with
that mail, maybe not.  You can make various arguments about why even
if the strangers didn't have anything to do with the mail they should
get to see it anyway, but you know how lawyers are, always telling you
to spend $1000 to defend against a $10 risk.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] RUA vs RUF reports

[Al Iverson via dmarc-discuss]

Thank you all! This has been very insightful.

I'm going to turn aggregate reports back on, and maybe build something to
process them (really as a programming exercise, I know there are tools and
services existing already).

I'm surprised to learn of the low value of failure reports. But it's good
to learn. For now I'm going to leave them on so I can peek at them for
curiosity's sake.

Cheers,
Al Iverson

On Mon, May 28, 2018 at 9:16 AM John Levine  wrote:

> In article  you write:
> >This is very helpful, thank you! I guess I assumed the issuance of
forensic
> >(failure) reports was more common than you indicate; because at my day
job
> >we get gobs of them for various domains ...

> Looking at my last 100 or so failure reports, I see that that more
> than half of them are from large Chinese ISPs, mostly for random spam
> that faked one of my domains, a few for mailing lists.  (Who knew that
> there were NANOG subscribers in China?)  There's maybe a dozen from
> Linkedin, which are a mix of mailing lists and bounces from Office 365
> for a customer who, against my advice, hosts their mail there.
> Perhaps someday Microsoft will figure out how to do SPF alignment for
> bounces but not today.  Other than that it's from a smattering of tiny
> systems, almost all mailing list messages.

> None of them are anything I can fix here, and I am not inclined to
> tell mailing list operators how to run their lists.

> I find the aggregate reports occasionally interesting.  The volume is
> not huge.  I have over a dozen active mail domains and the total
> number of reports since 2012 is 143,000, which I store in an ordinary
> mail folder.  I give away a little perl script to which I feed the
> report messages so it can put the interesting bits in a mysql database.

> R's,
> John



-- 
al iverson // wombatmail // miami
http://www.aliverson.com
http://www.spamresource.com
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] RUA vs RUF reports

[Roland Turner via dmarc-discuss]

Al,

Note that the terminology changed a while back from forensic reports to 
failure reports, presumably to remove the confusion that the use of the 
term forensic invites[1].


You've not stated what action you intend to take in response to the 
receipt of a failure report, so it's a little difficult to answer your 
question, but I'd point out two things:


 * Very few receiver-side authentication failures will cause you
   receive a failure report merely in response to your setting a ruf
   parameter. Receivers are in general unwilling to send them blindly,
   most will want background checks of the requester and a formal NDA,
   both of which generally happen as part of the contract with a
   specialist organisation providing email-authentication-related
   services. The spec provides for an interoperable failure reporting
   mechanism, but [obviously] can't mandate its use. If you are
   interested in knowing about failures in order to take some action
   (e.g. to change how you use particular lists, or to identify a list
   operator to encourage to change their DMARC handling), then >90% of
   the information that you're looking for is exclusively available to
   you in the aggregate reports.
 * For domains where you've not yet switched on p=reject, e.g. to
   minimise disruption of email flow, knowing about third parties
   impersonating you may be relevant whether or not they're sending to
   the few receivers who will send failure reports on request. This was
   certainly the case for me; when it became clear through aggregate
   reports that my personal domain was being impersonated - despite my
   not receiving a single failure report - I elected to switch on
   p=reject, then set about encouraging the few list operators who
   weren't yet honouring it to do so.

This does mean having to put in place some means to monitor aggregate 
reports for interesting failures, yes. Processing the XML to discover 
this is pretty straightforward, so long as you avoid the usual risks in 
processing XML from untrusted sources.


- Roland

1: working out what happened before vs. suitability for presentation in 
a public forum, particularly a court of law




On 28/05/18 01:17, Al Iverson via dmarc-discuss wrote:

Well, I think that would depend on the use case, would it not?. I've got
one server and Google Apps, everything signs with DKIM, and SPF is
configured correctly. I don't really have any edge cases to look out for --
no other outsource service providers in the mix. The rare (for me) failed
message forensic reports provide feedback about other peoples' broken
mailing lists (and maybe someday examples of forgery, if somebody forges my
domain). In that scenario, I'm getting a daily "everything is OK" aggregate
report from Google and a few others that is of low value to me. I could
either set a filter to delete those reports, or I modify my DMARC record to
stop requesting them. Either way, this is reversible in the future.

For an ISP or corporate entity, I would be more inclined to agree with you.
Somebody in another department could set up with some other service
provider that handles some form of email messaging without enabling proper
authentication and you'd want to be able to catch that, and summary
(aggregate) information from the big guys would help immensely.

So I do get your point, but it doesn't see to fit my use case.

Cheers,
Al Iverson

On Sun, May 27, 2018 at 11:18 AM Vladimir Dubrovin 
wrote:



Aggregated report contain all information, including SPF/DKIM/DMARC
failures, but it doesn't contain forensic information (e.g. failed
message Subject). Aggregated reports are supported by almost all large
ESPs, so, if you have some troubles you will probably see it in
aggregated report.
Forensic report contains information about individual message failing
SPF/DKIM/DMARC with some details (forensic information) regarding this
message, e.g. message headers. The problem is there are very few peers
sending forensic reports, so you may receive some reports, but should
not expect to receive forensic reports in the case of failure.
If you do not receive aggregated reports there is a very high chance to
have configuration problem without noticing it.
27.05.2018 17:43, Al Iverson via dmarc-discuss пишет:

In a DMARC record, I see that rua= specifies the address to which

aggregate

feedback is to be sent, and ruf= specifies the address to which
message-specific forensic information is to be reported.

I'm just a tiny bit confused about terminology-- could somebody confirm

for

me that I'm thinking of this correctly? I prefer only to receive failure
reports at this time. I don't want to receive summary reports telling me
that everything is AOK. That suggests to me that I should remove the rua
field but leave the ruf field.

Have I got that right?

Thanks,
Al Iverson


--
Vladimir Dubrovin
@Mail.Ru

Re: [dmarc-discuss] RUA vs RUF reports

[Al Iverson via dmarc-discuss]

Well, I think that would depend on the use case, would it not?. I've got
one server and Google Apps, everything signs with DKIM, and SPF is
configured correctly. I don't really have any edge cases to look out for --
no other outsource service providers in the mix. The rare (for me) failed
message forensic reports provide feedback about other peoples' broken
mailing lists (and maybe someday examples of forgery, if somebody forges my
domain). In that scenario, I'm getting a daily "everything is OK" aggregate
report from Google and a few others that is of low value to me. I could
either set a filter to delete those reports, or I modify my DMARC record to
stop requesting them. Either way, this is reversible in the future.

For an ISP or corporate entity, I would be more inclined to agree with you.
Somebody in another department could set up with some other service
provider that handles some form of email messaging without enabling proper
authentication and you'd want to be able to catch that, and summary
(aggregate) information from the big guys would help immensely.

So I do get your point, but it doesn't see to fit my use case.

Cheers,
Al Iverson

On Sun, May 27, 2018 at 11:18 AM Vladimir Dubrovin 
wrote:


> Aggregated report contain all information, including SPF/DKIM/DMARC
> failures, but it doesn't contain forensic information (e.g. failed
> message Subject). Aggregated reports are supported by almost all large
> ESPs, so, if you have some troubles you will probably see it in
> aggregated report.

> Forensic report contains information about individual message failing
> SPF/DKIM/DMARC with some details (forensic information) regarding this
> message, e.g. message headers. The problem is there are very few peers
> sending forensic reports, so you may receive some reports, but should
> not expect to receive forensic reports in the case of failure.

> If you do not receive aggregated reports there is a very high chance to
> have configuration problem without noticing it.

> 27.05.2018 17:43, Al Iverson via dmarc-discuss пишет:
> > In a DMARC record, I see that rua= specifies the address to which
aggregate
> > feedback is to be sent, and ruf= specifies the address to which
> > message-specific forensic information is to be reported.
> >
> > I'm just a tiny bit confused about terminology-- could somebody confirm
for
> > me that I'm thinking of this correctly? I prefer only to receive failure
> > reports at this time. I don't want to receive summary reports telling me
> > that everything is AOK. That suggests to me that I should remove the rua
> > field but leave the ruf field.
> >
> > Have I got that right?
> >
> > Thanks,
> > Al Iverson
> >

> --
> Vladimir Dubrovin
> @Mail.Ru



-- 
al iverson // wombatmail // miami
http://www.aliverson.com
http://www.spamresource.com

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] RUA vs RUF reports

[Vladimir Dubrovin via dmarc-discuss]

Aggregated report contain all information, including SPF/DKIM/DMARC
failures, but it doesn't contain forensic information (e.g. failed
message Subject). Aggregated reports are supported by almost all large
ESPs, so, if you have some troubles you will probably see it in
aggregated report.

Forensic report contains information about individual message failing
SPF/DKIM/DMARC with some details (forensic information) regarding this
message, e.g. message headers. The problem is there are very few peers
sending forensic reports, so you may receive some reports, but should
not expect to receive forensic reports in the case of failure.

If you do not receive aggregated reports there is a very high chance to
have configuration problem without noticing it.

27.05.2018 17:43, Al Iverson via dmarc-discuss пишет:
> In a DMARC record, I see that rua= specifies the address to which aggregate
> feedback is to be sent, and ruf= specifies the address to which
> message-specific forensic information is to be reported.
>
> I'm just a tiny bit confused about terminology-- could somebody confirm for
> me that I'm thinking of this correctly? I prefer only to receive failure
> reports at this time. I don't want to receive summary reports telling me
> that everything is AOK. That suggests to me that I should remove the rua
> field but leave the ruf field.
>
> Have I got that right?
>
> Thanks,
> Al Iverson
>

-- 
Vladimir Dubrovin
@Mail.Ru

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

[dmarc-discuss] RUA vs RUF reports

[Al Iverson via dmarc-discuss]

In a DMARC record, I see that rua= specifies the address to which aggregate
feedback is to be sent, and ruf= specifies the address to which
message-specific forensic information is to be reported.

I'm just a tiny bit confused about terminology-- could somebody confirm for
me that I'm thinking of this correctly? I prefer only to receive failure
reports at this time. I don't want to receive summary reports telling me
that everything is AOK. That suggests to me that I should remove the rua
field but leave the ruf field.

Have I got that right?

Thanks,
Al Iverson

-- 
al iverson // wombatmail // miami
http://www.aliverson.com
http://www.spamresource.com
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)