Dominic

On Thu, 21 Mar 2019 at 13:52, Rainer Sokoll rsokoll@users.sourceforge.net wrote: Are you sure that opendmarc tests NOT against the envelope-from? Isn't SRS made exactly for rewriting the envelope-from and not the header-from? And is there anything I can do here (operator of the rejecting mail server)? For an explanation about DMARC see, for example: https://www.sparkpost.com/resources/email-explained/dmarc-explained/ You haven't provided full details and have obfuscated, but it looks like the problem...

On Thu, 21 Mar 2019 at 13:02, Rainer Sokoll rsokoll@users.sourceforge.net wrote: Hi, this log: Mar 20 04:15:09 mx2 postfix/cleanup[10493]: 2E5F7610B4: milter-reject: END-OF-MESSAGE from o1.f.az.sendgrid.net[208.117.55.132]: 5.7.1 rejected by DMARC policy for example.com; from=bounces+4491766-4033-jdoe=example.com@sendgrid.net to=jdoe@example.com proto=ESMTP helo=<o1.f.az.sendgrid.net></o1.f.az.sendgrid.net> (original domain replaced with example.com) I do not understand much about SRS, but it seems...

I believe (though not sure how, since I can't now find it documented) that opendmarc will trust only the first (i.e. most recent) SPF header that it finds for each matching 'TrustedAuthservIDs' string. So if your policyd-spf daemon adds such a header to all emails (as it should) then you can be confident that it will be this header, and not any fake header (added previously), that will be trusted and used by opendmarc. Off topic: As far as I am concerned SPF is a broken technology anyway and I wish...

My feeling is that in the OP's original example this should pass: From: "Amazon.co.uk" <campaign-response@amazon.co.uk> <info@mejorargentina.com> because the From header address is info@majorargentina.com, and the earlier part of the line is just the 'text'. I agree though that it looks confusing - intentionally on the part of the malicious sender. Blocking it, although logical, is (I suspect, have not checked) a breach of the DMARC spec.

I don't see that it should be a problem if you leave the two SPF settings (SPFIgnoreResults and SPFSelfValidate) at their default 'false' settings. Why do you think it would be? OpenDMARC will mark an SPF fail if it doesn't see an SPF approval header that it trusts. In practice almost all senders using DMARC with p=reject or p=quarantine ensure that their emails are signed with DKIM - so they pass DMARC even with SPF fail.

Thanks Juri.

I now realise that the field that records the domain policy is 'p', while the subdomain policy (if any) is recorded in 'sp', not 'policy'. I don't know what the 'policy' field records, maybe nothing meaningful?

HistoryFile policy field not recording correctly?