27.01.2019 0:14, Дилян Палаузов пишет:
> Hello,
>
> reiterating over the arguments against sending reports to the ruf= …dmarc
> address, the first provided reason was, that
> such report will not match the expectations of the users.
> very good technical arguments skipped
Nope, the poin
On Sat, Jan 26, 2019 at 12:38 PM John Levine wrote:
> In article you
> write:
> >reiterating over the arguments against sending reports to the ruf= …dmarc
> address, the first provided reason was, that
> >such report will not match the expectations of the users.
>
> I'm pretty sure that the peop
In article you write:
>reiterating over the arguments against sending reports to the ruf= …dmarc
>address, the first provided reason was, that
>such report will not match the expectations of the users.
I'm pretty sure that the people you think you are arguing with are not
on this mailing list.
Hello,
reiterating over the arguments against sending reports to the ruf= …dmarc
address, the first provided reason was, that
such report will not match the expectations of the users. Which users? On the
site that sent the initial mail or on
the site that generated the report. It can be assum
Please, RUF is a ""Failure Report", not a "Forensic Report". Please read
RFC 7489 - https://datatracker.ietf.org/doc/rfc7489/
On Sat, Jan 26, 2019 at 12:21 PM Дилян Палаузов
wrote:
> Hello John,
>
> On Sat, 2019-01-26 at 11:31 -0500, John Levine wrote:
> > In article <6a56a3831dd4651e0d7610ee0c9
Hello John,
On Sat, 2019-01-26 at 11:31 -0500, John Levine wrote:
> In article <6a56a3831dd4651e0d7610ee0c90f50749a7203b.ca...@aegee.org> you
> write:
> > How can a domain owner communicate, that its users agree to have
> > investigations on forensic reports, where DKIM
> > signatures failed (fo
Hello,
will be there any concerns for sending slim forensic DMARC reports (ruf=) on
failed DKIM validation, if
* between sender and recipient there are no intermedates/aliases/redirecting
providers,
* the third MIME part of multipart/report is cut (contrary to
https://tools.ietf.org/html/rfc59
In article <6a56a3831dd4651e0d7610ee0c90f50749a7203b.ca...@aegee.org> you write:
>How can a domain owner communicate, that its users agree to have
>investigations on forensic reports, where DKIM
>signatures failed (fot the purpose of avoiding repeating errors in DKIM
>signing/validation)? In par
Hello,
On Sat, 2019-01-26 at 10:36 -0500, John Levine wrote:
> In article <40a9f309a70254b799f8bc3e42cbec2f5cf9dd7b.ca...@aegee.org> you
> write:
> > What are the privacy concerns in this simple scenario that speak against
> > sending a DMARC/DKIM report to sending server,
> > telling that the D
In article <40a9f309a70254b799f8bc3e42cbec2f5cf9dd7b.ca...@aegee.org> you write:
>What are the privacy concerns in this simple scenario that speak against
>sending a DMARC/DKIM report to sending server,
>telling that the DKIM validation fails?
The person reading the DMARC reports had enough autho
Hello,
how does the unrealistic expectation of message sender and recipient, that a
“deleted” message is immediately
irreversibly removed from all backups, differ from the expectation that an
“erased” message does not exist in a forensic
subsystem?
Do Terms of Use, that clarify the sending of f
Message sender can expect message content is only stored in sender's and
recipient's mailboxes after delivery. If deleted by both sender and
recipient, this message is not longer exists and it's content can not be
recovered.
In this scenario, (partial) message content can be stored in DMARC
foren
Hello,
for a smooth working DMARC DKIM signers and verifiers must be interoperatable.
When a server DKIM-signs a message and
sends it to another server without intermediates, the latter shall be able
verify the signature. Imagine, the DKIM
validation fails and the ruf= dmarc report email addre
13 matches
Mail list logo
