On 31/05/18 10:28, Richard via dmarc-discuss wrote:
Date: Thursday, May 31, 2018 09:26:38 +0800
From: Roland Turner via dmarc-discuss
Sending failure reports to
strangers appears unjustifiable under GDPR.
A currently common case where reports are going where they shouldn't
is with mailing
> Date: Thursday, May 31, 2018 09:26:38 +0800
> From: Roland Turner via dmarc-discuss
>
> On 31/05/18 04:51, 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)
On 31/05/18 04:51, 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
On 31/05/18 02:01, Jonathan Kamens via dmarc-discuss wrote:
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
On 30/05/18 22:56, Richard via dmarc-discuss wrote:
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.
I hadn't thought to perform this analysis:
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
On 31/05/18 02:31, Alessandro Vesely via dmarc-discuss wrote:
On Wed 30/May/2018 16:13:12 +0200 Roland Turner via dmarc-discuss wrote:
On 29/05/18 23:05, Alessandro Vesely via dmarc-discuss wrote:
[...] which includes pretty much all mail sites. The latter is *not* a
slow-moving data set.
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
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
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
On Wed 30/May/2018 16:13:12 +0200 Roland Turner via dmarc-discuss wrote:
> On 29/05/18 23:05, Alessandro Vesely via dmarc-discuss wrote:
>> [...] which includes pretty much all mail sites. The latter is *not* a
>> slow-moving data set. It grows steadily.
>
> Steady growth *is* slow movement.
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
On Wed, 2018-05-30 at 11:22 -0400, Jerry Warner wrote:
> I do not have a SPF record for mail.server.com in addition to
> server.com I thought it rolled back to server.com based on what I
> read.
As previously noted, nope.
> What's the point in listing mail.server.com in the server.com
>
just a guess but does mail.server.com have its own SPF record? Because, it
won't inherit anything in the SPF for server.com and if it's also not DKIM
signing those emails then that would cause your DMARC failure.
I do not have a SPF record for mail.server.com in addition to
server.com I
> 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
Yeah, only the DMARC settings "trickle down" to a subdomain. Your SPF or
DKIM authentication does not. It really sounds like you just need to add an
SPF record for the subdomain.
Cheers,
Al Iverson
On Wed, May 30, 2018 at 10:28 AM Ken O'Driscoll via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:
On 30/05/18 06:09, Brandon Long via dmarc-discuss wrote:
On Tue, May 29, 2018 at 8:10 AM Alessandro Vesely via dmarc-discuss
mailto:dmarc-discuss@dmarc.org>> wrote:
I know ARC proponents don't want author's domains to sign ARC-0,
but never
understood why. Anyway, ordinary
On Wed, 2018-05-30 at 09:44 -0400, Jerry Warner via dmarc-discuss wrote:
> I'm reading over my reports and I see that I'm getting fails on valid
> emails sent from my server when the sender uses a mail.server.com
> name instead of just server.com.
Hi Jerry,
just a guess but does
On 29/05/18 23:05, Alessandro Vesely via dmarc-discuss wrote:
* A single public whitelist is not necessary for ARC to work, multiple
lists are certainly possible, but the mapping of well-behaved
whitelist operators is:
o much easier than mapping abusers, as the latter are
I'm reading over my reports and I see that I'm getting fails on valid
emails sent from my server when the sender uses a mail.server.com
name instead of just server.com. I read that in this case the DMARC
will default to the "organizational domain" which using their
examples, would have
20 matches
Mail list logo
