On Wednesday, April 29, 2015 2:04 PM [GMT+1=CET], Stephen J. Turnbull wrote:
> J. Gomez suggests: > > > > > That would force DMARC-compliant Mediators to reject (or accept > > > > but not resend) incoming email from p=reject domains, > > > > irrespective of whether such mail passes or not the initial > > > > incoming DMARC checks. > > Something about having mediators (ie, non-MTAs) implement this check > was bothering me. I realized that the nagging thought was the > *Mediator* doesn't have to do it. How is a Mediator not an MTA (among other things)? Didn't we agree that a Mediator is an actor that does both the role of Receiver (MTA-based) and the role of Originator (MTA-based)? Original Originator ==> [ Mediator's Receiver role -> Mediator's internal process -> Mediator's Originator role ] ==> Final Receiver. The important point is that "Mediator's Originator role" SHOULD NOT inject DMARC-rejectable messages into the public email infrastructure (but I don't care if the Mediator rejects[*] those messages at the point "Mediator's Receiver role", or at the point "Mediator's internal process", or at the point "Mediator's Originator role"; that is an implementation detail specific to each Mediator. [*] I don't care also if the Mediator *rejects* those messages, or *forwards* them to /dev/null, or *transforms* them into non DMARC-rejectable messages. The point is: Mediator SHOULD NOT inject DMARC-rejectable messages into the public email infrastructure[**], how they achieve that is 100% up to them to decide/solve. [**] And if they do inject them, then such Mediator SHOULD be labeled and non DMARC-compliant and the DMARC specification SHOULD spell out clearly that doing such a thing is a VIOLATION of the DMARC specification. (Keep in mind DMARC is not mandatory for SMTP, so email actors can always choose to be or not to be DMARC-compliant.) Regards, J.Gomez _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
