On Tuesday, April 28, 2015 3:39 AM [GMT+1=CET], Stephen J. Turnbull wrote: > Hector Santos writes: > > On 4/26/2015 8:34 PM, Stephen J. Turnbull wrote: > > > > The problem is that all are detested by some users, and none are > > > actually liked by any user. Therefore we developers continue to > seek > > alternatives -- but all desirable alternatives require > cooperation of > > "p=reject" posting domains because of the nature > of current validation/ > > authentication protocols as > Originator-Receiver agreements. > > > The mediator has a receiver. Doesn't it have the same > > Originator-Receiver agreements? > > The effects are different. According to DMARC, a message which passes > at the Mediator, will fail at the next Receiver.
That is why it would be appropriate for the DMARC spec to explicitely say that a "DMARC-compliant Operator" CANNOT accept messages from p=reject domains AND then reinject them into the public email infrastructure in any why that would make them (or reveal them to be) susceptible to fail a DMARC check performed by the next-hop Recipient. The DMARC spec should declare that if any email operator did that, he could not be termed as "DMARC-compliant". Because if any email operator does that, he is in fact polluting the global email traffic stream with non-authorized email according to the public policies declared by DMARC-compliant original Senders. So that: to be a "DMARC-compliant Operator", it would be required to be (1) DMARC-compliant when performing the role of Receiver, and also to be (2) DMARC compliant when performing the role of Sender. So that lacking (1) or (2) it would render the email operator as non compliant with DMARC. DMARC-compliant Operator == DMARC-compliant in the role of Receiver + DMARC-compliant in the role of Sender Regards, J.Gomez _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
