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
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
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
> 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
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
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
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
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
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.
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
12 matches
Mail list logo
