A. Schulze via dmarc-discuss:
the element will be present in tomorrow's reports.
lesson learned when running docker containers:
fixes inside a container are volatile, rebuild the container at all to
make /permanent/ changes...
it will take some more days...
happy weekend!
Andreas
_
On 19.04.2018 18:38, A. Schulze via dmarc-discuss wrote:
> Am 19.04.2018 um 08:30 schrieb Juri Haberland via dmarc-discuss:
>> [btw. the SPF result seems wrong: "none" instead of "pass" for a mail from
>> the opendmarc-users ML]
>
> RFC5321.MailFrom for messages from opendmarc-users is
> "f...@t
On 19.04.2018 12:32, Alessandro Vesely via dmarc-discuss wrote:
> On Thu 19/Apr/2018 08:30:04 +0200 Juri Haberland via dmarc-discuss wrote:
>> This is what I found:
>> - wrong MIME type: expected: text/xml (.xml); found: application/xml (.xml)
> I found text/xml as required
Right.
>> - missing
Am 19.04.2018 um 08:30 schrieb Juri Haberland via dmarc-discuss:
> [btw. the SPF result seems wrong: "none" instead of "pass" for a mail from
> the opendmarc-users ML]
RFC5321.MailFrom for messages from opendmarc-users is "f...@trusteddomain.org".
That generate "spf=pass smtp.mailfrom=opendmarc
Am 19.04.2018 um 12:32 schrieb Alessandro Vesely via dmarc-discuss:
> I had that. However, I missed the element inside .
the element will be present in tomorrow's reports.
> Although this is optional, I think that's the reason why I don't "see" your
> reports.
There is a SHOULD in https://to
it will
>see the IP address of the upstream system)
> * DKIM will potentially be broken by the upstream system (always in
>Mimecast's case)
>
> Reporting is probably a no also, because there's no reason at all for
> Microsoft to disclose this information; fr
Hi
On Thu 19/Apr/2018 08:30:04 +0200 Juri Haberland via dmarc-discuss wrote:
> On 2018-04-19 07:55, A. Schulze via dmarc-discuss wrote:
>> since some days aggregated reports we generate using an other software:
>> rspamd These reports are invisible at dmarcian.com. I would like to ask
>> the group
